The Purpose and Characteristics of a Software Requirements Specification

The Purpose behind a Software Requirement Specification (SRS)

If an SRS is written well, it will serve the following purposes

Feedback to the Customer

The software requirement specification assures the project management stakeholders and client that the development team has really understood the business requirements documentation properly. This also provides confidence that the team will develop the functionality which has been detailed.

Breaking the Requirements Down

The Software Requirement Specification is documented in such a way that it breaks the deliverables into smaller components. The information is organized in such a way that the developers will not only understand the boundaries within which they need to work, but also what functionality needs to be developed and in what order.

These two points are particularly important in the process of software development. If your development team do not understand that there are certain constraints on their work, as for example the code must be tightly written so that it will compile and run quickly, then you will run into problems later on when the code might deliver the functionality required, but no one will ever see it because it takes so long to load!

Understanding what order the functionalityy will be developed in means that the developers have the "big picture" view of the development. This gives them an opportunity to plan ahead which saves both project time and cost.

Facilitating other Documentation

The SRS forms the basis for a load of other important documents such as the Software Design Specification.

Product Validation

It basically helps in validating with the client that the product which is being delivered, meets what they asked for.

Characteristics of a Software Requirement Specification

1.0 Accuracy

This is the first and foremost requirement. The development team will get nowhere if the SRS which will be the basis of the process of software development, is not accurate.

2.0 Clarity

SRS should be clearly stating what the user wants in the software.

3.0 Completeness

The software requirement specification should not be missing any of the requirements stated in the business requirements documentaton that the user specified.

4.0 Consistency

The document should be consistent from beginning till the end. It helps the readers understand the requirements well.

5.0 Prioritisation of Requirements

Software Requirement Specification should not simply be a wish list. The requirements should follow the order of priority and preference.

6.0 Verifiability

At the end of the project, the user should be able to verify that all that all the agred deliverables have in fact been produced and meet the project management requirements specified.

7.0 Modifiability

The SRS should be written in such a way that it can be modified when the development team and user feel the need.

8.0 Traceability

Each requirement stated in the SRS should be uniquely associated to a source such as a use case or interaction document etc.

---