Home     Content    

Requirements Guidelines

Following is a suggested guideline for producing requirements. This outline conforms to "IEEE Guide to Software Requirements Specifications". It is recommended that this outline be used as a guide for generating requirements. No outline will guarantee a good SRS. A good SRS has the following characteristics:

 

  1. Correct
  2. Unambiguous
  3. Complete
  4. Verifiable
  5. Consistent
  6. Modifiable
  7. Traceable
  8. Annotated
  9. Usable during Operation and Maintenance phase
  10. Understandable by non-computer specialists

 

Outline

1. Introduction

 

Brief background about how the need for these requirements came about, or simply the header by itself. It is the following subsections which follow which should provide an overview of the entire SRS.

 

1.1 Purpose

 

This subsection should accomplish the following:

  1. Delineate the purpose of the SRS
  2. Specify the intended audience for the SRS

 

1.2 Scope

 

This subsections should:

  1. Identify the software product(s) to be produced by name; for example, RT_EXEC
  2. Explain what the software product(s) will, and if necessary, will not do.
  3. Describe the application of the software being specified. Include a description of the relevant benefits, objectives and goals as precisely as possible. Be consistent with similar statements in higher-level specifications.

1.3 Definitions, Acronyms, and Abbreviations

 

Definitions change over time, acronyms are meaningless if not defined, abbreviations are meaningless if they are not included with a description either here, or in an appendix. It is a good idea to scan this document to make sure every term is defined.

1.4 References

 

References are vital to communicating an idea. Even when I think my ideas are original, I find it is helpful to find an author who has published a similar concept and use it as a reference. It is much easier to present a new concept if the audience can be convinced that it isn't your new concept.

1.5 Overview

 

This Subsection should:

  1. Describe what the rest of the SRS contains
  2. Explain how the SRS is organized

 

2. General Description

 

In the subsections that follow, describe the general factors that affect the product and its requirements.

 

2.1 Product Perspective

 

This subsection of the SRS puts the product in perspective with other related products or projects.

 

2.2 Product Functions

 

This subsection should provide a summary of the functions that the software will perform.

 

2.3 User Characteristics

 

Describe the users of the system and how they will affect the specific requirements.

 

2.4 General Constraints

 

This subsection should provide a general description of any other items that will limit the developer's options for designing the system. These can include:

 

  1. Regulatory policies
  2. Hardware limitations
  3. interfaces to other applications
  4. Parallel operation
  5. Audit functions
  6. Control functions
  7. Higher-order language requirements
  8. Signal handshake protocol
  9. Criticality of the application
  10. Safety and security considerations

2.5 Assumptions and Dependencies

 

This subsection should list each of the factors that affect the requirements stated in the SRS.

 

3. Specific Requirements

 

This section should contain all the details the software developer needs to create a design. This is the largest and most important part of the SRS.

 

3.1 Functional Requirements

 

3.1.1 Functional requirement 1 (state requirement)
3.1.1.1 Introduction

 

Brief description of how this requirement came about. A lead in to the requirement, does not state a requirement, simply the need. It does not contain a SHALL.

 

3.1.1.2 Inputs

 

Describe the data and commands which are needed as input for the requirement. This is input the requirement needs, not the requirement.

 

3.1.1.3 Processing

This is where the requirements SHALL be stated. All "SHALLs" go here.

 

3.1.1.4 Outputs

 

Describe the output expected as a result of the processing. This is the expected output from the processing, not the requirement. Describe the data, not the requirement.

 

3.1.2 Functional requirement 2 (state requirement)
3.1.2.1 Introduction
3.1.2.2 Inputs
3.1.2.3 Processing
3.1.2.4 Outputs

 

Continue with functional requirements till all functional requirements have been stated. The numbering should continue the sequence 3.1.x.

 

3.2 External Interface

 

If there is an external interface, describe it here, or reference an interface requirement specification document (IRS).

 

3.2.1 User Interface

 

Describe the user interface, or reference a user interface document. As an example is "CHCS Menu Diagrams (RQMTS-93-36)"

 

3.2.2 Hardware Interfaces

 

If there is an external interface, describe it here, or reference an interface requirement specification document (IRS).

 

3.2.3 Software Interfaces

 

If there is an external interface, describe it here, or reference an interface requirement specification document (IRS).

 

3.2.4 Communications Interfaces

 

If there is an external interface, describe it here, or reference an interface requirement specification document (IRS).

 

3.3 Performance Requirements

 

Includes number of terminals, number of users, number of transactions, and other capacities or performances.

 

3.4 Design Constraints

 

Includes all standards that software development must comply with and all limitations of the support hardware, such as memory, speed, and number of ports.

 

3.4.1 Standards Compliance

 

3.4.2 Hardware Limitations

 

3.5 Attributes

 

Covers other system software nonbehavioral attributes not covered in other sections. Includes attributes such as availability, security, and maintainability of the system.

 

3.5.1 Security

 

3.5.2 Maintainability

 

3.6 Other Requirements

 

This section specifies other requirements, such as data base or operational requirements.

 

3.6.1 Data Base

 

3.6.2 Operations

 

3.6.3 Site Adaptation