Trying to decide what goes into the BRD and what goes into the SRS can be a difficult task.
Here, I provide some guidance on how to make the judgment call.
This video gives you a solid understanding of the difference between Business Requirements versus Software Specifications.
Understand these differences to determine what goes in your Business Requirements Document (BRD) and what goes into your Software Requirements Specifications (SRS).
In some companies the Software Requirements Specifications (SRS) are also known as Functional Requirements Document (FRD), depending on the company you work for.
A Common Challenge Among New Business Analysts
How do I decide what goes into my functional requirements document and what goes into my Business Requirements document?
You may be looking for an easy answer to this question, but unfortunately, an easy answer does not exist. As an analyst, you have to be prepared to make many judgement calls based on your understanding of the situation, and BRD vs. SRS is one of those judgement calls.
The hallmark of an experienced business analyst is to stop relying on things like templates and standards that might come from the IIBA (International Institute of Business Analysis) or the PMI (Project Management Institute) because you see how things actually work inside your company over time and with experience
When deciding whether something is a requirement or a specification, you must consider the Level of Detail.
Requirements & Specifications Are Documented at 3 Levels of Detail
Level 1: Client / Customer Level
Your client or customer is the primary audience (depending on the company you work at) and is the broadest level of detail.
At the client level, you’re talking very broadly about bullet point level of what it is that the project is going to produce.
So you’re BRD could be a simple couple-of-page document that basically outlines at a very high level what it is that the project’s going to deliver.
If you’re working inside a company the person on the business side of the company who’s funding the project is the client (or the customer)
Level 2: User / Operational Level
Clients will direct you to the right people within their organization, the people who deal with the issues on a day-to-day basis. In most cases, the client who’s funding the project is not going to be in your requirements meetings.
The user-level includes the person who typically is the user of the system that you’re putting into place and they’re the person that works at the operational level to make sure that the client’s area of business functions properly.
This means user level details can be split into the BRD and the SRS (FRD) because the operational people understand system logic in a very clear way.
The BRD is really the contract between the business side and the I.T. side. You include functional specifications in the BRD. You don’t have to ask the client to necessarily to read it all, but the client/customer will have to rely on their operational stakeholders to validate that what’s written in the BRD is right.
Level 3: Developer / IT Level
The level of detail that you need in your requirements and specifications is a grueling and excruciating level of detail. The developer needs to be able to make sure that they can write the code to satisfy the requirement.
This level of detail is almost always what goes into your functional requirements document or software requirements specifications.
WHEN TO INCLUDE DEVELOPER LEVEL DETAIL IN YOUR BRD (2 RARE INSTANCES)
There are two rare instances that functional specifications or software requirements specifications should be included in your business requirements document:
1 – UNDER TIGHT TIME CONSTRAINTS
- You have a lot less time than you need to actually produce requirements and specifications.
- Produce one single set of documents that contains both requirements and specifications.
- You don’t make the difference between functional specifications and business requirements.
2 – “THE BUSINESS” IS ADAMANT
The second rare instance the BA includes software specifications in a BRD is when the folks on the business side are so savvy and adamant about knowing the details.
The business folks want you to include that builder level (developer level) detail in your BRD documents for your business customers to sign off on.
There Should Be No Debate
So what is a business requirement versus a functional specification (software requirement specification)?
no amount of philosophical debate will solve this that problem
The answer is there is no standard. You shouldn’t rely on external standards to dictate to you what goes into your business requirements or your software specifications document. You have to learn to make that judgment call based on the level of details and based on the norms of the organization or the client that you`re trying to satisfy.
This was very helpful! How do you define the difference between “system” requirements and “user” requirements? I know there is a distinction (something the system does v. something the user does or expects to be able to do), but I find this can be a gray area as I don’t see a standard way to define them. I have seen some thought on how it’s written being the defining piece. What do you suggest?
Thanks Nicki.
It’s definitely a gray area, and there really is no one standard to follow. This means that you have to make sure you can use an approach that works best with your company’s requirements process (if they have one).
When I’m at the beginning of the project, I distill all the business requirements conversations I have with the client/user(s), into a set of functional points that the solution is expected to deliver.
For example, “The user requires the ability to….”, OR “The system is required to…”
These functional points always describe what a user wants to do, or what the client/user expects the system to do. Coming up with this list of functional points usually involves a good amount of TO-BE process design work, and some high level solution architecture work.
At the requirements elaboration stage, I choose the best tool to express the type of requirement I’m trying to express.
For example, “The user requires the ability to…” functional point will likely get elaborated through Use Cases and Wire frames.
“The system is required to …” functional point will get elaborated with the tool that best suits the system function (e.g. If the system is expected to calculate something, then likely pseudo-code, or truth tables, or business rules. If the system is expected to execute a workflow, then likely state machine models etc…).
Do you think that this functional points + elaboration approach might work for you?
Long time video with no answer to the main point. i hate those who was just want to talk around without any benefits.
Hi Ahmed,
You may be looking for an easy answer to this question, but unfortunately, an easy answer does not exist. As an analyst, you have to be prepared to make many judgement calls based on your understanding of the situation, and BRD vs. SRS is one of those judgement calls.
In this video, I’ve provided some of the critical factors that will help you decide whether something is a BRD or an SRS for the specific situation you will likely face in your BA career.
I will be providing examples of requirements and specifications in the training program that is currently under development. Please feel free to sign up to our email list if you’re interested in seeing these examples.
Best wishes.