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.