Business Analysis

How to write a Business Requirements Document: a step-by-step guide for Business Analysts

A BRD is not a place to impress with volume. It is a place to remove ambiguity. Here's the process, the rules, and the quality checks that separate a document that ships from one that sits in a folder.

Of all the deliverables a Business Analyst produces, the Business Requirements Document carries the most downstream weight. It is the document that a delivery team works from. It is the document that defines what done looks like. It is the document that, when it is wrong, turns a technical success into a business failure.

Writing a good BRD is a discipline, not a talent. It follows a procedure. And the procedure, once internalised, produces documents that are reliable enough to hand to a development team without a standing meeting to explain them.

This guide walks through that procedure — from confirming the business problem through to the final quality review. The examples draw from customer data platform (CDP) programme delivery, which is the domain context for the YORIA AI Workplace Simulator, but the process applies to any programme where business requirements need to be formally captured.

Before you write a word: confirm the problem

The first mistake most BRDs make is starting too early. A requirements document written before the business problem is confirmed will document the wrong thing at high fidelity. That is worse than not documenting it at all, because it generates confidence where there should be uncertainty.

Before scoping the BRD, confirm three things:

• The problem statement — What is the business trying to solve, and what is the measurable impact of not solving it?
• The authorised scope — What is formally in scope for this programme? What is explicitly out of scope?
• The stakeholder map — Who has authority to define requirements, and who has authority to accept the final document?

Without these three, writing requirements is guesswork. With them, it is engineering.

The fifteen-step BRD procedure

The following steps represent a complete procedure from problem confirmation to signed document. Not every project will require every step, but skipping steps should be a deliberate decision, not an omission.

1. Confirm the business problem and programme objectives. Meet with the programme sponsor and document the problem in their words. The problem statement should be specific enough that you could test whether the programme has solved it.

2. Review existing documentation. Collect and read current-state process maps, system architecture diagrams, data dictionaries, previous requirement documents, and any relevant policy or regulatory documentation before your first stakeholder session. Arriving uninformed wastes stakeholder time and signals poor preparation.

3. Identify and schedule stakeholder elicitation sessions. Use the stakeholder map to identify every group with a legitimate interest in the requirements. Schedule structured elicitation sessions, not informal conversations. Informal conversations do not produce requirements; they produce impressions.

4. Conduct elicitation sessions. Run sessions with a prepared question set. Capture verbatim responses where possible. Distinguish between what stakeholders say they need and what they are actually trying to accomplish — the second often reveals requirements the first obscures.

5. Document requirements in a structured format. Each requirement should have a unique identifier, a clear statement using controlled language, a priority, a source, and a test check. This is the atomic unit of a BRD. See the requirement writing rules below.

6. Validate requirements with stakeholders. Return documented requirements to the stakeholders who raised them. Confirm you have captured their intent accurately. This step catches misinterpretation before it reaches the delivery team.

7. Identify conflicts and dependencies. Requirements from different stakeholders will sometimes conflict. Identify these explicitly rather than hoping the delivery team will resolve them. Escalate conflicts that cannot be resolved at BA level to the appropriate decision-maker.

8. Map requirements to business objectives. Every requirement should trace back to a stated business objective. Requirements that cannot be traced are candidates for removal. Traceability protects the scope of the programme and simplifies impact assessment when objectives change.

9. Prioritise requirements. Use a consistent prioritisation method — MoSCoW is standard. Document the rationale for priority decisions, particularly for requirements that are classified as Should Have or Could Have rather than Must Have. Priority decisions made without rationale are difficult to defend when delivery pressure arrives.

10. Define acceptance criteria. For each requirement, define what a successful test looks like. Acceptance criteria should be observable and deterministic — a tester looking at the system should be able to confirm pass or fail without subjective judgement.

11. Circulate a draft for review. Share the draft BRD with stakeholders and the delivery team for a structured review period. Set a clear deadline and a clear mechanism for raising comments. Manage the review actively — chasing responses is part of the process.

12. Resolve review comments. Address each comment and document your resolution. Some comments result in requirement changes; some are deferred to a later phase; some are rejected with documented rationale. Every comment should have a visible disposition.

13. Conduct a final quality review against the checklist. Before the document goes to sign-off, run it against a formal quality checklist. See the quality standards section below.

14. Obtain sign-off. Identify the authorised approvers and obtain formal sign-off. Sign-off means the document is baselined — it becomes the contractual definition of what the programme will deliver. Changes after sign-off follow a formal change control process.

15. Baseline and store the document. Store the signed document in the programme's designated repository with version control. Ensure the delivery team has access to the current baselined version.

Requirement writing rules

The way a requirement is written determines whether it can be implemented and tested. Poorly written requirements survive review because they sound reasonable. They fail in delivery because they are ambiguous. Apply the following rules to every requirement statement.

Use "must" for mandatory requirements. A requirement that says the system "should" do something or "will" do something is not a mandatory requirement. The word "must" is unambiguous. Reserve it for requirements that are genuinely non-negotiable.

Avoid vague qualifiers. Words like "fast," "easy," "robust," "user-friendly," and "scalable" are not requirements. They are wishes. Replace them with measurable specifications: "the system must return search results within two seconds for queries against a dataset of up to ten million records."

Write one requirement per statement. A requirement that contains "and" is probably two requirements. Splitting compound requirements makes them easier to test and easier to trace if scope changes.

Use active voice and identify the subject. "The system must..." or "The user must be able to..." — not passive constructions that obscure who or what is responsible.

Write for the reader who wasn't in the room. The developer implementing a requirement may not have attended a single stakeholder session. The requirement statement must be self-contained. If it requires a conversation to clarify, it is not ready.

A sample requirements table

Requirements should be documented in a structured table. Here is the standard format, with examples from a CDP programme:

The quality standard: two essential checklists

A BRD that passes stakeholder review but fails quality review is not ready for sign-off. Two checklists should be applied before the document is baselined.

Definition of Done — applied to each individual requirement:

• The requirement has a unique identifier
• The requirement uses "must," "should," or "could" consistently with its priority classification
• The requirement contains no vague qualifiers
• The requirement is testable — a pass/fail determination can be made without subjective judgement
• The requirement traces to at least one business objective
• The requirement has been validated with its source stakeholder

Final BA Checklist — applied to the document as a whole:

• All in-scope functional areas have requirements coverage
• Non-functional requirements (performance, security, compliance) are documented separately and completely
• All requirement conflicts have been identified and resolved or escalated
• Dependencies between requirements are documented
• All requirements have acceptance criteria
• The document has been reviewed by both business stakeholders and the delivery team
• All review comments are resolved with documented dispositions
• The authorised approvers are identified and have confirmed they are ready to sign off

The principle that governs all of it

The BRD is not a place to impress with volume. It is a place to remove ambiguity.

If a requirement can be read two ways, it is not ready. If a delivery team must guess what the business intended, the requirement has failed — not at implementation, but at the point it was written.

This means the BA's job is not to document everything that was said. It is to transform what was said into statements that are clear enough to build from and precise enough to test against. That transformation — from stakeholder language to implementation-ready requirements — is the core technical skill of business analysis.

The procedure above is what makes that transformation systematic rather than dependent on individual judgment. Apply it consistently, and the documents you produce will be reliable. Reliable documents make reliable programmes. That is the business case for doing this work well.

AI Workplace Simulator

Stop describing what you know.
Start showing what you can do.

30 days. 26 verified deliverables across the Junior and Intermediate BA tiers. A portfolio employers can inspect.

More from the blog