Business Analysis 101: Requirements Analysis and Design Definition - Analyzing and Specifying Requirements, Acceptance Criteria, Gherkin

What This Is

Analyzing and specifying requirements is the “Define” phase of the BABOK® Business Analysis Core Concept Model. It turns elicited stakeholder needs into clear, testable statements that developers, testers, and the business can agree on. In practice, this means writing acceptance criteria (the “done” checklist for a user story) and, when using Agile, expressing those criteria in Gherkin syntax (Given?When?Then).

Real?world example: A financial services firm is rolling out a new CRM system to track sales leads. The BA works with sales reps, compliance officers, and IT to turn “We need to see a lead’s status” into a user story with acceptance criteria such as “When a lead is marked Qualified, the system must automatically send a notification to the account manager” – written in Gherkin so the test?automation team can run it directly.

Key Terms & Techniques

• Acceptance Criteria – Specific conditions that a solution must satisfy to be accepted; output of the Requirements Analysis knowledge area, usually attached to a user story.
• Gherkin – Plain?language, structured format (Given?When?Then) for writing acceptance criteria; belongs to the Solution Evaluation and Requirements Life Cycle Management areas.
• User Story – Short, role?goal?benefit description of a requirement; primary deliverable of Elicitation and Analysis.
• Definition of Done (DoD) – Team?wide agreement on when work is complete; a Solution Scope artifact that complements acceptance criteria.
• Behavior?Driven Development (BDD) – Development approach that uses Gherkin to drive automated tests; linked to Solution Evaluation and Requirements Management.
• Non?Functional Acceptance Criteria – Performance, security, usability, etc., that must be met; part of Requirements Specification (e.g., “Response time < 2?s”).
• Traceability Matrix – Mapping of each acceptance criterion back to its originating stakeholder need; a Requirements Management deliverable.
• MoSCoW Prioritization – Must, Should, Could, Won’t; helps decide which acceptance criteria are essential for the current release (from Requirements Analysis).
• Specification by Example – Writing concrete examples (often in Gherkin) that illustrate requirements; supports Elicitation and Analysis.
• INVEST Model – Guideline for good user stories (Independent, Negotiable, Valuable, Estimable, Small, Testable); used during Requirements Life Cycle Management.
• Requirement Baseline – The approved set of acceptance criteria that will not change without formal change control; output of Requirements Management.
• Test?First Approach – Creating acceptance criteria (and Gherkin scenarios) before development starts; aligns with Solution Evaluation.

Step?by?Step Process Flow

1. Gather & Refine Stakeholder Needs – Conduct workshops, interviews, or observation sessions; capture high?level needs in the Business Requirements Document (BRD).
2. Create User Stories & Initial Acceptance Criteria – Translate each need into a user story using the INVEST model; draft “must?have” acceptance criteria (functional + non?functional).
3. Write Gherkin Scenarios – For each acceptance criterion, develop Given?When?Then statements (Specification by Example) and link them to the story in the backlog.
4. Validate & Prioritize – Run a review session with the product owner and key stakeholders; apply MoSCoW to rank criteria and update the Requirements Traceability Matrix.
5. Baseline & Manage Changes – Obtain formal sign?off on the acceptance criteria set; store it in the Requirements Baseline and use change?control procedures for any later modifications.
6. Hand?off to Development & Test – Export Gherkin scenarios to the automation framework; ensure the Definition of Done includes passing all Gherkin tests.

Common Mistakes

Certification Exam Tips

1. Know the Input/Output Relationship – Acceptance criteria are outputs of Requirements Analysis (BABOK?§5) and inputs to Solution Evaluation (BABOK?§6). Exam questions often ask “What does the BA produce after analyzing requirements?” – answer: Acceptance criteria (including Gherkin scenarios).
2. Distinguish Elicitation vs. Specification – The BA elicits information (technique: interviews, workshops) but specifies it as acceptance criteria. Look for wording like “writes” or “documents”-choose “specification” activity.
3. Remember the INVEST Checklist – When a question lists attributes of a good user story, the correct answer will reference Independent, Negotiable, Valuable, Estimable, Small, Testable.
4. Prioritization Technique – If a scenario mentions “must?have for the next release,” the exam expects MoSCoW (or Weighted Shortest Job First if the context is SAFe).

Quick Check Questions

1. Scenario: After a sprint planning meeting, the product owner says a user story’s acceptance criteria are too vague. Which technique should the BA apply?
   Answer: Specification by Example – write concrete Gherkin Given?When?Then scenarios.
   Justification: This technique turns vague statements into testable examples, directly addressing the problem.

2. Scenario: Stakeholders have identified 15 acceptance criteria, but the team can only implement 8 in the upcoming release. Which prioritization method is most appropriate?
   Answer: MoSCoW – classify criteria as Must, Should, Could, Won’t.
   Justification: MoSCoW explicitly separates essential from optional items, guiding scope decisions.

3. Scenario: A BA is asked to ensure that every acceptance criterion can be traced back to a business need. Which deliverable satisfies this requirement?
   Answer: Requirements Traceability Matrix.
   Justification: The matrix provides the one?to?one mapping between criteria and stakeholder needs.

Last?Minute Cram Sheet (10 One?Liners)

1. Elicitation = activity; Requirements = output (BABOK?§5.1).
2. Acceptance Criteria belong to Requirements Analysis; they become Test Cases in Solution Evaluation.
3. Gherkin uses Given?When?Then; it is a Specification by Example technique.
4. INVEST is the checklist for a good user story (BABOK?§5.2).
5. DoD is a solution scope artifact; it must include passing all Gherkin scenarios.
6. MoSCoW is a prioritization technique; “Must” items become the baseline.
7. Traceability Matrix links acceptance criteria-business needs-solution components.
8. Non?Functional Acceptance Criteria cover performance, security, usability, etc. (BABOK?§5.3).
9. Baseline = approved set of criteria; any change requires formal change control (BABOK?§5.5).
10. BDD = development approach that consumes Gherkin; the BA writes the scenarios, the test team automates them.

Good luck – you now have the practical toolkit to analyze, specify, and test requirements, and the exam?ready shortcuts to ace ECBA, CCBA, or CBAP!