Business Analysis 101: BA Foundations - What Is Business Analysis? IIBA, BABOK v3 Overview

What This Is

Business Analysis is the disciplined practice of understanding what a business needs to achieve its goals and then defining the changes—people, processes, technology, or information—that will deliver those outcomes. In the BA lifecycle the analyst acts as the bridge between the problem space (the current state) and the solution space (the future state).

Real?world example: A mid?size insurer wants to cut claim?processing time by 30?%. The BA works with claims adjusters, IT, and senior management to map the existing process, capture the required improvements, and define the functional and non?functional requirements for a new claims?management system.

Key Terms & Techniques

• Stakeholder: Any person, group, or organization that can affect or be affected by the change. (Stakeholder Analysis – Knowledge Area: Business Analysis Planning & Monitoring; Deliverable: Stakeholder Register)
• Elicitation: The set of activities used to gather information from stakeholders. (Knowledge Area: Elicitation & Collaboration; Deliverable: Elicitation Activity Plan, Raw Requirements)
• MoSCoW Prioritization: Classifies requirements as Must, Should, Could, or Won’t – a quick way to agree on what is essential. (Knowledge Area: Requirements Life Cycle Management; Deliverable: Prioritized Requirements)
• BPMN (Business Process Model and Notation): A standardized visual language for drawing process flowcharts. (Knowledge Area: Business Analysis Planning & Monitoring; Deliverable: Process Models)
• Use Case / User Story: Narrative describing how a user interacts with a system to achieve a goal. (Knowledge Area: Requirements Analysis & Design Definition; Deliverable: Use Case Diagram, User Stories)
• Traceability Matrix: A table that links each requirement to its source, design, test case, and implementation artifact. (Knowledge Area: Requirements Life Cycle Management; Deliverable: Requirements Traceability Matrix)
• SWOT Analysis: Examines Strengths, Weaknesses, Opportunities, and Threats to inform solution options. (Knowledge Area: Strategy Analysis; Deliverable: SWOT Diagram, Business Need)
• RACI Chart: Defines who is Responsible, Accountable, Consulted, and Informed for each activity. (Knowledge Area: Business Analysis Planning & Monitoring; Deliverable: RACI Matrix)
• Gap Analysis: Compares current state to desired future state to identify what must change. (Knowledge Area: Strategy Analysis; Deliverable: Gap Analysis Report)
• Non?Functional Requirements (NFRs): Quality attributes such as performance, security, usability. (Knowledge Area: Requirements Analysis & Design Definition; Deliverable: NFR Specification)
• Change Control Process: Formal method for reviewing, approving, and tracking requirement changes. (Knowledge Area: Requirements Life Cycle Management; Deliverable: Change Log, Change Request)
• Solution Assessment & Validation: Activities that confirm the implemented solution meets the business need. (Knowledge Area: Solution Evaluation; Deliverable: Evaluation Report, Defect Log)

Step?by?Step / Process Flow

1. Plan the BA approach – Define scope, identify stakeholders, select techniques, and create a BA work?plan (BA Plan).
2. Elicit & collaborate – Run workshops, interviews, and surveys; capture raw information in a Requirements Traceability Matrix.
3. Analyze & model – Convert raw data into models (BPMN diagrams, use cases, SWOT) and prioritize with MoSCoW.
4. Validate & baseline – Review models with stakeholders, resolve conflicts, and obtain sign?off on the Baseline Requirements Document.
5. Manage requirements – Track changes, maintain the Traceability Matrix, and ensure alignment through the solution’s life?cycle.

Common Mistakes

• Mistake: Treating “requirements” as a single, static document.
  Correction: BABOK treats requirements as living artifacts; they evolve, are version?controlled, and are continuously validated.

• Mistake: Assuming the BA “writes the code” after gathering requirements.
  Correction: The BA’s role ends at defining what the solution must do; design, development, and testing belong to the solution team, though the BA may verify that the design meets the requirements.

• Mistake: Using only one elicitation technique (e.g., only interviews).
  Correction: BABOK recommends a mix of techniques (workshops, observation, prototyping) to triangulate information and reduce bias.

• Mistake: Skipping stakeholder analysis because “everyone is a stakeholder.”
  Correction: Properly classifying stakeholders (primary, secondary, key) helps focus communication and risk management.

• Mistake: Forgetting to capture non?functional requirements.
  Correction: NFRs are a distinct input to design and testing; they must be elicited, documented, and traced like functional requirements.

Certification Exam Tips

1. Know the input?output pairs – Many questions ask “What is the primary output of Elicitation?” (Answer: Requirements). Memorize the main inputs/outputs for each Knowledge Area.
2. Watch the “next step” trap – If a scenario ends with a signed Requirements Document, the next logical activity is Solution Assessment & Validation, not Requirements Management.
3. Distinguish Knowledge Areas – “Strategy Analysis” focuses on business need and assessment of options; “Requirements Analysis & Design Definition” is where you model and prioritize.
4. Prioritization techniques are not interchangeable – MoSCoW is for prioritizing requirements, while the Kano Model is for categorizing features by customer satisfaction.

Quick Check Questions

1. Scenario: After a requirements workshop, three senior managers disagree on the priority of a new reporting feature. Which technique should the BA use to reach consensus?
   Answer: MoSCoW Prioritization.
   Why: It forces the group to label each requirement as Must, Should, Could, or Won’t, making trade?offs explicit and helping the team agree on what truly must be delivered.

2. Scenario: The BA has captured raw interview notes but needs to show how each requirement links to the business goal, design, and test case. Which deliverable is required?
   Answer: Requirements Traceability Matrix.
   Why: The matrix provides a bi?directional link between requirements and all downstream artifacts, satisfying traceability and change?impact analysis.

3. Scenario: The project sponsor asks the BA to confirm whether the new claims?processing system meets the 30?% reduction target. Which Knowledge Area contains the appropriate activities?
   Answer: Solution Evaluation.
   Why: This area includes measuring performance, validating benefits, and recommending improvements—exactly what the sponsor needs.

Last?Minute Cram Sheet (10 one?liners)

1. Elicitation = activity; Requirements = output.
2. Stakeholder Register lives in Business Analysis Planning & Monitoring.
3. MoSCoW is a prioritization technique; Kano is a categorization technique.
4. BPMN diagrams are the primary deliverable of Business Analysis Planning & Monitoring (process modeling).
5. Non?Functional Requirements are captured in the Requirements Analysis & Design Definition Knowledge Area.
6. Traceability Matrix links requirements to design, test, and implementation artifacts.
7. Gap Analysis belongs to Strategy Analysis and produces a Gap Report.
8. RACI Chart clarifies roles and is a BA planning artifact.
9. Change Control Process is part of Requirements Life Cycle Management; it produces a Change Log.
10. Solution Evaluation is the only Knowledge Area that explicitly includes benefits measurement and risk assessment of the implemented solution.