If you have landed on a waterfall project and someone has handed you a project plan with milestone dates against deliverables like “BRS”, “functional spec”, and “business case”, you need to know exactly what goes in each one and in what order. Business analyst deliverables in waterfall are well-defined, sequential, and interdependent. Getting them wrong, or producing them in the wrong order, causes real downstream pain. This article gives you the practical structure for each of the five core deliverables so you can start producing them immediately.
The Five Core BA Deliverables and How They Fit Together
Before getting into the detail of each document, it helps to understand the sequence. Waterfall is linear by design. Each deliverable builds on the last, which means a weak approach plan produces a weak business requirements specification, which produces a weak business case. The table below shows the five deliverables, their position in the sequence, and their primary purpose.
| Deliverable | Sequence Position | Primary Purpose |
|---|---|---|
| Business Analysis Approach Plan | 1 | Defines the strategy, scope, stakeholders, and how requirements will be gathered |
| Business Requirements Specification (BRS) | 2 | Captures what the business needs, independent of any technology platform |
| Business Case | 3 (sometimes 2a) | Financially and strategically justifies the proposed solution |
| Functional Specification | 4 | Details what the system must do at a feature and function level |
| Non-Functional Specification | 5 (often combined with 4) | Defines quality attributes, constraints, and technical requirements |
Deliverable 1: Business Analysis Approach Plan
This is the document that tells everyone, including your project manager, sponsor, and fellow analysts, what the BA effort will look like before any requirements work begins. I treat it as the contract between the BA and the project. It keeps the scope of the analysis effort honest and gives you something to refer back to when scope creep starts, which it always does. You can find a detailed guide to writing this document at How to Write a Business Analysis Approach Document.
The key elements to include are:
- Background and purpose. A brief description of why this project exists and what problem it is intended to solve.
- Business drivers. The strategic or operational reasons behind the initiative, which will later shape your high-level requirements and scope boundaries.
- Problem statement. A grounded, practical description of the current problem using real business examples, not abstract language.
- Vision. An aspirational but bounded statement of what the organisation wants to achieve as an outcome.
- Scope. What is in scope and, critically, what is explicitly out of scope. The out-of-scope list is just as important as the in-scope list.
- Dependencies. Links between this project’s tasks and tasks in other projects or workstreams that affect sequencing or delivery.
- Key roles and responsibilities. Who is accountable for what across the project, not just on the BA side.
- Stakeholder engagement plan. A list of stakeholders you will consult, what you need from each of them, and how you plan to engage them.
Deliverable 2: Business Requirements Specification
The business requirements specification (BRS) is the backbone of the entire analysis effort. Everything that follows it, the functional spec, the non-functional spec, and the technical design, traces back to what is documented here. The requirements in a BRS are platform-independent. They describe what the business needs, not how a system will deliver it.
The BRS builds on the approach plan and should contain:
- Refined business drivers and problem statement. By the time you are writing the BRS, stakeholder consultation will have sharpened your understanding. Update both sections accordingly.
- Stakeholder model. A structured view of the internal roles and external actors who interact with the system or process being changed.
- Business domain model. A high-level structural representation of the key business objects and their relationships within the problem domain.
- Business use cases. The functional areas of the business that will be modelled, expressed as discrete interactions between actors and the business.
- Business activity diagrams. Behavioural representations developed for each business use case, showing the flow of activities and decision points.
- Business requirements. The actual requirements, written to be platform-independent, traceable back to the use cases, and relevant to the defined scope.
For a detailed look at how business requirements differ from functional requirements, and why that distinction matters enormously in waterfall, see Business Requirements Document vs Functional Requirements Document.
Deliverable 3: Business Case
My preference, built up over many years of waterfall delivery, is to write the business case after the BRS, not before. The reason is straightforward: until you have done the requirements work, you do not have the tangible evidence you need to calculate real benefits. You are guessing at numbers rather than grounding them in what you have discovered. Once I have documented the current state in detail and mapped out the future state, I can attach real figures to things like manual processing time saved, error reduction rates, or compliance risk avoided.
That said, I have worked on projects where the business case was required before full requirements were in place, typically where executive sign-off was needed just to fund the BA work itself. In those situations, I flagged the assumptions clearly and built in a review point once the BRS was complete.
A solid business case includes:
- Background. The context and purpose of the business case, distinct from the BRS background, focused on the decision being sought.
- Current situation and problem statement. A description of the problem and the risks of doing nothing.
- Options analysed. The alternatives considered and the key findings from comparing them.
- Recommendation. What the approvers are being asked to approve and fund.
- Costs and benefits. The financial and non-financial benefits of the recommended option, with a clear explanation of how each was calculated or estimated.
- Risks. Constraints, limitations, and risks associated with the recommended approach.
For a worked template and structure, Business Case Template: Structure, Examples and What Works is worth reading alongside this section.
A Worked Example: When the Business Case Became the Battleground
On a systems replacement project I worked on for Organisation A, a government agency replacing a legacy case management system, we completed the BRS first. That gave us solid data: staff were spending an average of 40 minutes per case on manual data re-entry between systems, and the agency processed around 1,200 cases per month. The maths made the automation benefit clear and defensible.
When we presented the business case to the investment committee, the CFO pushed back hard on the benefit figure. He argued that the time saved would not translate to headcount reduction and therefore should not be counted as a financial benefit. He was not wrong on the technical point, but he was applying a rule of thumb that would have gutted the case for change.
I had to go back to the sponsor and the operations manager and reframe the benefit in terms of capacity: the same team could process significantly more cases without additional resource, which directly addressed a backlog problem that was generating ministerial complaints. We shifted the framing from cost savings to capacity gain, reworked the costs and benefits section of the business case, and resubmitted. It was approved, but only because we had the BRS data to back every number. Without the requirements work done first, we would not have had the evidence to survive that challenge.
Deliverable 4: Functional Specification
The functional specification is where you move from what the business needs to what the system must do. This is a platform-dependent document. The requirements here are testable, tied to specific system features and functions, and written with developers and testers as the primary audience.
The key components of a functional specification are:
- System use cases. The specific functions or services the system will provide, traced back to the business use cases in the BRS.
- User requirements. Traceable requirements written from the perspective of the end user interacting with the system.
- System activity diagrams. Behavioural diagrams that describe the interactions between actors and the system at a process level.
- Class diagrams. Structural representations of the system’s domain concepts, showing relationships between entities and traced back to use cases.
- Functional requirements. The specific, testable requirements for system behaviour, tied to defined functions and platform constraints.
Deliverable 5: Non-Functional Specification
Non-functional requirements are the ones that most often get left vague or bundled into a table at the back of the functional spec. In my experience, that approach causes expensive rework later, particularly on security and performance. Every non-functional requirement should be associated with specific project functionality, not floating free as a general statement.
The categories to address in a non-functional specification are:
- Hardware requirements. Specific hardware type, brand, specifications, size, and security considerations relevant to the solution.
- Software requirements. Whether software is to be built or bought, coding language, version requirements, data and interface requirements, and security standards.
- Performance requirements. Cycle time, transaction speed, reliability targets, minimum acceptable bug counts, and utilisation thresholds.
- Supportability requirements. Coding standards, naming conventions, maintenance access requirements, and required utilities for ongoing support.
- Security requirements. Security audits, cryptography standards, user authentication and authorisation, and resource utilisation controls.
- Interface requirements. Protocol management, directory services, message types, error handling, buffer management, and scheduling.
- Availability requirements. Hours of operation, required uptime levels, impact of downtime, and support availability windows.
- Compliance requirements. The existing regulatory and compliance environment as it applies to the solution being built.
For a deeper treatment of non-functional requirements and how to avoid the most common mistakes, see Non-Functional Requirements: Why BAs Get Them Wrong and How to Fix It.
A Note on Format and Terminology
In practice, functional and non-functional specifications are frequently combined into a single document. Whether they are separate or combined depends on the organisation, the project, and occasionally the preferences of whoever is reviewing them. The same applies to terminology: what one organisation calls a business requirements document, another calls a business requirements specification, and a third may use terms that bear little resemblance to either. Before you start producing any of these deliverables on a new engagement, spend time with the client to confirm exactly what they expect each document to contain. Assume nothing. I have wasted weeks on projects where I produced a beautifully structured BRS only to discover that the client’s definition of “business requirements” included system-level functional detail, which they expected in the same document.
If you are comparing waterfall deliverables with what is produced in an agile context, Business Analyst Deliverables in Agile covers the equivalent outputs and how the two approaches differ in practice.
The five deliverables covered here form a coherent, traceable chain from problem to solution. Each one depends on the quality of what came before it. Getting the approach plan right makes the BRS easier. A solid BRS makes the business case defensible under scrutiny. Detailed functional and non-functional specifications give development and test teams what they need to build and verify the solution correctly. The discipline of waterfall is that you cannot skip or rush any link in that chain without the weakness surfacing somewhere further down the line, usually at the worst possible moment.
Frequently asked questions
What are the main business analyst deliverables in a waterfall project?
The five core deliverables are the business analysis approach plan, business requirements specification, business case, functional specification, and non-functional specification. Each builds on the previous one, so the sequence matters as much as the content. In practice, organisations may combine some of these or use different terminology for the same documents.
What is the difference between a business requirements specification and a functional specification in waterfall?
A business requirements specification captures what the business needs in platform-independent terms, while a functional specification describes what the system must do at a feature and function level. The BRS is written for business stakeholders and analysts, whereas the functional specification is written with developers and testers as the primary audience. Requirements in the functional specification are testable and tied to specific system behaviour.
Should the business case come before or after the business requirements document in waterfall?
My preference is to write the business case after the business requirements specification, because the requirements work surfaces the evidence needed to calculate tangible benefits accurately. Writing the business case first means relying on estimates rather than grounded data, which makes it harder to defend under scrutiny. That said, some organisations require a high-level business case to secure funding for the BA work itself, in which case assumptions should be clearly flagged.
What goes in a non-functional specification for a waterfall project?
A non-functional specification covers hardware requirements, software requirements, performance targets, supportability and maintenance needs, security requirements, interface requirements, availability and uptime requirements, and compliance obligations. Each non-functional requirement should be linked to specific project functionality rather than written as a general statement. Vague non-functional requirements are one of the most common causes of expensive rework in waterfall delivery.
How does a business analysis approach plan differ from a project plan in waterfall?
A project plan covers the full project scope including delivery, resources, and timelines across all workstreams. A business analysis approach plan is specifically scoped to the BA effort: it defines the strategy for requirements activities, identifies stakeholders, sets the scope of the analysis, and outlines how elicitation will be conducted. It is the BA’s planning document, not a substitute for the project plan.
Try Ash, Your Virtual BA
If you are working through any of these five waterfall deliverables right now, Ash can help you structure and draft them. Whether you need to produce a business requirements specification, build out a business case with traceable benefits, or write defensible non-functional requirements, Ash is built specifically for BA practice and knows exactly what belongs in each document. You do not need to start from a blank page. Try Ash Virtual BA and get your next deliverable moving today.
Further reading
- IIBA | BABOK | A Guide to the Business Analysis Body of Knowledge®
- Business Analysis Blog | Business Analysis Planning and Monitoring | Learning BA Planning Skills | IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.