The BA's output
Requirements are the business analyst's primary product. Artefacts are the containers that hold, structure, and communicate those requirements to the people who will act on them — sponsors, designers, developers, testers, and the business functions that will eventually own the solution.
The question that requirements answer is: what must the solution do, to what standard, for whom? Everything the BA produces flows from that question.
By the end of this unit- State what makes a requirement well-formed, using the NATTIC quality criteria.
- Name the 16 standard BA artefacts in lifecycle order.
- Distinguish the purpose of the BRD from the FRD and explain when each is produced.
- Write a user story with acceptance criteria in Gherkin format.
- Explain what an RTM is and why it matters when scope is challenged.
The cost of poor requirements
Late scope changes, rework cycles, and misaligned delivery all trace back to the same root cause: ambiguity that was present in the requirements and never resolved. The longer ambiguity survives, the more expensive it becomes to address.
NATTIC — the quality criteria for requirements
A well-formed requirement meets six criteria. The acronym NATTIC provides a checklist that can be applied to any requirement before it leaves the BA's desk.
N — Necessary
A — Unambiguous
T — Testable
T — Traceable
I — Independent
C — Consistent
In practice, unambiguous is the criterion most often violated. Stakeholders describe the solution they imagine rather than the outcome they need, and the language they use is imprecise by default. The BA's job at elicitation is to press past the first answer until the underlying, measurable requirement is visible.
The standard artefact set
A BA working on a moderately complex change programme will produce a set of interconnected artefacts, each serving a specific audience at a specific point in the delivery lifecycle. Knowing the full set — and the order in which artefacts are produced — prevents the gaps that lead to misaligned delivery.
16 artefacts in lifecycle order
Stakeholder Map / RACI
Who is affected, who has authority, who must be consulted. Produced first, because every subsequent artefact is written for a specific audience. The RACI (Responsible, Accountable, Consulted, Informed) maps decision rights.
Business Case
The rationale for investment. Problem statement, options appraisal, recommended option, costs, benefits, risks, and success criteria. Written before scoping begins in earnest.
Business Requirements Document (BRD)
The problem, scope, stakeholders, constraints, assumptions, and success criteria. What the business needs. Not what the solution does.
Functional Requirements Document (FRD)
What the solution must do. Each requirement numbered, atomic, and testable. Written after the BRD and prior to solution design.
Capability Map
The business capabilities required to deliver the outcomes. Links strategy to execution. Often used to identify gaps between current and target state.
Value Stream Map
End-to-end flow from trigger to outcome, showing where time and value are added or lost. Produced during current-state analysis.
Process Models (BPMN)
Current-state and future-state process diagrams. Shows how work gets done and how the proposed change alters the flow.
Decision Models (DMN)
Decision tables for complex business rules. Referenced from BPMN gateway points. Documents the logic currently held in people's heads or undocumented spreadsheets.
Service Blueprint
The customer journey mapped against frontstage actions, backstage processes, and supporting systems. Bridges customer experience and operational reality.
User Stories + Acceptance Criteria
Requirements expressed in the voice of the user. Each story paired with Gherkin-format acceptance criteria that define "done". Used in agile delivery.
Use Cases
Actor-system interaction descriptions. More detailed than user stories. Used when system behaviour needs to be specified precisely, particularly for complex or safety-critical flows.
Wireframes / Prototypes
Visual representations of the proposed interface. Used to elicit requirements, validate understanding with stakeholders, and brief UX and development teams.
Data Model / ERD
Entity-relationship diagram showing the data objects, their attributes, and the relationships between them. Produced in collaboration with solution architects and data teams.
Requirements Traceability Matrix (RTM)
Maps each requirement from source through design, build, and test. The single most-skipped document — and the one that most often saves a programme when scope is challenged.
Test Cases / UAT Scripts
The test conditions derived from acceptance criteria and functional requirements. Confirms that what was built matches what was specified.
Solution Evaluation Report
Post-implementation review: did the solution deliver the benefits defined in the business case? Closes the loop between the problem statement and the delivered outcome.
BRD and FRD
The BRD and FRD are the two most fundamental written artefacts a BA produces. They are related but distinct, and confusing them — or combining them into a single document — is one of the most common causes of scope drift and rework.
Business Requirements Document
Purpose: answers "why are we doing this?" It captures the business need, not the solution. The BRD is owned by the business sponsor and signed off before solution design begins.
- Executive summary — the problem in plain language
- Business objectives — measurable outcomes the change must deliver
- Scope statement — what is in scope, what is explicitly out of scope
- Stakeholder register — who is affected and how
- Current state summary — what exists today and why it is insufficient
- Constraints and assumptions — regulatory, technical, organisational
- Success criteria — how the business will know the change worked
- Risks and dependencies — what could prevent delivery or reduce benefit
Functional Requirements Document
Purpose: answers "what must the solution do?" It specifies the behaviour the solution must exhibit to satisfy the business requirements. The FRD is the primary input to solution design and the basis for test cases.
- Requirement ID — unique, sequential, traceable (e.g. FR-001)
- Requirement statement — atomic, unambiguous, testable. Format: "The system shall [do X] when [condition Y]."
- Priority — MoSCoW (Must, Should, Could, Won't) or numbered priority
- Source — the BRD section or stakeholder input that generated this requirement
- Acceptance criteria — the pass/fail conditions used in testing
- Non-functional requirements — performance, security, availability, accessibility
- Data requirements — inputs, outputs, data formats, validation rules
- Assumptions and exclusions — what is being assumed and what is deliberately excluded
Writing the FRD before the BRD is signed off. If the business objectives are not agreed, any functional requirement that does not trace back to a confirmed objective is potentially out of scope. Lock the BRD first, then write the FRD.
User stories and the RTM
In agile delivery, requirements are most often expressed as user stories. In regulated, complex, or large-scale programmes, the RTM (Requirements Traceability Matrix) is what connects those stories — and the FRD requirements beneath them — to design, build, and test evidence.
User story format
A user story is a short statement of a requirement from the user's perspective, written in a standard three-part format:
The three parts matter equally. The role defines whose need is being served. The action describes what the system or process must do. The benefit explains why — and the why is what prevents requirements from being cut when pressure mounts, because it connects the story to a business outcome.
Example: loan officer completing a credit check
Why the benefit matters: "So that I do not need to log into a separate system and manually re-enter the result" is not just description — it defines the integration requirement and the data-entry waste being eliminated. Without it, a developer might build a link that opens a separate browser tab and consider the story done.
Common user story failures
Missing the benefit: "As a manager, I want a report" gives no indication of what decision the report enables or what frequency is needed. The benefit anchors the scope.
Too large (an epic, not a story): "As a customer, I want to manage my account online" is a feature, not a story. Break it into stories that can be built and tested independently within a sprint.
Acceptance criteria in Gherkin
Every user story needs acceptance criteria: the test that says "done". The Gherkin format (Given / When / Then) structures criteria so that they can be read by a tester and, in automated testing, parsed directly as test code.
Gherkin structure
When [the action — what the user or system does]
Then [the outcome — what the system does in response, verifiably]
Example:
Given a loan application is open and the applicant's ID has been verified,
When the loan officer selects "Run credit check",
Then the system returns the credit score and bureau reference within 5 seconds and displays them on the application screen without requiring re-entry.
Multiple scenarios per story
Scenario 2 (bureau unavailable):
Given a loan application is open,
When the loan officer selects "Run credit check" and the bureau returns an error,
Then the system displays an error message specifying the failure reason and logs the attempt with a timestamp.
The Requirements Traceability Matrix
The RTM maps every requirement from its source through every stage of delivery to its test evidence. It is the single most-skipped document in BA practice, and the one that most often saves a programme when scope is questioned in a steering committee or contract review.
RTM columns
Standard column set
| Column | Purpose |
|---|---|
| Req ID | Unique identifier (e.g. FR-012). Never renumber requirements once issued. |
| Source | Where the requirement came from: stakeholder name, BRD section, regulation reference. |
| Priority | MoSCoW or numerical. Used when scope must be cut under time pressure. |
| Design reference | The design document section, wireframe, or architecture decision that addresses this requirement. |
| Build reference | The sprint, user story ID, or code module that implements it. |
| Test case | The test case ID that verifies the requirement is met. |
| Status | Not started / In design / In build / In test / Verified / Closed. |
An RTM can be as simple as a well-structured spreadsheet. The value is in having it, not in the tool. Start it at the same time as the FRD. Update it at every stage gate. By the time you reach UAT, a complete RTM makes the difference between a sign-off conversation and a scope argument.
Think of a recent project or programme. Did it have a requirements traceability matrix? If not, at what point did you feel the absence — in design, in testing, or in a scope discussion? If it did have one, was it actually used or was it produced for compliance and then ignored?
Unit review
What does NATTIC stand for, and which of its criteria is most commonly violated in practice?
On a recent project, did you have a requirements traceability matrix? If not, where did you feel the absence most acutely — in a scope argument, during testing, or in the post-implementation review? If you were starting that project again, at what point would you have introduced the RTM?
End of Course 05
You should now be able to:
- Apply the NATTIC criteria to evaluate the quality of any individual requirement.
- Name and order the 16 standard BA artefacts across the delivery lifecycle.
- Distinguish the BRD from the FRD and explain the sequencing rule between them.
- Write a user story and acceptance criteria in the standard formats.
- Maintain a requirements traceability matrix from the FRD stage through UAT.
Continue to Course 06: AI for Business Analysts.