Software Requirement Spec. Template

The paragraphs written in the “Comment” style are for the benefit of the person writing the document and should be removed before the document is finalized.

This template can be used to create Software Requirements Specifications that conform to IEEE Standard 830-1993.

An SRS is a tool for capturing requirements on a project; it is the epitome
of “plain language requirements”. Although an SRS is designed to stand on its own, most projects will employ additional tools for capturing requirements. An SRS may be ancillary or unnecessary on many projects, but a partial or lightweight one may be quite useful even if other techniques are being used to capture the bulk of the requirements.

Consider using an SRS when:

• Modeling techniques need to be augmented

• Plain language is the best mechanism for capturing system behavior

• Requirements must be traceable

• Required by regulations

See CxGuide_CxOneArtifact for details on how to utilize the advanced features of CxOne artifact templates.

Contents

1 Introduction1

1.1 Purpose1
1.2 Scope1
1.3 Definitions, Acronyms, and Abbreviations1
1.4 References1
1.5 Overview1

2 Overall Description2

2.1 Product Perspective2
2.1.1 System Interfaces2
2.1.2 User Interfaces2
2.1.3 Hardware Interfaces2
2.1.4 Software Interfaces2
2.1.5 Communications Interfaces2
2.1.6 Memory Constraints3
2.1.7 Operations3
2.1.8 Site Adaptation Requirements3
2.2 Product Functions3
2.3 User Characteristics3
2.4 Constraints3
2.5 Assumptions and Dependencies4
2.6 Apportioning of Requirements4

3 Specific Requirements5

3.1 External Interface Requirements5
3.1.1 User Interfaces6
3.1.2 Hardware Interfaces6
3.1.3 Software Interfaces6
3.1.4 Communications Interfaces6
3.2 Software Product Features6
3.2.1 Feature 16

Purpose6
Stimulus/Response Sequence6
Associated Functional Requirements6
3.3 Performance Requirements6
3.4 Design Constraints7
3.5 Software System Attributes7
3.5.1 Reliability7
3.5.2 Availability7
3.5.3 Security7
3.5.4 Maintainability7
3.6 Logical Database Requirements7
3.7 Other Requirements8

Introduction

This section should provide an overview of the entire document.

1 Purpose

Describe the purpose of this specification and its intended audience.

2 Scope

Identify the software product(s) to be produced by name. Explain what the products will and will not do. Describe how the software will be used, and identify relevant benefits, objectives, and goals.

3 Definitions, Acronyms, and Abbreviations

Define all terms, acronyms, and abbreviations used in this document.

4 References

List all the documents and other materials referenced in this document. This section is like the bibliography in a published book.

5 Overview

Describe the content and organization of the rest of this document.

Overall Description

In this section, describe the general factors that affect the product and its requirements. This section should contain background information, not state specific requirements.

1 Product Perspective

This section should place the product in perspective with other related products. If the product is independent and self-contained, state that here. Otherwise, identify interfaces between the product and related systems.

1 System Interfaces

List each system interface and identify the related functionality of the product.

2 User Interfaces

Specify the logical characteristics of each interface between the software product and its users (e.g., required screen formats, report layouts, menu structures, or function keys).

Specify all the aspects of optimizing the interface with the person who must use the system (e.g., required functionality to provide long or short error messages). This could be a list of do’s and don’ts describing how the system will appear to the user.

3 Hardware Interfaces

Specify the logical characteristics of each interface between the software product and the hardware components of the system. This includes configuration characteristics (e.g., number of ports, instruction sets), what devices are to be supported, and protocols.

4 Software Interfaces

Specify the use of other required software products (e.g., a DBMS or operating system), and interfaces with other application systems.

For each required software product, provide identification information including at least name, version number, and source.

For each interface, discuss the purpose of the interfacing software, and define the interface in terms of message format and content. For
well-documented interfaces, simply provide a reference to the documentation.

5 Communications Interfaces

Specify any interfaces to communications such as local area networks, etc.

