Tuesday, April 16, 2013

How to write good Business Requirement document? Ready to use BRD template to prevent Scope Creep following best of TOGAF.

How to write good Business Requirement document? Ready to use BRD template to prevent Scope Creep following best of TOGAF.

Note: - * this document is a research item so please ignore brevity and incompleteness.
Please comment so that I can add your specific experience here and make this post more usable. 
I have tried putting in a new perspective for writing BRD and Specifications 


Motivation:-
For small projects, Business Requirement Document (B.R.D.) and Functional specification document (F.S.D.) are often very simple and can be created easily as per the need.
While the current practices are good, they need extra care and mastery to be able to do quality requirement gathering.

  1. ·         How do we make it easy?
  2. ·         How do we extend it with latest requirement gathering practices used in a framework like TOGAF?
  3. ·         How to make your B.R.D. and specification easily imported to UML models?
  4. ·         How to track it further to codes and tracking it back to B.R.D and technical specification?
Concerns:-
Most of the time when we do requirement gathering, there is a good chance that outcome and discussions with stakeholders cannot be traced back to the B.R.D.
What does this means?

  • 1.       This makes the agreed important stories to miss.
  • 2.       Missing such stories Lead's to scope creep.
  • 3.       This will further sour relationship between client and vendor.
  • 4    Raising CR will be tricky in such scenario because of misaligned expectations with a good chance that the vendor has to do the story free.
What can be the reason?
Does this not happens because of the following:-

  • 1.       Business requirement may not be crisp enough to bind client to an agreement.
  • 2.       A vague requirement description in the requirement document and S.O.W. leads to scope creep.
  • 3.       Scope creep help’s in missing business objectives.
  • 4.       There is a good chance that the person who documented the requirement made view point as their point of concerns rather than view.
  • 5.       Making view point as concern allows missing multiple stakeholder concerns.
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. 
Will you not go through some of the challenges below?

  • 1.       Do I boggle up Interacting with Large number of stakeholders and documenting their concerns where some are agreed upon and some are not? 
  • 2.       How do I prioritize my stakeholder in current requirement?
  • 3.       How do I handle complex information and Process flow? 
  • 4.       How do I Keep track of all concerns raised by multiple stakeholders with the view points?
  • 5.       How do I Get away from scope creeps, missing requirements and unknown expectations which were never viable in the current constraints and ensure that we deliver what we sign off? 
  • 6.       How my client does see it as a clean delivery and he is happy?
How this write-up helps?
This write-up extends the BRD to handle most of the concerns by extending the traditional methods with the researches in TOGAF.
What a Business requirement document should extend to?
Ideally a BRD should contain what is there in the link below.
But this is not the end of the world.
Think about some of the concerns below?

  • 1.       How about if most of the documentation is based on simple principle of separation of concern?
  • 2.       How can we do documentation that supports contra variance and covariance so that it can be traceable from bottom to top and top to bottom?
  • 3.       How a BRD write-up does not remain a solo task but gives an option for collaborative requirement gathering by multiple subject specific experts?
  • 4.       How do multiple people can work/review on a single BRD, while linking back the entire documents to BRD is easy?
  • 5.       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?

If you try reading some of the article below you will be able to understand  on:-

  • 1.       How important is to extend the current BRD templates, requirement gathering and documentation practice? 
  • 2.       Why BRD should no more be considered just a document but a Package.
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.
Section
Sub Section
Header
Description
0
1
Heading
Heading of the Document
0
2
Index
Indexing and Book marks
1
0
Executive Summary
Less than 100 words explanation on what business scenario and solution this document covers?
2
0
Version Management 
Version details.
3
0
Approvals Reviews & Sign off
Revision and Sign off details.
4
0
Link to  Signed SOW
The BRD should contain a Link to SOW ideally it does not contain one. Depends on the level of access to involved parties.
4
0
Client Details
A short synopsis for the client and department that the BRD covers for.
5
0
Stake Holders
Who will be the Stake holders? Primary User's, Funding Partners, Approvers or Core entrepreneur's or all?
6
0
Stake Holder Power Grid
A grid deciding whose concern can be in To Do List and can be done? Items that can be     considered in future version and may be considered good to have.
7
0
Business Scenario
A grid showing and describing all the business scenarios rose from stake holders, their basic definition and detail explanation and link to separate document existing in the same BRD package.
10
0
Stake holder concerns and view point
All the concerns and View point gathered against a business scenario maintained in separate document however linked backed to BRD.
11
0
Business Objectives
Business objectives should be based on SMART [Specific Measurable Actionable Realistic Time bound]
12
0
Viewpoints to View Catalog
While viewpoints are vague Views are Concrete which actually forms the base of your requirement.
13
0
Gap Analysis Existing/Purposed view
GAP Analysis between Existing and Proposed. One can Ignore it for a new system.
14
0
Views to Process Catalog
Now it’s the need to extract concrete non duplicate view from the viewpoint after concerning the GAP analysis sheet.
15
0
Process and Environment Matrix
On what environment the Processes will be realized?
16
0
Actors
What will be the Actors at generic level? who will utilize and action on the views?
17
0
Functionality to Process Catalog
What will be the functional behavior of the system a Catalog connecting all the FSD.
19
0
Information Flow
Data Flow
20
0
Data Source Matrix
Data Sources External/Internal/upstream/downstream
21
0
Data Dictionary
Attribute and Entity dictionary connected with Data Source.
22
0
Business Rule Catalog
Data Validation rule
23
0
Technology
Technology that realizes the view
24
0
Limitations Feasibility/Viability Analysis
Feasible/Viable and version of the requirement and delivery.
25
0
Risk
Risk that may arises Time Cost and Scope wise
25
0
Assumption's
Any Assumptions taken that may get converted in to Risk?
26
0
Glossary
Terms

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.

