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 that 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.
More Posts- Software Requirements Document – PurposeI 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 [...]
- Tere Bina – Nusrat Fateh Ali KhanThe genius of his master’s voice.
- Career advice for people on top!Well getting on top is tough. But what happens when you get there? There are instances in life where you can get to the top very fast. So you are working for a start up. Within a couple of years you proved yourself to be one of the top performers. What next? So you started [...]
- User StoriesUser Stories are stories narrated by users about how an application or parts of application should function. Enhancements It is comparatively easier for users to write User Stories when they ask enhancements to an existing application. For example while asking for enhancements for Microsoft Outlook, a user may ask for more fields in the address [...]
- Thoughts are things“Thoughts are things” Napoleon Hill once wrote. Like bricks and steel and mortar that make buildings. Just like a brick which is red, shatters when dropped and weakens in water, thoughts have properties. Anger subsides after shouting, encouragement strengthens resolve, love reduces stress and ambition reduces love. And to observe one’s thou […]
- Software Release NumberingAll softwares come with release number. Here is how I think it can be numbered. Every release will be denoted by a four digit release number of the format A.B.C.D where A = Application Life Cycle Number This number is a function of the number of complete Software Development Cycles the application has witnessed. One [...]
- Rainy DayIt is eight o clock in the evening. I am walking out of my house. I climb two stories down and step in between the gates of my building. I open my umbrella. It is raining. A pond of water has collected just in front of my house. I step into it. It is a [...]
- Anjane Raho Mein – Lucky AliOne my favorite Lucky Ali songs
- Fleetwood MacFleetwood Mac was a great band. One of my favorites. Take a look at some of my favorite numbers from them.
- RAStik Feature TourWell, we just finished work on a Project Management System for Registered Accessibility Specialists in Texas USA. It was exiting thing to work for. Just take a look at the features.
- Software Requirements Document – Purpose
August 28, 2008 at 7:26 pm
I’ve been thinking about what requirements documents are used for and came up with only two points:
- Teach
- Proof
Teach is more or less the same as your point 1. Except that it assumes that the project sponsor knows his business, while others need to learn it. To some degree it also explains point 2 – the document helps designers, because they have to learn the business.
And with proof I mean, that the document is used by both to proof that what THEY did is right. The developers to proof what they did is what was written down. The project sponsors to proof that the software doesn’t do what was written down.