Archive for the ‘Agile’ Category
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.
User Stories
User 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 book. A user story could be “We need a secondary email address field in the address book”. In a good user story the user would also say how this new field be used. “And the application should try to email the secondary email if the first email fails.”
New Feature
When the user needs a feature that is absent in the existing application he can point to examples in other popular applications that do something similar. For example, “We like Gmail’s Search Email function. We would like to have something similar to search projects.” And follow it with some improvements if required. Like “And we would like to search based on Date of Creation or Estimated Date of Completion”
Original Idea!
When a suitable example does not exist, it is best to write down one’s thoughts as clearly as possible and discuss it with the developers as the story is being written. This way the users and the developers are more likely to understand each other.
