SRS

Key Resources

Required Reading

29148-2018 Sections 8.5.2 and 9.6

Software Requirements 3rd Edition (template in Downloads)

MITRE Systems Engineering Guide: Develop System-Level Technical Requirements - pages 351-360.

Other Resources

Custom Software Requirements Specification Document Example belitsoft

Example Outline

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Product overview

1.3.1 Product perspective

1.3.2 Product functions

1.3.3 User characteristics

1.3.4 Limitations

1.4 Definitions

2. References

3. Specific requirements

3.1 Functions

3.2 Performance requirements

3.3 Usability requirements

3.4 Interface requirements

3.5 Logical database requirements

3.6 Design constraints

3.7 Software system attributes

3.8 Supporting information

4. Verification

(parallel to subsections in Section 3)

5. Appendices

5.1 Assumptions and dependencies

5.2 Acronyms and abbreviations

Example Outline with More Information

The specific requirements clause of the SRS should be organized such that a consensus of the system stakeholders agrees that the organization method aids understanding of the requirements. There is no one optimal organization for all systems.

• Identification

  • Title

  • Revision notice - The title and a revision notice uniquely identify the document. Revision information may include the project name, version number of the document, date of release, approved signature, a list of subclauses that have been changed in the current version of the document, and a list of version numbers and dates of release of all previous versions of the document.

• Front matter

  • Include the following front matter:

    • A table of contents

    • A list of figures

    • A list of tables

1. Introduction

1.1 Purpose

Delineate the purpose of the software to be specified.

1.2 Scope

Describe the scope of the software under consideration by

a) Identifying the software product(s) to be produced by name (e.g., Host DBMS, Report Generator, etc.);

b) Explaining what the software product(s) will do;

c) Describing the application of the software being specified, including relevant benefits, objectives, and goals;

d) Being consistent with similar statements in higher-level specifications (e.g., the system requirements specification), if they exist.

1.3 Product overview

1.3.1 Product perspective

Define the system's relationship to other related products.

If the product is an element of a larger system, then relate the requirements of that larger system to the functionality of the product covered by the SRS.

If the product is an element of a larger system, then identify the interfaces between the product covered by the SRS and the larger system of which the product is an element.

A block diagram showing the major elements of the larger system, interconnections, and external interfaces can be helpful.

Describe how the software operates within the following constraints:

a) System interfaces;

b) User interfaces;

c) Hardware interfaces;

d) Software interfaces;

e) Communications interfaces;

f) Memory;

g) Operations;

h) Site adaptation requirements.

1.3.2 Product functions

Provide a summary of the major functions that the software will perform. For example, an SRS for an accounting program may use this part to address customer account maintenance, customer statement, and invoice preparation without mentioning the vast amount of detail that each of those functions requires.

Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the software product.

Note that for the sake of clarity

a) The product functions should be organized in a way that makes the list of functions understandable to the acquirer or to anyone else reading the document for the first time.

b) Textual or graphical methods can be used to show the different functions and their relationships. Such a diagram is not intended to show a design of a product, but simply shows the logical relationships among variables.

1.3.3 User characteristics

Describe those general characteristics of the intended groups of users of the product including characteristics that may influence usability, such as educational level, experience, disabilities, and technical expertise. This description should not state specific requirements, but rather should state the reasons why certain specific requirements are later specified in specific requirements in subclause 9.5.9.

1.3.4 Limitations

Provide a general description of any other items that will limit the supplier's options, including

a) Regulatory policies;

b) Hardware limitations (e.g., signal timing requirements);

c) Interfaces to other applications;

d) Parallel operation;

e) Audit functions;

f) Control functions;

g) Higher-order language requirements;

h) Signal handshake protocols (e.g., XON-XOFF, ACK-NACK);

i) Quality requirements (e.g., reliability)

j) Criticality of the application;

k) Safety and security considerations.

l) Physical/mental considerations

1.4 Definitions

• • • Provide definitions for any words or phrases that have special meaning beyond normal dictionary definitions.

2. References

• • Provide a complete list of all documents referenced elsewhere;

  • Identify each document by title, report number (if applicable), date and publishing organization;

  • Specify the sources from which the references can be obtained.

  • This information may be provided by reference to an appendix or to another document. The references information should be subdivided into a 'Compliance' section, containing references to those cited documents containing requirements which are included by that citation and a ‘Guidance' section, containing reference to those cited documents containing information, but no requirements.

