Where is the Requirement Document?

This blog is on an obvious topic. But for those who are still using a Requirement Specification document it can be an interesting read.

When I started with my first project in year 2001 we had a 200+ pages SRS - System Requirements Specifications document. Till year 2007 I worked on several large projects/products and each had a fairly huge Requirement document.

Few months back during a conversation I realized that I have not seen a SRS document from year 2007. These projects were much larger and were Enterprise scale with geographically distributed teams. So, then what happened to the Requirement Document? What led to collapse of Requirement document and what replaced it?

Giving it a thought I think a shift to agile methodology provided clients the flexibility to change the requirements. Maintaining requirement documents along with code with short iterations is a tough job and often the effort would go waste when requirements would evolve or change in subsequent iterations. Following drawbacks of keeping requirements in a document were evident:

• Frequent changes require revisiting entire related requirements. Relating requirements in a document was not an easy task either.
• Changes in Requirement would affect not only code, but Technical design document, test cases document, etc. and keeping traceability between Requirements and these artifacts is not again an easy task that can be accomplished via documents.
• Change to Requirements also affects Project plan and getting a real time report for this required a lot of efforts

Clearly, evolved the need for a tool sophisticated enough to accomplish above tasks. There are several tools available in market that would capture the requirements in form of User Stories and then link test cases to these along with any technical design and could also link code committed to a particular user story. Requirements could be categorized, prioritized; defects could be associated with Requirements. These tools would also integrate the estimates to accomplish the change and provide on-demand and live reporting with most features entailing entire Software Development Lifecycle. When required, the tools will filter the data as desired and export it in many different formats.

  

This tool completely replaced the need for a requirement document.

But does it mean that requirement capturing techniques like conducting workshop, interviewing clients, use case diagrams are also out of picture. Answer to this is a big NO. Requirement capturing is THE most important aspect of the project as this is the way you define and redefine what the end user actually need. Only that you document the requirements in a tool which allows traceability and visibility than using a stale document which will become obsolete by the next iteration.

Closing this blog, I also recall that I have not seen a Technical Design document from Year 2007 onwards. Few important very complex things where various components are interacting did require some sort of technical design document, but then I did not see a Tech design for many complex functionalities. A self-organizing strong team would infer the design from the code. So, code is the only documentation we had from a long time now. Do you also work in similar pattern these days? Do you like it? Probably this will need another blog to talk about this.