8 Key Business Analysis Acronyms and Abbreviations from B to S

When you enter the world of business analysis for the first time, you might find yourself having one of two competing thoughts:

• Everything is quite clear and obvious; or
• Everything is confusing and unfamiliar.

You can argue that which group you fall into depends on the domain, methodology, technique, or approach, but there is at least one BA sphere that will always end up in the second category: the world of BA acronyms and abbreviations.

In this article, I focus on the most common key business analysis acronyms and abbreviations.

BABOK

BABOK is definitely the one to start with. This acronym stands for “Business Analysis Body of Knowledge.” It scares all newcomers at first, since it presents as a huge monster that cannot be conquered. But you shouldn’t fear it. Instead, think of it not as a book that you need to memorize, but as a comprehensive guide that you can refer to as needed – which provides help to business analysts of all levels. In the BABOK, you’ll find detailed information on six core knowledge areas, skills, deliverables, and the techniques required to achieve better outcomes. For newcomers, it is a trusted and valuable resource for learning and enhancing their effectiveness.

UML

UML stands for “Unified Modeling Language,” and there are two things to remember about it. The first is that UML offers a variety of diagrams and focuses on the structure and behavior of objects in a system. The second is that you should never confuse it with BPMN, which means “Business Process Model and Notation” and focuses on process flow diagrams.

STAR

STAR model might be a surprise (since each business analyst is a star or feels like one) because it stands for “Situation — Task — Action — Result.” Does this relate to business analysis? Yes, in many ways – and not only to business analysis, but to any field in which communication and collaboration are highly valued. Here is how the model works:

• Situation: first, you focus on the context or situation that you face;
• Task: once the context is clear to everyone, you specify the task that you want to address;
• Action: next, you share the actions that you took to resolve the issue; and
• Result: finally, you wrap up the narration by explaining the outcome of your actions.

For business analysts, the STAR model will be very useful when preparing to elicit requirements. It can help you: gather detailed information about specific scenarios; analyze existing processes to reveal areas for improvement; and interview stakeholders, since it makes your communication well-organized, concise, evidence-based, and clear.

INVEST

INVEST should be the acronym that you already know and use. It stands for “Independent — Negotiable — Valuable — Estimable — Small — Testable” and is used to create effective user stories in Agile.

• Independent: the more independent user stories are, the simpler it is to prioritize them and implement them in parallel without blockers.

• Negotiable: the core of BA work is collaboration to achieve desired outcomes. When refining a user story, be ready to face questions, concerns, and ideas and – most importantly – remember that negotiation is a key to successful teamwork and great results.
• Valuable: every time you create a user story, ask yourself whether it delivers value to end users or not. If not, you know what to do.
• Estimable: estimates help us understand the complexity of a user story in terms of effort. It is vital to consider the full scope of a story and to break it down if it’s too complicated or vague.
• Small: simply — the smaller the stories are, the easier it is to manage them.
• Testable: do you remember the “valuable” part? The only way to see whether value is delivered is to verify it. To do that, there should be acceptance criteria accompanying each user story.

Now that all of the elements are defined, as a newcomer, you need to keep in mind that collaboration, chunking, and prioritization are the fundamental activities that INVEST is based on.

NFRs

NFRs stands for “Non-Functional Requirements” which differ from the functional requirements in that they describe how the functional requirements should work. To oversimplify, functional requirements define what the system is supposed to do, NFRs focus on how well a system does those things. NFRs address aspects such as speed, security, reliability, data integrity, usability, scalability, etc.

For a newcomer, this category might be challenging at first, but with the help of the BABOK guide and more senior colleagues, it will be easier to cope with conflicting stakeholders’ views on NFRs, constraints associated with external systems, business-specific processes, priorities, and rules.

ERD

ERD stands for “Entity-Relation Diagram,” and it provides a visual representation of data relationships to achieve a better understanding of complex systems. ERD is of great help to identify entities existing in the system and define their relationships. The major benefit of ERD is that it can facilitate communication and collaboration with the stakeholders by making sure everyone is on the same page. ERD are also widely used to design relational databases with a proper table structure. The major challenge of ERDs is that they can seem quite complex and, as a result, can scare newcomers. Here is a trick, never try to draw the entire diagram all at once. Instead, start with simple and clear entities and gradually complicate it.

SME

SME stands for "Subject Matter Expert” and refers to the stakeholders with in-depth knowledge of the current business process. SMEs help business analysts gather information about the specifics of the domain, including insights and information about the challenges that they face every day.

SMART

SMART stands for “Specific — Measurable — Achievable — Relevant — Time-Bound” and describes goals that help a business analyst establish clear directions and aims regardless of what they are working on, whether it’s eliciting requirements, suggesting a solution, or giving a presentation. Let’s see how it works:

• Specific: any goal that a BA sets should have a clear outcome. This means clear not just to the BA, but to everyone taking part in the discussion. To accomplish this, you should always try to be specific, even if it requires you to plunge the audience into the context and explain every detail. Ultimately, it’s worth it.
• Measurable: when setting goals, a BA can put themselves into QA shoes and ask, “how can we verify and prove this?” Doing so will illustrate that achieving a quantifiable goal is a clear direct path, which is easy to follow.
• Achievable: although sometimes a BA (especially a newcomer) may tend to set huge and idealistic goals, because the prospect of achieving them seems very satisfying, remember that the goals should always be realistic – and based on the proven facts, and the available tools and knowledge.
• Relevant: each specified goal should reflect a meaningful value and should contribute to, and align with, the overall idea/product, not contradict it.
• Time-Bound: when setting goals, in addition to being measurable, a BA should focus on the due date or a timeline that will help everyone involved understand the scope of the goal and have a clear vision of the pace, complexity, and expectations.

In conclusion, remember that to work SMART (although it can be hard at first), you need to collaborate with stakeholders and SMEs as a STAR, supporting your ideas with ERD and UML diagrams. And don’t forget that NFRs INVEST a lot into user stories and should not be overlooked. Finally, do not be afraid to refer to the BABOK guide — it’s not a silver bullet, but it will definitely assist you in most cases.