BRD: Blurred Requirements Document
The Business Requirements Document, or BRD, is a document name and acronym that comes up in IT projects several times a day.
BRD is prefixed with 'high level' or 'detailed', resulting in variations such as High Level BRD, BRD, and Detailed BRD. The question is: What is the standard for a BRD’s level of detail? Specifically, how high-level is high-level, and how detailed is detailed? The answer vastly depends on the capabilities of the Business Analyst (BA) or Document Author in requirements engineering—i.e., requirements elicitation, analysis, specification, validation, management, verification, and traceability.
The less experienced the BA is in requirements specification techniques, the fluffier the requirements. Objective statements, solution statements, and random ramblings are passed off as requirements. Note: The number of years a BA has held the Business Analyst job title has nothing to do with their competency in writing requirements.
The de facto standard is the author’s interpretation of a business requirements document, which may not align with the Project Manager’s expectations as an added level of complication. This disconnect often turns the trusted BRD into a deliverable tick-off exercise: completed on time yet unusable to downstream consumers.
Despite being a staple in enterprise IT projects, the BRD remains a continual challenge to define. Let's not contemplate a BRD template as a solution because section headings are often deleted when they are too difficult to complete. The remaining sections of a template, despite lengthy explanatory guides and examples, do little for content consistency due to projects and their participants inventing their own definitions to suit their capabilities. This lack of a standardised BRD definition or structure, i.e., non-adherence to industry standards and best practices, leads to poor requirements and with certainty, poor project outcomes in enterprise IT projects.
The table below demonstrates the ambiguity that frequently arises in defining and detailing requirements within IT project practices.
| Description | Perspective | Level of Detail | Deliverable |
|---|---|---|---|
| High level business requirements | * | * | High Level BRD |
| Business requirements | * | * | BRD |
| Detailed business requirements | * | * | Detailed BRD |
To align with recognised requirements and specification standards, a structured approach is needed. The table below outlines a proposed standard for defining business requirements at various levels:
| Description | Perspective | Level of Detail | Deliverable |
|---|---|---|---|
| High level business requirements | Enterprise | Business enterprise needs constrained by enterprise architecture | Input to business case, change request, or request for information |
| Business requirements | User | Business areas, employees, or operators constrained by business objectives | Stakeholder Requirements Document |
| Detailed business requirements | Functional, Non-functional | People, process, technology, and information requirements constrained by project or document scope | Solution Requirements Document |
If the above standard feels too complex, by all means, invent requirements document names and definitions that are agreed upon across the project stakeholders. However, let's not call every document in enterprise IT project delivery a BRD.
Reflection Points
- Do you implement a structured, standards-based approach to requirements documentation? Consider whether your approach adheres to recognised frameworks or best practices to ensure consistency and clarity in your requirements.
- Are project teams aligned on a standardised definition for BRDs and other requirements documents? Reflect on whether your teams share a common understanding of key deliverables, reducing miscommunication and improving collaboration.
- Are your BRDs structured to be usable by all project stakeholders, including business and IT teams? Evaluate whether your documentation effectively addresses the perspectives of all stakeholders, including business and IT teams.
