Business requirement specification document?

Following question was raised in one of the forums on LinkedIn.

What do you expect to see in a business requirement specification document?

Here is what my reply was:
As per the 2003 metagroup report (later on metagroup was acquired by Gartner), 60-70% of the projects fail because of poor requirement gathering. In other words these projects fail because the Business requirement specification documents do not describe what they are supposed to. Or may be this is what happens
- SRS is written the way customer described the requirement
- Project manager reads this document and understands it in his own way
- Architects take inputs from project manager and SRS document and design it in their own way
- Programmer takes the design documents as inputs and program it in their own way

At all the above mentioned stages humans are involved!

Humans involved?
Two different people would understand and interpret a document in a different manner. This happens to requirement specification documents and therefore to software being developed rarely meets customer’s need.

Keep in mind that the customer does not want software. Customer needs a system which would help him in solving a business problem. It is always hard to articulate on paper what type of software would help customer.

More statistics – On an average 20% of the features described in SRS document would carry more than 80% of business value. Why not work on these 20% features first? How to come to know about those features? Would customer involvement help?

In most of the cases customers too do not know what they want. But because they have only one chance to mention (through SRS), they would write about everything which might be helpful even if not mandatory. Most of these features are nice to have but not must have.

Most of the time, when we look at SRS document, it looks like these requirements are fixed, while should not be so… Requirements evolve with time and there SRS document should not be written in blood.

Customer collaboration?
For me, the more than SRS document, involvement of customer (or customer representative) is important who can really keep a check on whatever is being developed is usable. This involvement should be from the beginning because changes at a later stage are difficult to absorb.

It is better to have SRS document having clarity of user stories which can be evolved by the continuous involvement of product owner. On high level, product owner would be responsible for the following:

- He would be the voice of the customer
- He would describe, prioritize and refine the requirements continuously
- He would be with the team and would ensure that the development team understands his (or customer’s) needs
- He would be responsible for the ROI and release plan

Opps, I gave the discussion a totally different direction but I thought to mention what came to my mind.