Software Requirements Specification Document

Software Requirements Specification (SRS)

IEEE Std 830 is a "recommended practice" for software requirements specification documents.

The IEEE has a different standard for a "Software Requirements Document" (SRD), which is IEEE/EAI 12207.1-1997. If you look in the table at the back of IEEE Std 830-1998 you will see the cross reference tables in Appendix B, showing that these are consistent with one another.

Table of Contents

The following is on example of an outline for an SRS.

1.  Introduction
      1.1 Purpose
      1.2 Scope
      1.3 Definition, Acronyms, or Abbreviations
      1.4 References
      1.5 Overview
2.  General Description
      2.1  Product Perspective
      2.2  Product Functions
      2.3  User Characteristics
      2.4  General Constraints
      2.5  Assumptions
3.  Specific Requirements
3.1  Functional Requirements
      3.2  Interface Requirements
      3.3  Data Requirements
      3.4  Behavioral Requirements
      3.5  Design Constraints
      3.6  Standard Compliance
      3.7  Environmental Definition
      3.8  HCI

System Requirements Specification

1.1 Purpose

The Purpose section states the goals and objectives of the system. Goals have to do with the general purpose of a system. Goals are fuzzy and non measurable. Goals are decomposed into objectives. Objectives are finite and measurable. You know when you reach them.

example:

The goal of this project is to reduce the time and lines for students receiving financial aid. Objectives are to automatically verify financial aid request for correctness and completeness, track request within FSU, allow on-line access for students to the department of education, allow on-line notification of problems to students for quick correction, and ...
The benefits of this project are increased student moral... (tangible..., intangible...)

1.2 Scope

The Scope section defines the boundaries of a system. These include what is inside the system - what will be designed and programmed.

example:

The scope of this project includes initiation of financial aid, verification of aid packet, tracking of request within FSU, access to DOE tracking, ...
The resulting products of this project include on-line tracking screens, on-line student verification and notification, ... (generally not individual I/O)
The people involved in this project include (names and titles) ... The production of this document was done by ...

1.3 Definition, Acronyms, or Abbreviations

As you begin to define a system, you will encounter words which need definitions and general usage acronyms. These should be documented for new personnel and for clarity of all concerned parties.

example:

FSU - Florida State University
CS - Computer Science
MSES - Masters in Software Engineering Science
DOE - Department of Education
...

1.4 References

example:

Many references may be used to define existing systems, procedures (both new and old), documents and their requirements, previous system endeavors. These references are listed here for others.

example:

DOE document #DOE4564 -Description of DOE Tracking System ...

1.5 Overview

The Overviw section defines the organization of the entire document. It will lay the framework for reading the document.

example:

The remainder of this document is organized as follows. Section 2 describes the ... and explains ... . Section 3 discusses ... and specifies ... . ...

Section 2 - General Description

• Overview of the system and its relationship with other systems.
• "Shall List" of the functions
• User behavior characteristics
  e.d., users, operations ...
• System constraints (time, space, money)
  e.g., hardware, tracing, accounting, compliance standards, ...
• Additional requirements
  e.g., security, reliability, mobility, availability, performance, external interfaces
• Assumptions

2.1 Product perspective

example:

This product ... will be the responsibility of the XXX group within the organization. It will do the reporting for the four xxx departments. It serves as a xxx vendor invoicing sytem for the xxx accounting system xxx. It interfaces with the xxx organization and xxx financial system ...

We estimate it will add xxx number of transactions on the PC systems in the district offices and xxx number of transactions on the mainframe during peak hours of daily processing. It will add 2 hours of batch processing in the evening.

The environment of the system includes ORACLE database, Unix operating system, TCPIP communication system.

2.2 Product Functions

This section lists the major functions of the system. James Martin documented the major business functions of all business in his technique on Information Strategy. These include items such as accounts receivable, accounts payable, sales, administration, etc. In this section you should note which major business function is impacted and the minor functions. The section decomposes the function until a verb is encountered to name the processes of the functions.

This section also includes the "shall list", which specifies what the system should do. Each item in the list is a statement of the form "The system shall ...".

example:

This product builds a system under the major business function of financial management. It is under the sub-function of accounts receivable. It includes the process named issue bills.
The system shall:

accept charges to a persons account.
accept payments to a persons account.
report amount of charges per month, year, and location.
report amount of payments per month, year.
bill persons for amount due, over 30, over 60, and over 90.
adjust accounts.
...