3. Requirements

Specify all of the software requirements to a level of detail sufficient to enable designers to design a software system to satisfy those requirements.

Specify all of the software requirements to a level of detail sufficient to enable testers to test that the software system satisfies those requirements.

At a minimum, describe every input (stimulus) into the software system, every output (response) from the software system, and all functions performed by the software system in response to an input or in support of an output.

The specific requirements should:

a) Be stated in conformance with all the characteristics described in subclause 5.2 of this International Standard.

b) Be cross-referenced to earlier documents that relate.

c) Be uniquely identifiable.

3.1 Functions

Define the fundamental actions that have to take place in the software in accepting and processing the inputs and in processing and generating the outputs, including

a) Validity checks on the inputs

b) Exact sequence of operations

c) Responses to abnormal situations, including

1) Overflow

2) Communication facilities

3) Error handling and recovery

d) Effect of parameters

e) Relationship of outputs to inputs, including

1) Input/output sequences

2) Formulas for input to output conversion

It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This does not imply that the software design will also be partitioned that way.

3.2 Performance requirements

Specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole.

Static numerical requirements may include the following:

a) The number of terminals to be supported;

b) The number of simultaneous users to be supported;

c) Amount and type of information to be handled.

Static numerical requirements are sometimes identified under a separate section entitled Capacity.

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

The performance requirements should be stated in measurable terms.

For example,

95 % of the transactions shall be processed in less than 1 second.

rather than,

An operator shall not have to wait for the transaction to complete.

3.3 Usability Requirements

Define usability (quality in use) requirements. Usability requirements and objectives for the software system include measurable effectiveness, efficiency, and satisfaction criteria in specific contexts of use.

See https://www.clarrus.com/resources/articles/software-quality-attributes/

3.4 Interface requirements

Define all inputs into and outputs from the software system. The description should complement the interface descriptions in 9.5.3.3.1 through 9.5.3.3.5, and should not repeat information there.

Each interface defined should include the following content:

a) Name of item;

b) Description of purpose;

c) Source of input or destination of output;

d) Valid range, accuracy, and/or tolerance;

e) Units of measure;

f) Timing;

g) Relationships to other inputs/outputs;

h) Screen formats/organization;

i) Window formats/organization;

j) Data formats;

k) Command formats;

l) Endmessages.

3.5 Logical database requirements

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

a) Types of information used by various functions;

b) Frequency of use;

c) Accessing capabilities;

d) Data entities and their relationships;

e) Integrity constraints;

f) Data retention requirements.

3.6 Design constraints

Specify constraints on the system design imposed by external standards, regulatory requirements, or project limitations.

3.7 Software system attributes

Specify the required attributes of the software product. The following is a partial list of examples:

a) Reliability - Specify the factors required to establish the required reliability of the software system at time of delivery.

b) Availability - Specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart.

c) Security - Specify the requirements to protect the software from accidental or malicious access, use modification, destruction, or disclosure. Specific requirements in this area could include the need to:

1) Utilize certain cryptographic techniques;

2) Keep specific log or history data sets;

3) Assign certain functions to different modules;

4) Restrict communications between some areas of the program;

5) Check data integrity for critical variables;

6) Assure data privacy.

d) Maintainability - Specify attributes of software that relate to the ease of maintenance of the software itself. These may include requirements for certain modularity, interfaces, or complexity limitation. Requirements should not be placed here just because they are thought to be good design practices.

e) Portability - Specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems, including:

1) Percentage of elements with host-dependent code;

2) Percentage of code that is host dependent;

3) Use of a proven portable language;

4) Use of a particular compiler or language subset;

5) Use of a particular operating system.

3.8 Supporting information

The SRS should contain additional supporting information including

a) Sample input/output formats, descriptions of cost analysis studies, or results of user surveys;

b) Supporting or background information that can help the readers of the SRS;

c) A description of the problems to be solved by the software;

d) Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements.

The SRS should explicitly state whether or not these information items are to be considered part of the requirements.

4. Verification

Provide the verification approaches and methods planned to qualify the software. The information items for verification are recommended to be given in a parallel manner with the information items in subclause 9.5.10 to 9.5.17.

(parallel to subsections in Section 3)

5. Appendices

5.1 Assumptions and dependencies

List each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but any changes to these factors can affect the requirements in the SRS. For example, an assumption may be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly.

5.2 Acronyms and abbreviations