Evolution of Software Requirements Specification

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:

  1. ) The system shall allow a room to be reserved with a credit card.
    1. ) The system shall accept Visa and MasterCard cards.
    2. ) 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.

Use Cases

A use case is a generalized description of an interaction between the system and an actor (a user or another system). For example:

Use Case Title: Accept reservation for a room
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.

Scenarios

A scenario is a detailed description of a user’s interaction with a computer. For example:

Maria logs in with her username and password in our website. She want to find a four-star hotel near downtown with a lap pool. She searches for and finds a few hotels that match. She selects the Royal National Hotel. She selects a standard room and enters her credit card information and reservers a room for three nights next month.

A typical scenario may comprise multiple use cases.

User stories

A user story is a relatively small piece of functionality that will be valuable to the software’s users. For example:

“A room can be reserved with a credit card.”
“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.

the place for my daily writing
Write down every day the things that are important for you, your feelings, your progress, your tasks done and access to them everywhere you are, easily and fast.
sign up free 

Leave a Reply

Your email address will not be published. Required fields are marked *