When a problem or solution requiring software is conceived it is essential that the software project is properly conveyed to the software house, agency or project staff creating the software. When constructing the document there are defined standards that the SRS may be structured to follow, such as IEEE Std 830-1998 which has been superseded by IEEE Std 29148-2011.

The document may also be written by the customer should the client choose to do so as it may provide more control of the specifications required in the project. Simply a Software Requirements Specification (SRS) could be titled ;

This is what the customer wants the software to do.

Introduction

The introduction should indicate the expected behaviors of the software as clearly as possible detailing the processes, activities, interfaces, and tasks required by the software. The introduction can be muddied if the software is not already clearly conceptualized or thought out or is to be built onto existing software if the requirements are not understood by all parties. It may also be necessary to indicate the expected life cycle, phase-out period and maintenance required to maintain the performance and usability of the software. Users may also be considered.

Purpose

An SRS document may state the purpose of the software which could be considered an ultimate end-goal of the resulting project and consider the project a failure if not met. It should conclude with affirming that this document specifies how the software should be designed, developed, tested and implemented where applicable. If the purpose is to improve the speed of current business processes then make it appear in the purpose section, if the purpose is to improve the usability of the current software used by staff then include it in the purpose section as well. If the software is also supposed to do something not included in the purpose or easily justified by this section, then it can be hard to justify why such a feature should exist in the project.

Scope

The scope of the document is to provide a description of what the document specification includes, such as use cases and requirements. Some of the program may be in multiple documents so the scope is necessary to reduce overlap between projects.

System Overview

System Overview provides a description of the context, function and requirements of the software project.

References

References should indicate if the software is somewhat pre-existing, any references made in the document and references to appendixes should also be included too.

Overall Description

The overall description is the second section of the SRS document.

Product Perspective

A product perspective is a detailed outlook of what the program should appear like to the users of the system, some software projects may be completely transparent to users, if so then the product perspective should outline the interfacing between other software components that make it so.

• The overall description should not be vague, it should provide justification as to why the functions of the program are required.
• The overall description should detail crucial cornerstones of the program and interfaces that exist with the hardware or software.
• Some of the programs may be pre-existing which will require the project interface detailed and easily readable to be understood.

The Description should have six sections,

• System Interfaces which the user may interact with the system or the system may interact with other systems.
• User Interfaces which the users may interact with which may include the frequency of their usage and the intuitiveness of the design.
• Hardware. Including the frequency of use of the hardware, considerations to the longevity of the hardware and ability to update or dispose of the hardware.
• Software. Including external interfaces, naming conventions.
• Communication and Telecom both in interfaces software to software and to the user.
• Memory. Including minimum requirements.
• Operations and processes that the program may perform real-time or batch, transaction or otherwise.
• Adaptations and the ability to configure the system. For open source or high-security systems, this section may be larger than private or closed source software due to the need to ensure that it is secure or can be maintained or made depreciated quickly.

Design Constraints

• What are the limitations of the software?
• What might the software fail to perform at?
• What are the limitations of the programming language if selected?
• How might this delay the project if risks arise?
• What are the limitations of the users’ ability?
• What training will need to take place in order to use the software effectively?
• What does the software not do?
• What happens if a user does not use the software as intended?

In most aspects of software engineering, there are simply parts of human nature and failure modes or edge cases that simply cannot always be mitigated, in such scenarios it is important to outline what steps your software has taken to make these issues not slow the productivity of the software and ensure that the system runs as intended part of this may be detailed in test cases written in the appropriate section.

Product Functions

Product Functions should as best as possible describe the function of the program and how the modules of the program if any will work together with the interfaces of the system to produce the software’s desired functions.

The aim of the section is to break down the large characteristics of the program into more readable and manageable sections that can be delegated out to a team or read to an individual clearly without much overlap to avoid confusing what the program is designed to accomplish and what each function does.

• The functions should be organized and listed so that they may be read for the first time and understood effectively.
• The section may include graphical sections or UML detailing how the program may operate.
• The validity of the input.
• Sequence diagrams or how the program may pass data between functions.
• How the program accounts for abnormality.
• Common input examples may be a good way of explaining the function to the reader and providing a sample of what the programmer should accomplish on each function.
• Sequencing.

User Characteristics

When a user may use the system either from time to time (i.e. infrequently), once or many many times it is important to detail this information in the user characteristics section and account for this in the software, if the methods used to do something are contrived or confusing it could lead to increased mistakes or data mismanagement further down the line and increase the need for normalization or reconciliation of information.

• User Characteristics should detail the factors that affect each user and provide use cases for each user, it may also be ideal to detail overlapping functions that each user may use and diagram where appropriate.
• It also may be applicable to detail why each user may need a function of the program.

Specific Requirements

The specific requirements should detail all of the requirements of the clients, the user and the software itself. It should provide suitable detail to enable the software to be written clearly and tested effectively. It should be stated for each requirement which user the requirement is for and if applicable that the test case corresponding to the requirement should be satisfied through cross-referencing other parts of the document.

• The requirements should be clearly stated to prevent later mistakes or edge cases, poorly written requirements or poorly designed functions may cause the program to be unstable or possibly unsuitable for use. Proper error handling should be given to most aspects of the programs requirement and how it operates to meet the requirement.
• Vagueness or Failings in test cases may allow for requirements to be deliberately misinterpreted, such as “The program must be fast and easy to use” may be considered easy to use for the programmer or tester, and therefore a suitable statement that the requirement is met, but not for the user who may not understand the inner workings of the software and therefore lack the knowledge to use the software effectively as much as the programmer testing the requirement, it may be a good idea to allow the users to try the functions using agile development and adapting the program accordingly.

The final part of the document should include the appendices and the index.