SOFTWARE REQUIREMENTS SPECIFICATION: WHAT IT IS AND WHY IT IS IMPORTANT

Suppose you are a company and you plan to make a software that simulates stock exchanges. You have the idea, and you know how the stock exchange software will look to the end user. That is, you know what functions the software will perform, and how it will perform. Suppose you also know the software will run on Windows. Perhaps you have made a deal with Microsoft so that the software can only be run on Windows. Now, you pretty much know what the software will look to the end user and how you will profit from it. But you don’t have the technical expertise to develop the software. So you outsource the software development to an IT firm.

Now, you need to make sure the IT firm developers understand exactly what you want from the software. Also, you need to make clear to them which operating system the software will run in. All these details you are going to give to the developer is, in essence, the Software Requirements Specification (SRS).

A broader definition of a Software Requirements Specification (SRS) is given below:

A Software Requirements Specification (SRS) is a document that lays out the description of the software that is to be developed as well as the intention of the software under development. Software requirements specification shows what the software is supposed to do as well as how it is supposed to perform. It is written down before the actual software development work starts.

An SRS should address, among other things:

1. Functionality of the software: What the software will do
2. External interfaces: How the given software will interact with hardware, other software(s) and assumptions on these entities
3. Required performance levels: Required performance levels such as response rate, recovery rate etc. of the software
4. Quality attributes: The non-functional factors that are used to evaluate the performance of the software, such as security, safety, portability etc
5. Design constraints: Any operating system limitations (e.g.: the stock exchange software will only run on Windows), implementation language etc that will affect or limit the design of the software.

Software requirements specification(SRS) is important for developers because it minimizes the amount of time and effort developers have to expend to achieve desired software goals. It thus reduces development cost. This also benefits the client company because the lesser the development cost, the lesser the developers will charge from the client. And, if composed properly, an SRS ensures that there is less possibility of future redesigns as there is less chance of mistake on the part of developers as they have a clear idea on the functionalities and externalities of the software. It also helps clear any communication problems between the client and the developer. Furthermore, an SRS serves to form a foundation of mutual agreement between the client and the developer (supplier). It also serves as the document to verify the testing processes. A format of software requirements specification given by IEEE (Institute of Electrical and Electronics Engineers) is shown below (explanation for each point is given within the point):

1. Introduction

1.1 Purpose

This gives the purpose of the SRS document, not the software itself. It also states how much of the software is covered by the document, particularly saying whether it describes the entire software system or only a part of it. It also states the intended readers of the document.

1.2 Document conventions

This covers whether the documentation follows any particular format.

1.3 Intended audience and reading suggestions
This segment lists the intended audience and provides reading suggestions. For example, a document might be for both developers and project managers. This part suggests how developers should read and also how project managers should read this document. The sequence and importance of different segments might be different for developers and project managers.

1.4 Product Scope

This segment describes the software in brief. Its purpose, objectives etc. It further states how the software ties into corporate aims and objectives.

1.5 References

This segment lists any and all websites and documents that were referred to in this document. The reference should be clear enough that the reader can access the referenced document or site after reading the reference list.

2. Overall description

2.1 Product Perspective

This part describes the context within which the product (software) is being built. It also shows if the software is part of a product family, a replacement for an already existing member, or a completely new and unique product. Also, if the SRS only describes a part of a larger system, then this part will lay out the requirements from the larger system for this part to operate effectively. A diagram should be drawn here to show the chief components of the entire system, the interlinking connections, and also the interfaces.

2.2 Product Functions

A list of the major functions that product is to perform, or lets the users perform. This should be readable and easily understandable by all the intended readers of the SRS.

2.3 User classes and characteristics

This part identifies the user classes that will use the product. The classes may be categorized based on which functions they use, usage frequency, technical expertise, experience etc. The relevant characteristics of each class should be given here. Also the most important user classes should be identified here.

2.4 Operating Environment

This segment describes the environment in which the product will operate, such as the platform (hardware) operating system version etc. Also any other components the application will cohabit.

2.5 Design and Implementation Constraints

This segment lays out any constraints or issues that will limit options to developers. Some of these might be hardware limitations, interfaces, particular technologies, parallel operations, language requirements, regulatory policies, corporate policies, security provisions etc.

2.6 User Documentation

This part shows the user manuals, tutorials etc that will be provided along with the software.

2.7 Assumptions and Dependencies

This part lists any assumptions that could affect the requirements stated in the SRS. The software would not work to the desired level if these assumptions are incorrect or change. Also listed here is any dependency the product will have on external factors.

3. External Interface Requirements

3.1 User Interfaces

This part describes the logical characteristics of each interface between the software and the user. This might include screen image samples, Graphics User Interface standards, screen layout constraints, buttons and functions, keyboard shortcuts, message displays etc. The software components for which user interface is need will also be defined.

3.2 Hardware Interfaces

This segment describes the logical and physical characteristics of each interface between the software and hardware components of the system.

3.3 Software Interfaces

This segment describes the connections between the product and any other specific software components, be it operating systems, databases libraries, etc. Data items and messages going into the system and going is identified and the purpose of each is described.

3.4 Communications Interfaces

This part describes any communications functions required by the software, such as e-mail, web browser, network server communications protocols, electronic forms etc. Any communication standards to be used is also identified. Communication security and/or encryption issues are specified.

4. System Features

This part lists the major services the product will provide. This part may be organized by use case, mode of operation, user class, object class, functional hierarchy, a combination of these etc.

An example might be:

4.1 System Feature 1 (basically here the name of the feature will be stated)

4.1.1 Description and Priority

4.1.2 Stimulus/Response Sequences

4.1.3 Functional Requirements

4.2 System Feature 2 (and so and so)

5. Other Non-functional Requirements

5.1 Performance Requirements

Requirements such as RAM requirements, CPU speed etc. Basically, these will ensure the software performs smoothly and without any problems

5.2 Safety Requirements

Requirements concerned with possible loss, damage or harm that could result from the use of the product are stated here. Any safeguards that must be implemented should also be defined. External policies or regulations stating safety issues that affect the product’s design or use should be referred. Any safety certifications that must be satisfied is defined.

5.3 Security requirements

This part specifies any requirements regarding privacy and safety, as well as protection of data created or used by the product. Any user identity authentication requirements are stated here. Any safety certifications that needs to be satisfied is also defined.

5.4 Software Quality Attributes

Any additional quality characteristics of the product that might be important are specified here. Such as: adaptability, interoperability, availability, correctness, maintainability, robustness, usability, testability etc.  These are written in a specific, verifiable and quantitative way.

5.5 Business Rules

Operating principles of the product are stated here. Such as which individuals can perform which functions under different circumstances.

 6. Other requirements

Any requirements not stated in the SRS elsewhere are stated here. The requirements may include database requirements, legal requirements etc.

Appendix A: Glossary

Here any and all terms that are necessary to understand and interpret the SRS are given. These may include Acronyms and abbreviations.

Appendix B: Analysis Models

This is an optional element, which may show relevant models, such as data flow diagrams, entity-relationship programs etc.

Here is a template for an SRS. For an actual example, see this Software Requirements Specification created for the open-source software Gephi.

Contributor: Ashiqur Rahman, Nascenia