Tuesday, April 16, 2013

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 (BRD) and Functional specification document (FSD) 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.
How do we make it easy and extend it with latest requirement gathering practices used in a framework like TOGAF?
How to make your BRD and specification easily imported to UML models and further to code's and be tracked back.

Concerns:-

Most of the time when we do requirement gathering, there is a good chance that outcome and discussions with stakeholders cannot be tracked back to the BRD.

What does this means?

  • This makes the agreed important stories to miss.
  • Missing such stories Lead's to scope creep.
  • This will further soar relationship between client and vendor.
  • Raising CR will be tricky in such scenario because of misaligned expectations and there is a good chance that the vendor has to do the story free.

What can be the reason?

This happens because the business requirement may not be crisp enough to bind client to an agreement.

A vague requirement descriptions in the requirement document and SOW leads to scope creep and missing business objectives.


Their is a good chance that the person who documented the requirement made view point as their point of concerns  rather than view 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?
  • Do I boggle up Interacting with Large number of stakeholders and documenting their concerns where some are agreed upon and some are not? 
  • How do I handle complex information and Process flow? 
  • How do I Keep track of all concerns raised by multiple stakeholders with the view points?
  • 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? 
  • How does my client sees 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?


  • How about if most of the documentation is based on simple principle of separation of concern?
  • 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?
  • 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 document’s 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?

If you try reading some of the article below you will be able to understand how important is to extend the current BRD templates and requirement gathering and documentation  practice? 

BRD should no more be considered just a document now but a Package.
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 raised 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 view points 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 till 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?

  1. This is what we usually miss The Abstraction The Generalization and The Specialization,How does my BRD answers to these and how?
  2. Do my use cases are well connected to platform (Business -> Technical) to deal with the matter of abstraction to specialization?
  3. How do we answer questions related to messages transferred in each use cases between platforms that we are going to built in and trying to realize further as a solution through our BRD.
  4. How can I derive the code out of my use case ? Generalization to specialization, My Platform ? Generalization to specialization building and correlating  components ports and interfaces and so one till the actual execution?
  5. 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 documents.

The 5V's are Validity, Veracity, Verbosity,Velocity and Versioning.
Are you a magician? No but Yes? come suggest how can we achieve it?







1 comment:

Anjani kumar said...

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

Recent Posts