Phases

• We can think of developing a software

requirements specification document as a two-
Requirements Analysis phase process
and Specification – Problem analysis: Goal is to understand the purpose of
the software, who will use it, what is the required
functionality, constraints on acceptable solutions,
possible trade-offs between conflicting constraints
– Requirements specification: Goal is to create the
requirements document describing exactly what is to be
built. The requirements document captures the results
of the problem analysis

Requirements CS172 2005 Requirements CS172 2005

1 2

Problem Analysis Eliciting Requirements

• Basic issues:
– How to effectively elicit a complete set of requirements
from the customer or other sources?
– How to decompose the problem into intellectually
manageable pieces?
– How to organize the information so it can be
understood?
– How to communicate about the problem with all the
parties involved?
– How to resolve conflicting needs?
– How to know when to stop?
To elicit the requirements
• Interviews with the customer
• Use questionnaires if there are multiple users
• Investigate the environment where the product
will be used
– investigate the customer’s business
• Scenarios: walk through different scenarios of
how the product will be used by the customer
– understandable to the customer
– can uncover additional requirements

Requirements CS172 2005 Requirements CS172 2005

3 4

Requirements Document Terminology

Defines the product that is to be developed in
Requirement - A specification of capabilities that
a way that is satisfactory to both the
a system must provide in order to solve a
customer and the developer
problem
Will be referenced by
– Software designers
The things about a system that a user can
– System implementers
observe
– System testers
– Those responsible for maintaining the
completed system
Requirements CS172 2005 Requirements CS172 2005
5 6

1
 Requirements Include More Terminology
• Functional requirements
• Performance requirements Constraint - Limitation on possible
• Hardware implementations of the system
• Firmware
• Software Goal - A statement that guides tradeoffs
• User interface among design decisions
• Development standards
• Quality assurance standards

Requirements CS172 2005 Requirements CS172 2005

7 8

Goals vs. Requirements Requirements Document Objectives

A goal may become a requirement if it can be
quantified
Examples:
• The system should be delivered in 12 months
• The system should make user’s job more interesting
• The system should make transactions more efficient
• The system should reduce the cost of a transaction
by 25%
• The system should be robust
• The system shall be fully operational 95% of each
24-hour period
• The development process should enhance the
professional skills of quality assurance personnel
Requirements CS172 2005
9 10
• Specifying external behavior only
– Expressing requirements in terms of possible
implementations restricts the software designer too much
• Specify constraints on the implementation
– Particularly for imbedded systems
– Details of software/hardware interfaces
• Should be easy to change
– Requirements will change, so requirements documents
should be easy to change
Requirements CS172 2005

Requirements Document Objectives Requirements Document Objectives

• Should serve as a reference too
– Primary function of the document is to answer specific
questions quickly • Characterize acceptable responses to
– Precision and conciseness are valued undesired events
– Not a tutorial
– Should be anticipated during requirements
definition
• Should record forethought about the life-cycle of
the system – Should not be left up to the programmer
– What types of changes are likely to occur – Hardware failures, user errors, unexpected
– What functions would maintainers like to be able to input, etc.
remove easily

Requirements CS172 2005 Requirements CS172 2005

11 12

2
 Requirements Document
Requirements Document
Design Principles
Design Principles
• State questions before trying to answer them (continued)
– Generate questions from common sense
– Organize them into forms • Use precision notation
– Generate more questions by trying to fill in the blanks – Avoid prose and use formal ways to present
– Revise the form information
– Be precise, consistent, complete
• Separate Concerns
– Each section of the document concerned with a different
topic

Requirements CS172 2005 Requirements CS172 2005

13 14

Requirements Document Requirements Document

Table of Contents Table of Contents
Introduction Chapter 8 Fundamental Assumptions
Chapter 1 Computer and OS Characteristics Chapter 9 Changes
Chapter 2 Hardware/Software Interface Chapter 10 Glossary
Chapter 3 Software Functions Chapter 11 Sources
Chapter 4 Timing Constraints
Chapter 5 Accuracy Constraints “Specifying Software Requirements for Complex Systems: New
Techniques and Their Application”
Chapter 6 Response to Undesired Events - Henzinger, IEEE TSE, Vol. SE-6, No. 1, January, 1980
Chapter 7 Subsets
Requirements CS172 2005 Requirements CS172 2005
15 16

Introduction Chapter 1
Computer and OS Characteristics
• If the computer/OS is predetermined, a
• Organization principles
description with particular attention to
• Abstracts for other sections idiosyncrasies
• Notational guide • If not predetermined, a summary of required
characteristics

Requirements CS172 2005 Requirements CS172 2005

17 18

3
 Chapter 2 Chapter 3
Hardware/Software Interface Software Functions

• Concise description of information received • What the software must do to meet its
or transmitted by the system requirements
• in various situations
• in response to various events

Requirements CS172 2005 Requirements CS172 2005

19 20

Chapter 4 Chapter 5
Timing Constraints Accuracy Constraints

• How often and how fast each function must • How close output values must be to ideal
be performed values to be acceptable

Requirements CS172 2005 Requirements CS172 2005

21 22

Chapter 6 Chapter 7
Response to Undesired Events Subsets
• What the software must do if undesired • What parts of the system should be easy to
events occur remove
• e.g., the sensors go down, the pilot keys in • What subsets of the total system make a
invalid data, etc. useful system

Requirements CS172 2005 Requirements CS172 2005

23 24

4
 Chapter 8 Chapter 9
Fundamental Assumptions Changes
• The characteristics of the program that will • The types of changes that were made in
stay the same no matter what changes are similar systems
made
• The types of changes that are likely to be
made
• Assumptions often become changes
• Much easier to for a reviewer to recognize
an error rather than an omission

Requirements CS172 2005 Requirements CS172 2005

25 26

Chapter 10 Chapter 11
Glossary Sources

• Most documents are loaded with acronyms
and technical terms
• Useful for developers during development
• Useful for users when the system is
delivered
• Annotated list of documentation and
personnel, indicating the types of questions
each can answer

Requirements CS172 2005 Requirements CS172 2005

27 28

Final Requirements Document

Additional Sections in Fairley
Should Exhibit the Following Properties
• Each requirement is validated
• External Interfaces and Data Flow • It is in the language of the customer
• Acceptance Criteria • It contains no adverbs (“very”, “fast”)
• Design Hints and Guidelines • It is complete
• It includes the requirements other than functions
(performance, maintainability)
• It is explicit about constraints
• It is brief and readable
• It is signed by both the customer and the developer

Requirements CS172 2005 Requirements CS172 2005

29 30