What do you need to write a great BRD?
For small projects, Business Requirement and Functional specification document are often very simple and can be created easily as per the need. While the current practice is good, they need extra care and mastery to be able to do the quality requirement gathering with granular traceability linking right from statement of work to actual deliverables.
When you start writing Business requirement document you have a big responsibility of working on the correct requirement stories with a story telling ability that answers below questions: -
· How do you make it easy for reading and implementation?
· How do you extend it with latest requirement gathering practices?
· Is there a way you utilize a framework like TOGAF?
· How to make the B.R.D. and specification easily imported to UML models?
· How to track it further to codes and tracking it back to B.R.D and technical specification?
· How to create a document which has Traceability, Validity, Versioning, Veracity, and Velocity.
Most of the time when you do requirement gathering and start writing down the business requirement into delivery stories, there is a good chance that you have a great amount of delta between what you estimated and agreed to deliver to what is actually delivered.
-: What does this mean? :-
· This makes the agreed important stories to miss.
· Missing such stories Lead's to scope creep.
· This further sour's the relationship between client and vendor.
· Raising the C.R. become tricky due to misaligned expectations with a good chance that the vendor later has to do the story free or the business relationship ends into a legal battle.
-: What can be the reason? :-
· Business requirements may not be crisp enough to bind a client to an agreement.
· A vague requirement description in the requirement document and S.O.W. leads to scope creep.
· Scope creep further resists meeting business objective.
· There is a good chance that the person who documented the requirement made view point as their point of concerns rather than view.
· Views are closed and written articulation of a viewpoints shared by multiple stake holder prioritized through stake holder power grid.
-: When it comes to understanding human thought, is it simple? -
Think about the complexity while dealing with large number of stakeholders when one has to handle multiple business scenarios connected to each other.
· Do you boggle up Interacting with Large number of stakeholders and documenting their concerns where some are agreed upon and some are not?
· How do you prioritize your stakeholders in current requirement?
· How do you handle complex information and Process flow?
· How do you Keep track of all concerns raised by multiple stakeholders with the viewpoints?
· How do you Get away from scope creeps, missing requirements and unknown expectations which were never viable in the current constraints and ensure that you deliver what you sign off?
· How can you ensure clean delivery?
-: How should you ideally write it? :–
-:To understand let’s think it this way.:-
· How about if most of the documentation is based on simple principle of separation of concern?
· How can you do documentation that supports contra variance and covariance so that it can be traceable from bottom to top and top to bottom?
· How a BRD write-up does not remain a solo task but gives an option for collaborative requirement gathering by multiple subject specific experts?
· How do multiple people can work/review on a single BRD, while linking back the entire documents to BRD is easy?
· How do one take the CRUX of all requirement to SOW and detail it well in to multiple Functional Requirement Document all linked and traced to BRD and SOW?
This is why you should no more consider BRD being a document but a Package. A package which can be created at one place, worked by multiple people, but the output can be rendered through its stake holder view points and need.
What an Ideal BRD should extend to?
An ideal BRD for today should have the below section which can be linked further to their detail document which contains write-up, Catalog, Matrix and Diagram.
As the BRD will contain multiple catalogs, so multiple checklist/matrix/grids/documents are needed to support it.
Some of them would be: -
- 1. Base BRD.
- 2. Functionality linked through Functional Specification connected to sections in BRD.
**To understand few of the suggested terms you can try reading
· Stake holder Grid
· Stake holder and Their Concerns
· Concerns and View points
· Data Dictionary
· Gap Analysis
· Business Process
· Smart business objective
How can the document be made to be worked as a package?
**Note: FSD and technical document are intentionally not detailed here.
This is what you usually miss: -
How does my BRD answers to these and how?
· Do the high-level use cases will be easily correlated when the platform is being designed later in the discovery cycle?
· How to depict create and deal with the evolution from generalization to specialization, abstraction to derived and further to realization via object. Further these objects have activities leading to use case state sequence and activity diagram.
· You have to make sure that whatever you design and write has an easy extension and inclusion keeping in mind that you are not diving too much deep at BRD
· How do you answer questions related to messages transferred in each use cases between platforms that you are going to build in and trying to realize further as a solution through our BRD?
· How can you build a technical use case from business use case, and further build an application platform?
· How do you Generalize building and correlating components ports and interfaces to realize platform?
· How do you back track each of this till the BRD?
This paper tries to help you understand the concept of the powerful 4V’s, TOGAF and UML while you write business and technical specification documents.
**The 4V's are Validity, Veracity, Velocity and Versioning.