Requirements Specification: The Weak Links



Most of us believe that Software Requirement Specification documents handed over to project teams enable them in designing, coding, testing and delivering the end product. We trust, in every project we get into, that the business analysts and user representatives collaborated well in order to create such documents. We must be positive and think optimistically. We must trust. We must believe. However, our positive thinking, trust and belief can take us only so far unless we do our homework right.

Yesterday, I was reading a paper titled, ‘What’s Wrong with Requirements Specification? An Analysis of the Fundamental Failings of Conventional Thinking about Software Requirements, and Some Suggestions for Getting it Right’ written by Tom Gilb. Tom is the author of nine books, and hundreds of papers on topics related to Software Engineering. He has been a keynote speaker at dozens of international conferences. He has delivered guest lecturers in universities all over the world.

In this paper, Tom has outlined ten key principles for creating successful requirements specification documents. He has provided very good examples to illustrate these principles. I found it very interesting as it helped me realize several weak links in the way we gather and specify requirements. Let me share a set of takeaways from Tom’s paper in this blog post. I encourage readers to download this paper (It is free! No registration required) and read it.

1) Check if requirements specification helps you understand the top level project objectives. Make sure that these objectives are not verbose and qualitative. They need to be detailed enough but fit into a single page. Tom says that a good first draft of the top ten critical objectives can be made in a day’s work assuming that the key management personnel are available for discussions.

The top level project objectives remain weak links if you are not able to translate these top level objectives into success criteria that can help you measure the success of your project.

2) Understand the value delivered to stakeholders by means of satisfying the specified requirements. More than the defined functionality or user stories, the value delivered is what counts. Traditionally, we are not used to considering value when we think about requirements specifications. The ability to prioritize requirements based on value delivery is critical. Product Owner (Scrum), Business Analysts, Marketing Managers, and Product Managers need to focus on this function. When you implement a requirement (or satisfy a requirement) validate if you are delivering value to stakeholders.

3) Quantify requirements. Qualitative descriptions or textual representation of requirements do not help. Quantification enables measurement. Measurement is necessary if you want to improve.

4) Specify the value you want to deliver to stakeholders clearly. Do not mix this up with how you want to achieve the value (the 'design').When you are able to specify your needs clearly, the solutions to your requirements will naturally follow. Do not let the solutions change your real needs.

5) Instead of focusing on each functionality, focus on system quality. Great products go to market because of this focus.

6) Make the specifications rich with several elements such as historical data, test data, scenarios, etc.

7) Inspections can help you improve the quality of requirements. So, consider Specification Quality Control (SQC).

Finally, requirements do change or evolve. If you spend lot of efforts in hardening all requirements in advance, it is probably a waste of energy. Embrace change!

When you read, Tom’s paper you will realize the weak links in the current state of creating Requirements Specifications. Also, you will get an opportunity to learn from his experience and thoughts!