Software Requirements Specification

Overview

The Overview section consists of five subsections and provides for an executive level overview.

Objectives

A concise description of the objectives of the document.

Scope

A brief description of the scope of the requirements specification.

References

Identify sources of information used to develop this document, such as IEEE or project documentation.

Outstanding Issues

A list of issues or problems which are known to be outstanding with this revision.

Current Environment

This section consists of four subsections of brief descriptions that provide understanding of the context for the proposed effort.

Organization Profile

Relevant information about the organization, mission, locations, numbers, and type of personnel, and relationships or interfaces with other organizations and entities, as they relate to the system task.

Business Functions

A high-level picture of the processes and procedures by which information is currently handled by the owner/user in the area being automated or modified. The timing of critical processes should also be discussed, e.g., if there are any processes dependent on other processes being previously completed, these dependencies should be noted. For example, if time sheets are due on the 15th of the month, and there is an audit step to ensure all time sheets have been keyed prior to running a system job that cuts the checks, the audit step must be run after the 15th and prior to the system job being run.

Component or System Description

A brief introduction to the component or system that is covered by the specification. This section should be brief, since it is included only to help the reader quickly understand what is being specified.

A context diagram should be included to assist in positioning the proposed component or system.

Deficiencies

This subsection portrays any problems experienced by the owner/user with the current process.

Requirements

This section consists of twelve subsections. This section states the functions required of the software in quantitative and qualitative terms, and what the system must do to completely fulfill the owner/user’s expectations. The requirements should answer the following questions:

How are inputs transformed into outputs?

Who initiates and receives specific information?

What information must be available for each function to be performed?

Each paragraph (or group of paragraphs) should contain a reference identifying the source of the requirement. Each requirement (sentence or paragraph) should be numbered, using a numbering scheme that allows for inserting additional requirements later, e.g., FUNC-01, or A-1.1, etc. Only one requirement should be defined per numbered item.

Each requirement should be classified as one of the following:

Mandatory: Absolutely essential feature; project will be canceled if not included

Required: Individual features are not essential, but together they affect the viability of the project.

Desired: Nice-to-have feature; one or more of these features could be omitted without affecting the project viability.

Goals

Provide a clear list of the expectations of a new system or function(s), both in terms of what must be improved and what must be retained from the current processes. All detailed requirements should address one or more of these goals.

Input and Output Requirements

Provide a description of all manual and automated input requirements for the software product such as data entry from source documents and data extracts from other applications, as well as all output requirements for the software product such as printed forms, reports, display screens, files and other work products the system will process and produce.

Data Requirements

Identify the data elements and logical data groupings that will be stored and processed by the software product. Include archiving data requirements and sensitivity of data. Describe safety requirements.

This section is supported by a data model. An accompanying data dictionary should be included in an appendix.

Functional Requirements

Delineate, at a detailed level, computer system requirements within the context of the processes they must support. This is supported by a process model, which may be included.

Performance Requirements

Portray owner/user defined standards for system operations, relating to hours of operations, system response time, volumes, growth, and reliability.

Systems and Communication Requirements

Describe hardware and software interface requirements, as well as the connectivity and data interchange requirements in terms of types and volumes of data, location, and frequency of use.

Security and Privacy Requirements

Describe security and privacy requirements.

Back up and Recovery Requirements

Provide details of back up and recovery requirements. If software is identified as mission essential a continuity of operations plan must be developed.

Support Considerations

A description of any special or unusual support considerations that this system or component might require e.g., first time a UNIX system will be shipped to the field.

Hardware Requirements

Hardware Functionality

This section should cover the required capabilities of the hardware, e.g., requirement for the hardware to support multiple operating systems, or must support ethernet.

Hardware Characteristics

Required characteristics of the hardware. At a minimum this should include any requirements for diagnosis of the hardware.

Development Requirements

Technical Specifications

Document the technical approach that translates user requirements into specific requirements that can be used by programmers/analysts to create the system design.

Design Constraints

Document any design constraints that should be taken into consideration during the system design phase.

Glossary

A glossary of terms and definitions used in the Requirements Specification that might not be known to the reader or open to misinterpretation. If a standard glossary is available this might be referenced in the reference section and included with the specification to any readers or reviewers of the specification.