Requirements Analysis

&
Requirements Specification
Originally developed by Michael Madigan
StorageTek
Manager, PAL Engineering

Software Engineering of Standalone Programs

University of Colorado, Boulder

Requirements Engineering

Requirements Engineering
Requirements Elicitation
Requirements Specification
Requirements Management

Requirements Analysis
Requirements Verification

Requirements Analysis & Specification

Definitions
Requirements

Analysis

The process of studying and analyzing the customer and the

user/stakeholder needs to arrive at a definition of software
requirements.1

Requirements

Specification

A document that clearly and precisely* describes, each of the

essential requirements of the software and the external
interfaces.

(functions, performance, design constraint, and quality

attributes)

Each requirement is defined in such a way that its achievement

is capable of being objectively verified by a prescribed method;

for example inspection, demonstration, analysis, or test. 2

Types of Requirements
Functional

requirements
Performance requirements
Speed, accuracy, frequency, throughput
External interface requirements
Design constraints
Requirements are usually about what, this is a
how.

Quality

attributes

i.e. reliability, portability, maintainability,

supportability

What vs. How Dilemma3

User
UserNeeds
Needs
System
System
Requirements
Requirements
System
SystemDesign
Design
Software
Software
Requirements
Requirements
Software
Software
Design
Design

What
How
What
How
What
How
What
How

Requirements vs. Design

Requirements

Design

Describe what will be delivered3

Describe how it will be done3

Primary goal of analysis:

UNDERSTANDING3

Primary goal of design:

OPTIMIZATION3

There is more than one solution

There is only one (final) solution

Customer interested

Customer not interested (Most of

the time) except for external

Software Quality Attributes4

Correctness
Reliability

Rating = 1 (Num Errors/ Num LOC)

Can be allocated to subsystems
Efficiency
Integrity
Usability
Survivability
Maintainability
Verifiability
Flexibility
Portability
Reusability
Interoperability
Expandability

Analysis of Elicitation
results helps to create
a Vision

Settle on which problem

- Explain in the problem statement (2.2)
Marketing group establishes positioning of the product (2.3)
Stakeholder and User Summaries
- User is a special case of stakeholder
- Identify all stakeholders w.r.t. development:
Name Represents
Role
- Identify all users w.r.t. system:
Name Description
Stakeholder

Stakeholder Profiles (3.5)

Representative - who (name) is representing this stakeholder
type.
Description - brief description of the stakeholder type
Type - Qualify s-hs expertise, technical background, degree of
sophistication
Responsibilities - List s-hs key responsibilities with regard to
the system being developed - why a stakeholder?
Success Criteria - How does the stakeholder define success?
How rewarded?
Involvement - involved in the project in what way?
Requirements reviewer, system tester, ...
Deliverables* - required by the stakeholder
Comments/Issues - Problems that interfere w/ success, etc.

User Profiles (3.6)

Representative - Who represents this user? (might be a
stakeholder)
Description - of the user type
Type - qualify expertise, technical background, degree of
sophistication
Responsibilities - users key resp.s w.r.t. system being
developed
Success Criteria - how this user defines success? rewarded?
Involvement - How user involved in this project? what role?
Deliverables - Are there any deliverables the user produces?
For whom?
Comments/Issues - Problems that interfere w/ success, etc.
This includes trends that make the users job easier or
harder

User Environment (3.4)

-- working environment
of target user
Number of people involved in doing this now? Changing?
How long is a task cycle now? Changing?
Any unique environmental constraints: mobile, outdoors, inflight, etc.
Which system platforms are in use today? future?
What other applications are in use? Need to integrate?

Key Stakeholder or User Needs (3.7)

List key problems with existing solutions as perceived by
the stakeholder or user.
What are the reasons for this problem?
How is it solved now?
What solutions does the stakeholder want?
What is relative importance of solving each problem?

Alternatives and Competition (3.8)

Product Overview (4.)

(at last!)
4.1 Product perspective (context)
Put the product in perspective to other related products
and the users environment.
Independent?
Component of a larger system?
How do the subsystems interact with this?
Known interfaces between them and this component?
Block diagram

Product Overview (4.)

(at last!)
4.2 Summary of Capabilities
Customer Benefit
1.
2.
3.
4.

Supporting Features

Product Overview (4.)