2.3 User characteristics

• Enumerate the users involved with the proposed system.
• Describe the responsibility of each type of user involved.

example:

The users of this system include the business clerks who make charges to a person's bill, the data entry operators who make payments to the bill, the administrators at the district offices who make inquiries against a patient's bill, the managers who review the reports monthly, and the accountants who make adjustments.

The clerks will use an automated credit card debit machine and will be trained on this type of equipment. The data entry operators will use a key to disk machines. The administrators will use a PC intelligent terminal. The managers will use Excel type reporting. The accountants will use a PC intelligent terminal.

2.4 General Constraints

In this section, the constraints of the system are listed. They include hardware, network, system software, and software constraints. It also includes user constraints, processing constraints, timing constraints, and control limits.

example:

The constraints of this system include the following:

The hardware must be secured from any internet access.
The software must be:

DB2 database on mainframe and PC
MVS operating system on the mainframe
Windows NT on PC's
TCPIP for PC communications
SNA Network
Audit functions include the State Audit Control Board.
Batch processing must be limited to 2 hours during evening.
On-line processing must not impact the current schedule.

2.5 Assumptions

This includes assumptions made at the beginning of the development effort as well as those made during the development.

example:

The assumptions are that:

This system will not need any more or less personnel.
All existing personnel are trainable.
...

Entity Relationship Diagram

Entity Relationship Attribute Diagram

ER Data Dictionary

example:

3.4 Behavior Requirements

• Use Case Diagrams + Data Dictionary for Use Cases
• Process Diagrams + Data Dictionary for Process
• Class Diagrams + Data Dictionary for Classes
• State Transition Diagrams or State Charts

Use Case Diagrams

The above example of a use case diagram is reproduced from http://community.borland.com/article/0,1410,30166,00.htm.

For more detail see the notes on use case requirements elicitation and diagrams in the Chapter 10 notes.

Sequence (Event Trace) Diagrams

The above diagram is reproduced from http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/Interactions.html.

Data Dictionary for Use Cases

example:

Class Diagrams

The above example of a UML class diagram is reproduced from a very nice tutorial on UML on the web, at http://www.togethersoft.com/services/practical_guides/umlonlinecourse/.

Class Dictionary

example:

Process Diagrams

Several kinds of diagrams may be useful in modeling the interactions of the system to be built with its users and other entities in its environment.

• Data Flow Diagrams
• Control Flow Charts
• Work Flow: IDEF3, IDEF0
• State Charts
• Use Case Diagrams

Some of these same diagrams may be useful later, in the design phase, to model the functions and interactions of the components into which the design has decomposed the system.

Data Flow Diagram

See also the Chapter 12 notes on DFDs.

In a requirements specification, only the top level DFD would ordinarily be included. This is sometimes called a Context Diagram.

The above diagram is reproduced from http://wiki.cs.uiuc.edu/SEcourse/PAS%3A+Data+Flow+Diagram+-+0+Level<.

Data Flow Diagram

The above example of a more complex flowchart-type control-flow process diagram is reproduced from http://sunset.usc.edu/research/reference_architecture/toc_main.html, and example of a "Software Architecture Specification" document. That is a different type of document, but it serves as an example of this type of diagram, while also illustrating that DFDs can be used on more than one context.

See also http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm

A tutorial on data flow diagrams can be found at http://www.smartdraw.com/resources/centers/software/dfd2.htm.

Control Flow Diagram

The above example of a flowchart-type control-flow process diagram is reproduced from http://www22.verizon.com/wholesale/local/order/wsg_lo_prcdiagram/0,19414,,00.html.

The diagram above is reproduced from tutorial at http://government.popkin.com/methods/idef.htm.

The diagram above is reproduced from overview of tutorial on IDEF3 and other IDEF standards at http://www.idef.com/default.html.

See also IDEF0, e.g., the tutorial at http://www.campbell.berry.edu/faculty/jgrout/idef0/ and the actual NIST standard at http://www.itl.nist.gov/fipspubs/idef02.doc.

State Charts

State diagrams or state charts are also used to describe processes.

See also the notes on statecharts in the Chapter 12 notes.

UML Object Diagram for Comm. Controller

UML State Chart Detail for Send_Transaction

UML State Chart Detail for Receive_Transaction

More Complex UML State Chart, With Nested States