How to Write a System Specification

“A goal without a plan is just a wish”

What is a System Requirement Specification (SRS)?

A SRS is a document which sets out what the client expects and what is expected of the software system which is being developed. It is a mutual agreement and insurance policy between client and developer and is a vital part of the Software Development Lifecycle.

The SRS is a technical document which provides a framework for the software development process. It provides an overview of the software or application including what it should do and what its parameters are, how it will interact with its environment and the end users, and its hardware and software requirements.

The SRS should be able to be read and understood by all the parties involved in the production of the software, including clients, designers, coders, testers and end users.

Can you do without a SRS?

Sure you can;

• if you don’t want to have a overview of the project and a reference point available to the whole development team
• if you don’t want to know what the software is supposed to do and how it will perform
• if you don’t want to inspire confidence in stakeholders, users and your own development team
• if you don’t want the development team to know the specifications and are willing to leave things open to a variety of interpretations
• if you’re not interested in the expected costs and are not worried about time implications.

“Planning without action is futile, action without planning is fatal”

Who writes the SRS?

Many people can be involved in the process, not least of all the client. The project manager will be at the forefront of what is produced, but the writing can also include system analysts, programmers, technical writers and product marketers.

Standards to be achieved when writing the SRS

It is good practice to use project unique identifiers in the text so that not only the document itself, but also references within the document can be traced in a hierarchical way.

It is important that the document records how requirements will have the ability to be tested, so quantitative elements should be built in.

Writing a SRS is not a simple matter. Natural language can be ambiguous so a structured language is needed. The language used should be clear and concise, without ambiguity, and should be consistent and accurate. The use of imperative terms should be consistent and directives should point to additional and supplementary information. The use of subjective words and passive phrases are best avoided.

A more complete checklist of language quality characteristics can be found elsewhere on the internet.

Where does a SRS come in the development process?

It will usually happen right up-front, after the discussions between the development team and the client, when the requirements of the end product are known and understood. The next step, following the SRS, would be the design phase.

The SRS structure

The SRS can be written in a variety of ways, and the type and length of the document produced may well depend on the environment in which you are operating, e.g. in an agile environment the SRS may be quite short, but if adopting a waterfall model it could be very long.

You can easily find templates on the internet, and one of the important ones to look at is that produced by the Institute of Electrical and Electronic Engineers (IEEE). This is a world-wide organisation, based in America and concerned with all aspects of technology-centred products and services. It is active in promoting standards for a range of technologies including computing, and has produced a standard (IEEE std 830-1998 - ‘Recommended Practice for Software Requirement Specifications’).

Let’s look at a generic SRS structure.

Before the introduction it is good practice to have a REVISION HISTORY so that you can see how the document has evolved, how many revisions it has had and which is the latest version.

Introduction

This must include the:

Purpose for the software i.e. what it should do. This should be a joint collaboration between the client and the development team.

Reasons why the software needs to be built.

Parameters of the software i.e. what it will and will not do.

Standardised Terms and how they will be used in the language of the document.

References which will list any web addresses or titles with author name, date and source, which you’ve used in preparing the specifications.

Description

A General Description which covers the context of the software i.e. is it new software or built to be part of a larger system? If the latter it needs to be stated where it lies in the overall system.

Who will use it This describes the user classes who will use the product.

Environment in which the software will work, including hardware platform, operating system and software applications it has to work with.

Constraints which affect the development, such as limitations placed on the development by the client’s business policies or timing issues; development restrictions affecting hardware, memory, databases, language etc.

Assumptions regarding internal or external dependencies which could affect the development.

Interfaces

Here the various interfaces are described including how the software will present to the end user on the screen. Also included are hardware and software interfaces, and communication interfaces which work alongside the software.

Functional requirements

The functional requirements are concerned with the way the software behaves in response to the client’s or business needs, and should be readily accessible to client or end user. They derive from the business requirements which ask the question ‘why we are undertaking the development’ i.e why the business can gain benefit from the project, and they also derive from the user requirements which ask the question ‘what will the user be able to do with the system’ i.e. what benefits the business can gain from the project. The functional requirements tell the developer what to build and what system features the software should embody.

Non-functional requirements

The non-functional requirements are about the software itself and what should be built into it.

Non-functional requirements can be split into:-

• System Features which are the performance requirements and quality attributes of the software such as usability, robustness etc.
• Remaining Non-Functional Requirements such as business rules, company policies, security requirements, safety requirements etc.

User documentation

This section lists the support which is supplied for understanding and working the system such as manuals and tutorials.

Appendix

This will include a glossary of terms which are needed by the SRS reader. The appendix may also include diagrams of data flow, entity-relationship diagrams etc.

It is imperative to produce a full and clear SRS. Time spent on this will enable the client to see what he is getting and enable the development team to understand the client’s needs and produce a valuable product.

If you have any concerns about compiling a System Requirement Specification, or need any help, please don’t hesitate to get in touch with us.