Requirements Specification Outline

Project Title
System Requirements Specification

Author(s)
Affiliation
Date
VersionHistory with Revision Dates

Systems Requirements Specification

Below is general outline. You do not do ALL of this, only those parts that a relevant for your project.

Software Requirements Specification Outline

This document contains a template structure for a software requirements specification (SRS) document. To use this outline replace the description of each section with the information about your project. If a section is not applicable to your project, keep the heading in your document, and just state that it is not applicable.

Software Requirements Specification

Project Title

Author(s)
Affiliation
Date
Version History with Revision Dates

1. Introduction

• 1.1 Product Overview

1.2 Human Resources
Describes the potential users, customers, and domain experts that have been consulted or will be consulted in the development of the system.

• 1.3 Business Context
  Provides an overview of the business organization sponsoring the development of this product. This overview should include the business's mission statement and its organizational objectives or goals.

2. User Requirements (written for customers)

• 2.1 User Objectives
  This section describes a list of objectives and requirements for the system from the user's perspective. It may include a "wish list" of desirable characteristics, along with comments if a characteristic is not likely to be feasible or consistent with the overall organizational context.

• 2.2 Similar System Information
  Describes the relationship of this product with any other products. Specifies if this product is intended to be stand-alone, or else used as a component of a larger product. If the latter, this section discusses the relationship of this product to the larger product.

• 2.3 User Characteristics
  Describes the features of the user community, including their expected expertise with software systems and the application domain.

• 2.4 User Problem Statement
  Describes any problems currently confronted by the user community.

3. Functional Requirements

This section lists the functional requirements in ranked order. A functional requirement describes a desired behavior or effect of the software system, in other words, what the system must accomplish, but not how it will do it. Other kinds of requirements (such as interface requirements, performance requirements, or reliability requirements) describe how the system accomplishes its functional requirements. Each functional requirement should be specified in a format similar to the following:

1. Short imperative sentence stating what the system should do.

• Description
  A description of the function or object, explaining it as unambiguously as possible.

• Inputs
  Describe input data and its source (e.g., keyboard, mouse, file, another system)

• Outputs
  Describe any data produced and its destination

• Criticality
  Describes how essential this requirement is to the overall system.

• Technical issues
  Describes any design or implementation issues involved in satisfying this requirement.

• Risks
  Describes the circumstances under which this requirement might not able to be satisfied, and what actions can be taken to reduce the probability of this occurrence.

• Dependencies with other requirements
  Refer to other requirements or modules which must be developed for this requirement to function as intended.

1. Short imperative sentence stating the second ranked requirement
   …

4. Interface Requirements

This section describes how the software interfaces with other software products or users for input or output. Examples of such interfaces include library routines, token streams, shared memory, graphical I/O, and so forth.

• 4.1 User Interfaces
  Describes how this product interfaces with the user.

  • 4.1.1 GUI
    Describes the graphical user interface, if present. This section should include a set of preliminary screen dumps or mockups to illustrate user interface features. If the system is menu-driven, a description of all menus and their components should be provided.

  • 4.1.2 CLI
    Describes the command-line interface, if present. For each command, provide a description of all arguments and example values and invocations.

  • 4.1.3 API
    Describes the application programming interface , if present. For each public interface function, provide the name, arguments, return values, examples of invocation, and interactions with other functions.

  • 4.1.4 Diagnostics
    Describes whether any debugging information or log data should be produced for diagnostic purposes.

• 4.2 Hardware Interfaces
  Describes interfaces to specific hardware devices.

• 4.3 Communications Interfaces
  Describes network interfaces.

• 4.4 Software Interfaces
  Describes any remaining software interfaces, such as a database interface, not included above.

5. Non-Functional Requirements

• 5.1 Hardware Constraints
  Specifies the type(s) of hardware on which the system is expected to run.

• 5.2 Performance Requirements
  Specifies time and memory constraints that must be satisfied for the system be effective.

• 5.3 System Environment Constraints
  Describes any standards for which compliance is required, or standard data or application formats that must be supported.

• 5.4 Security Requirements

• 5.5 Reliability

• 5.6 Maintainability

• 5.7 Portability
  Describes a range of systems that should be supported by this software.

• 5.8 Extensibility
  Describes any constraints on forward or backward compatibility with other systems.

• 5.9 Development Process Constraints
  Describes the software development environment to be used, including programming languages, development tools, and software libraries, indicating any reasons that these are required or preferred.

6. System Models
This section includes diagrams showing relationships between major software components and the system environment. It may include one or more of the following:

1. State Machine Diagrams

2. Object Models

3. Data-Flow Models

4. Entity-Relationship Diagrams (if the system will include a database)

7. Operational Scenarios

This section may include a set of scenarios that illustrate, from the user's perspective, what will be experienced when utilizing the system under various situations. In the article Inquiry-Based Requirements Analysis (IEEE Software, March 1994), scenarios are defined as follows:

A scenario is simply a proposed specific use of the system. More specifically, a scenario is a description of one or more end-to-end transactions involving the required system and its environment. Scenarios can be documented in different ways, depending up on the level of detail needed. The simplest form is a use-case diagram, which consists of a labeled interaction between actors. More detailed forms are called scripts. These are usually represented as tables or sequence diagrams and involve identifying a sequence of actions and the agent (doer) of each action.

Although scenarios are useful in acquiring and validating requirements, they are not themselves requirements, because they describe the system's behavior only in specific situations; a specification, on the other hand, describes what the system should do in general.

8. Appendices

Specifies other useful information for understanding the requirements. All SRS documents should include at least the following two appendices:

• 10.1 Definitions, Acronyms, Abbreviations
  Provides definitions of specialized terms or acronyms that must be understood in the context of this application.

• 10.2 References
  Provides complete citations or URLs for all documents and web sites referenced or used in the preparation of this document.