(at last!)
4.3 Assumptions and dependencies
What factors affect the features above?
List assumptions that, if changed, ALTER this document
4.4 Cost and pricing -- not done by engineering
4.5 Licensing and installation -- different types of license
enforcement will create more requirements for the
development effort

Product Features (5.)

Whats a feature?
- high level capability necessary to deliver benefit to the user
- externally desired service that typically requires inputs to
achieve
Level of detail must be general -- this is not the requirements
spec for the developers.
Provide the basis for product definition, scope management,
and project management.
Each will be expanded in the use-cases or other
requirements
Externally perceivable by users or external systems

What is not in the

Product Features Section?
Design
Constraints

-- These go in section 6.

Design constraints
External constraints
Quality Ranges -- These go in section 7
ranges for performance, robustness, fault tolerance, etc. that
are not really features (specific capabilities, functions)

Precedence and
Priority (8.)
Which

features essential?

We will delay shipment in order to have these

We will postpone the feature in order to meet first-release goal

Other Product Requirements

These

are requirements that are not features (functions)

of the product
hardware platform requirements - system requirements -- supported host o.s.s, peripherals,

companion software
environmental requirements -- temperature, shock, humidity,
radiation, usage conditions, resource availability, maintenance
issues, type of error recovery
applicable standards -- legal, regulatory, communications

Documentation Requirements
What

must be developed to support successful

deployment?
User Manual?
Online Help?
Installation guide? Read Me file?
Labeling, packaging?

Vision Doc adds

basis for SRS

Use Case Internals -- Compare to example

in Larman text (p. 68 ff.). Terms: 73-78
Use

Case Name
Scope
Level
Primary Actor
Stakeholders & interests
Preconditions
Success Guarantee (postconditions)

Basic

Flow
Alternate Flows (extensions)
Error Flows
Subflows
Special requirements
Technology & data variations
list
Frequency of occurrence
Open Issues

Fully Dressed Example: Process

Sale, Larman text, p. 68 ff.
Primary Actor: Cashier
Stakeholders and Interests:
- Cashier: Wants accurate, fast entry, and no payment errors, as cash
drawer shortages are deducted from his/her salary.
- Salesperson: Wants sales commissions updated.
- Customer: Wants purchase and fast service with minimal effort. Wants
proof of purchase to support returns.
- Company: Wants to accurately record transactions and satisfy customer
interests. Wants to ensure that Payment Authorization Service payment
receivables are recorded. Wants some fault tolerance to allow sales
capture even if server components are unavailable. Wants automatic and
fast update of accounting and inventory.

Fully Dressed Example:

Process Sale, Larman text,
p. 68 ff. - continued
- Government Tax Agencies: Want to collect tax from every sale.
May be multiple agnecies such as national, state, and county.
- Payment Authorization Service: Wants to receive digital
authorization requests in the correct format and protocol. Wants to
accurately account for their payables to the store.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions): Sale is saved. Tax is
correctly calculated. Accounting and Inventory are updated.
Commissions recorded. Receipt generated. Payment authorization
approvals are recorded.

Fully Dressed Example: Process Sale,

Larman text, p. 68 ff. - continued
Main Success Scenario (of Basic
Flow):
1. - 10.
Extensions (Alternative Flows):
*a.
*b.
1a
2-4a

3a.
3b.
3c.
3-6a-c
4a
5a-c
6a
7a-f
9a-c

Fully Dressed Example: Process

Sale, Larman text, p. 68 ff. cont.
Special Requirements:
- Touch Screen UI on a large flat panel monitor. Text visible from 1 meter.
- Credit auth. response within 30 seconds 90% of the time.

...
Technology and Data Variations List:
...
Frequency of Occurrence: Could be nearly continuous.
Open Issues:
- What are the tax law variations?
- Explore the remote service recovery issue.
- What customization is needed for different businesses?

Now what -- after development of use case(s)

Look

for consistency, correctness, completeness

Most important for core requirements likely to be implemented

soon

By translation

to other formats

See Vision Document

State diagrams and tables
Event tables
Condition tables
Domain diagram (UML)

References
1

Requirements Analysis, Richard Thayer, SMC 10/97

Version 2, 1997
2 IEEE Guide for Software Requirements Specification,
IEEE 830-1998
3 Software Requirements:Objects, Functions, and
States, Prentice Hall, 1993
4 Software Quality Measurement for Distributed Systems,
RADC-TR-83-175