January 24, 1999
Version 1.3.1

Introduction

This document outlines the template for software requirements specification (SRS) documents produced in the CPSC372 Introduction to Software Development course. It is based on the following templates:
ANSI/IEEE Std 830-1984 - IEEE Guide to Software Requirements Specification
Cockburn, A. "Basic Use Case Template," available at http://members.aol.com/acockburn/papers/uctempla.htm.
 

Template

This section contains the template for an SRS. The numbers corresponding to subsections in this document specify the numbers that should appear in the SRS. Also included are brief descriptions of the contents of the sections.
An SRS must contain a table of contents, including section titles, numbers and page numbers.
 

1 Introduction

1.1 Purpose

This section should outline the purpose of the SRS as well as its intended audience.

1.2 Scope

This section must identify the software being specified by name, a brief description of what the product will and will not do, and explain the benefits, objectives and goals of the software as precisely as possible.

1.3 Definitions, Acronyms and Abbreviations

This section should specify all the terms, acronyms and abbreviations necessary to understand the SRS.

1.4 References

This section contains all the documents referenced elsewhere in the document, for example, other standards and reference documents. Each document should be identified by its title, date and publishing organization. In the event that the document is a web page, the URL must also be specified.

1.5 Overview

This section describes the rest of the document and its organization.

2 General Description

2.1 Product Perspective

This section describes how the product relates to other products. In particular, each component of the larger system must be identified and briefly described. The primary external interfaces should also be described in this section. Note, however, that these need not be specified in detail - this is provided elsewhere in the document. To aid in describing this section, a block diagram may be used that shows the major functional components of the larger system (i.e., the system being described in this SRS should appear as a block, but should not be decomposed further; neither should other major functional components). If the product is independent, it should be explicitly stated in this section.

2.2 Product Functions

This section provides a summary of the functions that the software will perform. For example, an SRS for a video rental system might use this section to address customer maintenance, video maintenance and report generation. Note that these are summaries, and so vast amounts of detail are not required in this section. As with section 2.1, block or other diagrams might aid in displaying the interactions between the various major components of this product. Such diagrams are not intended to impose a particular design, but rather to aid readers in understanding what the product is to do.

2.3 User Characteristics

This section should be used to describe the general characteristics and backgrounds of the eventual users of this product, such as educational level, experience and technical expertise, that will specifically impact on the requirements for this product. For example, if users only interact with the software occasionally, then this might result in the requirements for a detailed help system, which must be described in the requirements. Note, also, that many people may interact with the product during its lifetime; all user characteristics must therefore be described.

2.4 General Constraints

This section must contain a general description of any other items that will restrict the design of the system. For example, regulatory policies, hardware limitations, interfaces to other applications, company procedures, criticality of the application, safety and security considerations.

2.5 Assumptions and Dependencies

This section should describe any factors that affect the requirements. Such factors are not design restrictions, but rather factors that, if they should change, would mean a significant reevaluation of the SRS. For example, an assumption might be that a specific operating system will be used - if this operating system were to change, or was not available, then the SRS will need to be modified accordingly.

2.6 Requirements

3 Specific Requirements

3.1 Description of Actors and Use Cases

3.1.1 Actors

This section contains the role name and brief description of all actors that use the software system.

3.1.2 Use Cases

This section describes all the use cases and their interactions with actors and other use cases. The use cases themselves are not described here, simply their names and relationships. A UML top level diagram would be useful here.

3.2 Specific Functional Requirements

3.2.x Use Case 1

3.2.x.1 Characteristic Information

Goal in Context: This should serve as an introduction to the use case, stating its purpose and the goal that will it will achieve.
Scope: One of:

• Strategic - this use case  is a strategic goal with respect to the system. These goals are goals of value to the organization. The use case shows how the system is used to benefit the organization. These strategic use cases will eventually use some of the same lower level (subordinate) use cases. An exmple of a strategic use cases included monitoring customers - it is a collection of specific functions, all related to a general, strategic goal.
• System - Use cases at system scope are bounded by the system under development. The goals represent  specific functionality required of the system. The majority of the use cases are at system scope. These use cases are often steps in strategic level use cases

Level: One of:

• Primary task - a goal that a primary actor is trying to achieve.
• Summary - a collection of primary tasks to get a larger task done.
• Subfunction - a subgoal or step in some Primary task use case.

Preconditions: This should contain a list of what is expected to be the state of the world for this use case to succeed.
Success End Condition: This should contain the state of the world upon successful completion.
Failed End Condition: This should contain the state of the world if goal abandoned.
Primary Actor: This should contain a role name for or a description of  the primary actor.
Trigger: The action upon the system that starts the use case, may be time event
Inputs: The data required for this use case, including sources, quantities, units of measure, timing
Outputs: The data produced by this use case, including targets, quantities, units of measure, timing

3.2.x.2 Scenarios

3.2.x.2.1 Main Success Scenario

This section contains the steps of the scenario, from trigger to goal delivery, and any cleanup activities. Each step should be numbered and described. All information used in each step must be listed in the Inputs subsection of 3.1.x.1.

3.2.x.2.2 Extensions

This section contains any variations of the main success scenario, each referring to a step in the main success scenario. For example, this section may contain variations that lead to failure of this scenario, such as if errors occur, or appropriate information is not given.

3.2.x.3 Related information

Priority: How critical to your system / organization.
Performance Target: The amount of time this use case should take.
Frequency: How often it is expected to happen.
Superordinate Use Case: optional, name of use case that includes this one.
Subordinate Use Cases: optional, depending on tools, links to sub.use cases.
Channel to primary actor: e.g. interactive, static files, database.
Secondary Actors: List of other systems needed to accomplish use case.
Channel to Secondary Actors: e.g. interactive, static, file, database, timeout

3.2.x.3.1 User Interfaces

This section should contain a description of the required screen formats, page layouts of any reports generated as a result of this use case. In particular, if the origin/destination of inputs/ouputs is the user (or actor), then a description of how this information is attained/presented to the user should be presented.

3.2.x.3.2 Other external interfaces

This section describes interfaces to other systems, such as software, hardware or networks. This section should describe (or refer to) interfaces to these other systems, in particular relating them to the inputs and outputs for this use case in a manner similar to 3.1.x.3.1

3.2.x.4 Open issues

This section contains a list of issues that need to be decided. In the final version of the SRS, this section should contain the word "None." However, this section is useful in preliminary versions to record issues that require discussion.

3.3 Performance requirements

This section should specify precisely the static and dynamic numerical requirements placed on the product. Static numerical requirements may include the number of terminals to be supported, the number of simultaneous users, number and size of files and tables. Dynamic performance requirements may include the number of transactions or tasks to be processed in certain time periods for both normal and peak workload conditions.

3.4 Design constraints

This section contains information that will restrict the design of the system, and may include:
Standards compliance, including specific report formats, data naming, accounting procedures, or audit tracing, which may be derived from existing standards or regulations. These attributes need to be summarized here, and the standards and regulations referenced.
Hardware limitations, specific hardware configuration characteristics) that may be imposed on the system, that may restrict the number of ports, amount of memory, etc. that may be used in the design.

3.5 Attributes

There are a number of attributes that can place specific requirements on software.
Availability, which could specify factors required to guarantee a defined availability level for the system (for example, checkpointing, recovery, restart)
Security, which could specify factors required to protect the software from accidental or malicious access, use, modification, destruction or disclosure. This may include certain cryptographic techniques, restricting communication between some areas of the system, keeping track of users.

Last modified: 1/24/99