How to Write Software Requirements Specifications

I N T R O D U C T I O N

Requirements collection is crucial to the development of successful information systems. To achieve a high level of IS quality, it is essential that the SRS be developed in a systematic and comprehensive way. If this is done, the system meet the user's needs, and will lead to user satisfaction. If it is not done, the software is likely to not meet the user's requirements, even if the software conforms with the specification and has few defects.

How to Write Software Requirements Specifications is an easy to use, step-by-step guide to developing high quality, effective SRSs. It prescribes both the format and content of the Software Requirements Specification (SRS).

How to Write Software Requirements Specifications is basically a 'plain English' version of the 1998 release of IEEE Std 830 Guide to Software Requirements Specifications [ANSI/IEEE Standard 830-1998], but with added features to enable project staff with average literacy skills to effectively develop a SRS.

Any Software Requirements Specifications prepared in compliance with this How To guide will therefore also comply with IEEE Std 830.

The SRS has business and technical considerations added which the customer may or may not be able to provide in the original Requirements List. The SRS provides all relevant detail about the proposed system to enable a development team to commence the design/development phases.

V I E W   C O N T E N T S

Click here to view the complete   Table of Contents & Representative Content (Section 2).   This gives you an indication of the scope and level of detail of this document, plus representative content of the actual document.

A B O U T   T H E   A U T H O R

How to Write Software Requirements Specifications was written by David Tuffley, who combines a successful commercial career as a software quality management consultant with academic involvement at the School of ICT, at Griffith University, Australia, where he lectures and is engaged in postgraduate research in IS Quality Management.

T C S   C L I E N T S

Click here to view a select client list

W H A T   C A N   Y O U   A C H I E V E ?

By using this comprehensive, step-by-step guide you will arrive at a statement of all requirements which are identifiable and meaningful to both the customer and the developer. The objective is to satisfy the identifiable needs of its intended audience.

Four key areas are identified:

• Feed back to the customer - the SRS allows the customer to verify that the analyst has understood the problem to be solved and the required behaviour of the software. As such the SRS must be presented in terms that can be understood by the customer. This most commonly means that it must be written in natural language. Should natural language prove inadequate to unambiguously describe complex requirements, modelling tools such as data flow diagrams, structured English, state transition diagrams and decision tables may be used providing they can be understood by the customer.
• Problem decomposition - the physical act of writing the requirements down crystallises ideas, organises the information, surfaces and resolves conflicts and assists in the orderly decomposition of the larger problem into its component parts.
• Input to design - the SRS is the primary reference for the development of the design. As such, it must contain an accurate and detailed description of system behaviour from which a system architect can devise a design solution.
• A basis for product validation - the SRS is the primary source from which the developer produces a strategy for testing the end product. All requirements must therefore be verifiable. That is, the user must be able to devise a test to verify that the end product satisfies the requirement.

A V O I D   T H E   B I G G E S T   P I T F A L L   O F   T H E M   A L L

Much work has been done over the past 30 years on why and how a large proportion of systems are fail to achieve their purpose. They may be abandoned before the project is finished, or the system is developed, but the customer does not use it because it does not meet their requirements. The system may conform to its original SRS, and still be a failure if it does not do what the customer needs it to do.

The most common cause of not getting the requirements right is the existence of a cultural gap between supplier and customer. These differences result in poor or inhibited communication between the stakeholders in the requirements gathering process, leading to an incomplete or poorly defined statement of user requirements. Systems subsequently developed using such an SRS is unlikely to meet the user's needs and will in all likelihood be abandoned or need to be substantially reworked.

The need for IS developers and users to collaborate has long been recognised by both the practitioner and academic worlds. A wide range of what might be called integrative processes have been developed to promote a collaborative approach to requirements analysis. These integrative processes include the ETHICS model for participative systems development, Joint Application Development and the use of particular people as integrators, such as the 'hybrid manager'. Where used, inte-grative processes are successful in improving the level of collaboration and effective communication between suppliers and customers.

But despite their effectiveness in solving a widely recognised, highly expensive problem, in reality integrative processes are not generally used. In practice, they are seen as expensive, time-consuming and a threat to established ways of developing software. Tight project budgets and schedules put most integrative processes into the 'nice to have in an ideal world' category.

The author has developed a proven integrative process that can substantially improve the chances of achieving successful project outcomes. A technical writer, who is already a member of the supplier development team, should take responsibility for the writing of the SRS. This is likely to be welcomed by the software engineers who would otherwise have to do it themselves. Technical writer's are usually able to understand both the technical point of view of the supplier, and the non-technical view of the customer/user, and as such can bridge the cultural divide. This suits them to act as a facilitator of communication between supplier and customer. If an appropriate template is used to develop the SRS, such as this one, it will be possible for a complete, correct, verifiable etc SRS to be developed, and this most dangerous of pitfalls for any development project to be avoided.

D O W N L O A D - F R E E - U S E F U L - S A M P L E S

Two brief (~10 pages each) how to guides can be downloaded for free. They are zip files containing rtf & pdf copies of the documents.

They are useful and relevant to any software development project and are intended to give prospective buyers of the full featured range of Altiora how to guides an indication of their quality and usefulness.

Click here to download How to Perform Risk Management.
Click here to download How to Perform Project Estimates .