6 Memory Constraints

Specify any applicable characteristics and limits on RAM, disk space, etc.

7 Operations

Specify any normal and special operations required by the user, including:

• periods of interactive operations and periods of unattended operations

• data processing support functions

• backup and recovery operations

• etc.

8 Site Adaptation Requirements

Define requirements for any data or initialization sequences that are specific to a given site, mission, or operational mode. Specify features that should be modified to adapt the software to a particular installation.

2 Product Functions

Provide a summary of the major functions that the software will perform.

3 User Characteristics

Describe the general characteristics of the intended users, including

• educational level

• experience

• technical expertise

4 Constraints

Describe any other items that will constrain the design options, including

• reliability requirements

• criticality of the application

• safety and security considerations regulatory policies

• hardware limitations

• interfaces to other applications

• parallel operation

• audit functions

• control functions

• higher-order language requirements

• signal handshake protocols

• etc.

5 Assumptions and Dependencies

List factors that affect the requirements. These factors are not design constraints, but areas where future changes might drive change in the requirements.

6 Apportioning of Requirements

Identify any requirements that may be delayed until future versions of the system.

Specific Requirements

This section should describe all software requirements at a sufficient level of detail for designers to design a system satisfying the requirements and testers to verity that the system satisfies requirements.

The remainder of this sample document is organized according to A.5 Template of SRS Section 3 Organized by Feature shown in the Annex of Std 830-1993. For alternative organizational schemes by system mode, user class, object, stimulus, functional hierarchy, and combinations, see the standard.

1 External Interface Requirements

Provide a detailed description of all inputs into and outputs from the software. This section should complement the interface descriptions under section 2.1 and should not repeat information there. Include both content and format as follows:

• name of item

• description of purpose

• source of input or destination of output

• valid range, accuracy, and/or tolerance

• units of measure

• timing

• relationships to other inputs/outputs

• screen formats/organization

• window formats/organization

• data formats

• command formats

• end messages

These requirements may be organized in the following subsections.

1 User Interfaces

2 Hardware Interfaces

3 Software Interfaces

4 Communications Interfaces

2 Software Product Features

1 Feature 1

Repeat subsections at this level and below for each feature.

1 Purpose

2 Stimulus/Response Sequence

3 Associated Functional Requirements

1 Functional Requirement 1

Repeat subsections at this level and below for each associated functional requirement.

Each functional requirement may be described in natural language, pseudocode, or in four subsections as follows. Functional requirements include:

• validity checks on inputs

• exact sequencing of operations

• responses to abnormal situations, including error handling and recovery

• effects of parameters

• relationships of inputs to outputs, including input/output sequences and formulas for input to output conversion

1 Introduction

2 Inputs

3 Processing

4 Outputs

3 Performance Requirements

Specify static and dynamic numerical requirements placed on the software or on human interaction with the software.

Static numerical requirements may include the number of terminals to be supported, the number of simultaneous users to be supported, and the amount and type of information to be handled.

Dynamic numerical requirements may include the number of transactions and tasks and the amount of data to be processed within certain time period for both normal and peak workload conditions.

4 Design Constraints

Specify requirements imposed by standards, hardware limitations, etc.

5 Software System Attributes

The following items provide a partial list of system attributes that can serve as requirements that should be objectively verified.

Other possible options include scalability, portability, robustness, recoverability, etc.

1 Reliability

2 Availability

3 Security

Specify the factors that will protect the software from accidental or malicious access, misuse, or modification. These factors may include:

• cryptography

• activity logging

• restrictions on intermodule communications

• data integrity checks

4 Maintainability

Specify attributes of the software that relate to ease of maintenance. These requirements may relate to modularity, complexity, or interface design. Requirements should not be placed here simply because they are thought to be good design practices.

6 Logical Database Requirements

Specify the requirements for any information that is to be placed into a database, including

• types of information used by various functions

• frequency of use

• accessing capabilities

• data entities and their relationships

• integrity constraints

• data retention requirements

7 Other Requirements