Requirements Specification

Software Requirements Specification (SRS)

The requirements documentation that completely describes the behavior that is required of the softwarebefore the software is designed, built, and tested.

• overlap of the skills required for design, programming, and testing, and those required for requirements engineering.

Requirements Specification Document

• Clearly and accurately describes each of the essential requirements of the system / software and its external interfaces.
• Each requirement must be described in such a way that it is feasible and objectively verifiable by a prescribed method.
• Basis for contractual agreements between contractors or suppliers and customers
• Elaborated from elicitation notes
• Specifications are intended to a diverse audience
• Different levels of detail and formality is needed for each audience
• Different templates for requirements specifications (IEEE 830)

Requirements Elicitation

Requirements elicitation is the process through which a requirements analyst gathers, understands, reviews, and articulates the needs of the project's stakeholders and users.

Elicitation involves:

• fact-finding,
• validating one's understanding of the information gathered,
• and communicating open issues for resolution.

Objective: create a complete list of what the users believe are important requirements.

Requirements Elicitation (cont.)

Elicitation activities can include:

• interviews with the users, stakeholders, and anyone else whose perspective needs to be taken into account during the design, development, and testing of the software

• observation of the users at work

• distribution of discussion summaries to verify the data gathered in interviews

Use Cases

After requirements elicitation anf discussion summary has been distributed and reviewed, use cases required to be created.

A use case is a description of a specific interaction that a user may have with the software.

A use case contains a textual description of all of the ways that the intended users could work with the software through its interface.

Use cases do not describe any internal workings of the software.

• Simply show the steps that the user follows to use the software to do his work.
• All of the ways that the users interact with the software can be described in this manner.

Use Case Structure

A typical use case includes these sections:

• Name: Use case number and name
• Summary: Brief description of the use case
• Rationale: Description of the reason that the use case is needed
• Users: A list of all of the categories of users that interact with this use case
• Preconditions: The state of the software before the use case begins
• Basic Course of Events: A numbered list of interactions between the user and one or more users
• Alternative Paths: Conditions under which the basic course of events could change
• Postconditions: The state of the software after the basic course of events is complete

IEEE 830 Standard

IEEE 830: Recommended Practice for Software Requirements Specifications

• Describes the content and qualities of a good software requirements specification (SRS)
• Presents several sample SRS outlines

IEEE 830: Objectives

• Help software customers to accurately describe what they wish to obtain
• Help software suppliers to understand exactly what the customer wants
• Help participants to:
  • Develop a template for the software requirements specification (SRS) in their own organizations
  • Develop additional documents such as SRS quality checklists or an SRS writer's handbook

IEEE 830: Benefits

• Establish the basis for agreement between the customers and the suppliers on what the software product is to do
• Reduce the development effort
  • Elarly requirements  →  reduces later redesign, recoding, retesting
• Provide a basis for realistic estimates of costs and schedules
• Provide a basis for validation and verification
• Facilitate transfer of the software product to new users or new machines
• Serve as a basis for enhancement requests

How to produce a good SRS (IEEE 830: Section 4)

• Goals of SRS
  • Functionality, interfaces, performance, qualities, design constraints
• Environment of the SRS
  • Where does it fit in the overall project hierarchy
• Characteristics of a good SRS
  • Generalization of the characteristicsto the document
• Evolution of the SRS
  • Implies a change management process
• Prototyping
  • Helps elicit software requirements and reach closure on the SRS
• Including design and project requirements in the SRS
  • Focus on external behavior and the product, not the design and the production process

Structure of the SRS

Contents of SRS (IEEE 830, Section 5):

1. Introduction
2. General description of the software product
3. Specific requirements (detailed)
4. Additional information such as appendixes and index, if necessary

SRS: 1. Introduction

1.1. Purpose

• Describe purpose of this SRS
• Describe intended audience

1.2. Scope

• Identify the software product
• Enumerate what the system will and will not do
• Describe user classes and benefits for each

1.3. Definitions. Acronyms, and Abbreviations

• Define the vocabulary of the SRS (may reference appendix)

1.4. References

• List all referenced documents including sources

1.5. Overview

• Describe the content of the rest of the SRS
• Describe how the SRS is organized

1.6. Risk Analysis

• Describe the conclusions of risk analysis from using a risk template

SRS: 2. Overall Description

2.1. Product Perspective

• Present the business case and operational concept of the system
• Describe how the proposed system fits into the business context
• Describe external interfaces: system, user, hardware, software, communication
• Describe constraints: memory, operational, site adaptation

2.2. Product Functions

• Summarize the major functional capabilities
• Include the Use Case Diagram and supporting narrative (identify actors and use cases)
• Include Data Flow Diagram if appropriate

2.3. User Characteristics

• Describe and justify technical skills and capabilities of each user class

2.4. Constraints

• Describe other constraints that will limit developer's options:
  • regulatory policies;
  • target platform, database, network software, etc.;
  • development standards requirements

2.5. Assumptions and Dependencies

• List each of the factors that affect the requirements stated

2.6 Apportioning of Requirements

• Identify requirements that may be delayed until future versions

SRS: 3. Specific requirements

• Specify software requirements in sufficient detail to enable designers to design a system to satisfy those requirements and testers to verify requirements

• State requirements that are externally perceivable by users, operators, or externally connected systems

• Requirements should include, at a minimum, a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output
  • Requirements should have characteristics of high quality requirements
  • Requirements should be cross-referenced to their source.
  • Requirements should be uniquely identifiable
  • Requirements should be organized to maximize readability

3.1 External Interfaces

• Detail all inputs and outputs (complement, not duplicate, information presented in section 2)
• Examples: GUI screens, file formats

3.2 Functions

• Include detailed specifications of each use case, including collaboration and other diagrams useful for this purpose

3.3 Performance Requirements

• Include the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole.

3.4 Logical Database Requirements

• Include types of information used
• Include data entities and their relationships

3.5 Design Constraints

• Specify design constraints that can be imposed by other standards, hardware limitations, etc.
• Report format
• Data naming
• Accounting & Auditing procedures

3.6 Software System Attributes

• Reliability, Availability, Security, Maintainability, Portability

3.7 Organizing the specific requirements

• The main body of requirements organized in a variety of possible ways:
  • Architecture Specification
  • Class Diagram
  • State and Collaboration Diagrams
  • Activity Diagram (concurrent/distributed)

Annex A of IEEE 830

Section 3 (Specific Requirements) may be organized in many different ways based on

• Modes
• User classes
• Concepts (object/class)
• Features
• Stimuli
• Organizations