As like BRD Functional specs should be extended to one as below:-
Area
Section
Subsection
Header
Description
1
0
Heading
2
0
Associated Processes
3
0
Index
4
0
Executive Summary
5
0
Version Management 
6
0
Approvals Reviews and Sign off
7
0
Link to  BRD
Function
8
0
Actors Power Grid
All the actors involved in FSD
9
0
Use Case
Written use case supported by Diagrams.
10
0
User Interface
Link to the UI design document till pixel level.
11
States
State flow
Data
12
0
Data Entities and Attributes
13
0
Relationships
14
0
Information flow back link
Link back to the area of information blow and see if there was a leakage?
15
0
Data dictionary back link
A link back to the section of Data dictionary 
16
0
Assumptions
17
0
Risk's
18
0
Glossary



Ah I wrote my BRD How Do It becomes a Synching Point between the technical staff and business?
This is what we usually miss:-

  • 1.        The Abstraction.
  • 2.        The Generalization.
  • 3.        The Specialization.
How does my BRD answers to these and how?

  • 4.       Do my use cases are well connected to platform (Business -> Technical) to deal with the evolution from abstraction to specialization?
  • 5.       How do we answer questions related to messages transferred in each use cases between platforms that we are going to build in and trying to realize further as a solution through our BRD?
  • 6.       How can I derive the code out of my use case? Generalization to specialization and the Platform they are built on?
  • 7.       Generalization to specialization building and correlating components ports and interfaces and so one till the actual execution?
  • 8.       How do I back track each of this till the BRD?

Conclusion
This paper tries to make you understand the way to utilize the powerful 5V’s, TOGAF and UML while you write business and technical specification documents.

The 5V's are Validity, Veracity, Verbosity, Velocity and Versioning.

Are you a magician? No? But Yes? Because your experience in this area can suggest the world on how better can we achieve it?


4 comments:

Anjani kumar said...

Please comment as your comments and experience will help me improve this topic...

balachandar k said...

the definition you gave is good....
if any downloadable sample document is attached mean more useful ....

Anonymous said...

https://www.facebook.com/myfolkstore

Anonymous said...

Buy %E0%A4%B8%E0%A4%A4%E0%A5%8D%E0%A4%A4%E0%A5%82 Online
http://www.myfolkstore.com/category/%E0%A4%B8%E0%A4%A4%E0%A5%8D%E0%A4%A4%E0%A5%82
Buy Sattu Online
http://www.myfolkstore.com/category/consumables

About Sattu
http://www.myfolkstore.com/category/consumables
%E0%A4%B8%E0%A4%A4%E0%A5%8D%E0%A4%A4%E0%A5%82
http://www.myfolkstore.com/category/%E0%A4%B8%E0%A4%A4%E0%A5%8D%E0%A4%A4%E0%A5%82
I) Buy Folker Jeans

http://www.myfolkstore.com/category/jeans-trousers-for-men

J) Gift Organic and Darjeeling Tea.
http://www.myfolkstore.com/product/lopchu-tea-golden-orange-pekoe
k)Buy organic rice
http://www.myfolkstore.com/category/organic-food
l)Buy dinner Set
http://www.myfolkstore.com/category/home-and-kitchen

Recent Posts