Software Requirements Document – Purpose
I have been reading the book: Agile Software Development by Alistair Cockburn
It is a truly interesting book that first speaks about the role of communication in Software Development, how critical communication is for the success of any software project, how all communication is imperfect and how we still manage with it. Here is an interesting extract from the book about Software Modeling or Software Specs. refuting the principle that software development is only about “model building” Alistair says:
Some successful project teams have built more and fancier models than some unsuccessful teams. From this people draw the conclusion that more modeling is better. Some successful teams have built fewer and sloppier models than some unsuccessful teams. From this, other people draw the conclusion that less modeling is better. Neither is a valid conclusion. Modeling is a part of team communication. There can be both too much modeling and too little modeling. Scrawling on napkins is sufficient at times; much more detail is needed at other times
I feel that while making Software Specifications beautiful and accurate we fail to see what purpose of the document is in the first place. I have written quite a few Software Specifications. Every document begins with the section “Purpose” where the purpose of the document is written. Here is an extract:
“The purpose of this document is to establish clarity between the development team and the project sponsors for the project that is under consideration. The document will strive to remove all ambiguity on what the deliverables are. This document will enumerate and discuss all the various features this software will bring to its users. If there are multiple user categories, the document will discuss each of them individually. Wherever possible a pictorial representation of the user interface is made to aid the understand of the user. However, these interfaces are subject to changes if the development team finds better alternatives.
This document will also aim to give the developers access to the exact software requirements. This document does not contain any implementation details but only the functional requirements of the application. However an effort will be made to present the requirements in a format so the development team finds it easier to implement.
Further, the document aims to furnish enough detail to the application architects and leads to prepare detailed use-cases and therefore make development schedules and release plans for the entire application.”
The above extract brings three main objectives of software specs into the foreground:
- Bring clarity between the development team and the project sponsors on the exact deliverables
- Help the designers develop a good design serving the requirements
- Help in making development schedules and release planing
These three, I believe are the core objectives of the requirements documentation.
