Saturday, September 24th, 2016
Before starting any kind of software development, we need some requirements about the behaviour of the application. Today, the point is not to focus if it is possible to know exactly what we want or what we really need, nor even if we are defining these requirements before any development (traditional approach) or in every sprint (agile approach). The point now is how to define and write these requirements.
There are several options:
IEEE 830 software requirements specifications
The most distinguishing characteristic of an IEEE 830-style software requirements specification is the use of the phrase “The system shall …” which is the IEEE’s recommended way to write functional requirements. For example:
- ) The system shall allow a room to be reserved with a credit card.
- ) The system shall accept Visa and MasterCard cards.
- ) The system shall give the user a unique confirmation number.
It is a very formal description, very time-consuming, boring to read (medium-size of 300 pages) and moreover it is effectively impossible to write all of a system’s requirements this way.
A use case is a generalized description of an interaction between the system and an actor (a user or another system). For example:
Main Success Scenario:
1. Purchaser submits credit card number, date and authentication data
2. System validates credit card
3. System charges credit card full amount for all nights of stay
4. Purchaser is given a unique confirmation number
Sometimes, they include details of the user interface.
A scenario is a detailed description of a user’s interaction with a computer. For example:
A typical scenario may comprise multiple use cases.
A user story is a relatively small piece of functionality that will be valuable to the software’s users. For example:
“Users can see photos of the hotels.”
“Users can restrict searches so they only see hotels with available rooms.”
Users stories are written to facilitate release planning and to serve as reminders to fill in requirements details with conversations.
Summing-up: it is more important to think about users’ goals than to list the attributes of a solution. As the development methodologies have evolved from waterfall to agile, the software requirements specification has follow a similar way: user stories are compatible with iterative development and they place significant value on conversations between developers and users.