Chapter 5

 Understanding Requirements
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1
 Software Lifecycle Activities

Requirements System Implemen-

Elicitation
Analysis Testing
Design tation

Verified
Expressed in Structured By Implemented By
Terms Of By

class...
class...
class...
?
class....

Use Case Application

Subsystems Source Test
Model Domain
Objects Code Case Model
 Requirements Phase
 The development of a system is not just done by taking a
snapshot of a scene (domain)
 Two questions need to be answered:
 How can we identify the purpose (Goal) of a system?
 Identifying system boundaries: What is inside and outside the
system?
 These two questions are answered in the requirements
process
 The requirements process consists of two activities:
 Requirements Elicitation:
• Definition of the system in terms understood by the customer
(“Problem Description”)
 Requirements Analysis:
• Technical specification of the system in terms understood by the
developer (“Problem Specification”)
3
 Requirements Analysis and
Definition
 The requirements analysis and definition establish the
system's services, constraints and goals by consultation
with users.
 This phase can be divided into:
• Requirements analysis
• Requirements modeling
• Requirements specification
Requirements define the function of the system from the
client's viewpoint.
Why are requirements important?

Causes of failed software projects (Standish Group study, 1994)

Incomplete requirements 13.1%
Lack of user involvement 12.4%
Lack of resources 10.6%
Unrealistic expectations 9.9%
Lack of executive support 9.3%
Changing requirements & specifications
8.8%
Lack of planning 8.1%
System no longer needed 7.5%
The commonest mistake is to build the wrong system.
 Requirements in Software
Development

Feasibility and All process

Planning Requirements
models include a
requirements
activity
Design

Operation and
Implementation Maintenance
 Requirements in iterative
enhancement

Evaluation/acceptance
Requirements

Implementation Design
 Goals during the
requirements phase
• Understand the requirements in detail (analysis).
• Describe the requirements in a manner that is clear to the client.

• Describe the requirements in a manner that is clear to the

people who will design and implement the system.
The Requirements Documentation is the defining document
that describes the goals of the system that is being built.
It may form a legal contract between client and software
developers.
 The requirements process
Feasibility Requirements
Study Analysis
Requirements
Model
Feasibility Requirements
Report Work with Specification
Organize the
the client to requirements in
understand a systematic and
the understandable
requirements way Documentation of
Requirements
 Requirements analysis

High-level abstract description of requirements:

• Specifies external system behavior
• Understandable by customer, management and users
Should reflect accurately what the client wants:
• Services that the system will provide
• Constraints under which it will operate
 Requirements analysis
1. Identify the stakeholders:
Who is affected by this system?
Eitheran individual, group or organization who is
impacted by the outcome of a project
Can be within or outside the organization
Client
Senior management
Production staff
Computing staff
Customers
etc., etc., etc.,
Requirements analysis
Example: University Admissions System
• Applicants
• University administration
Admissions office
Financial aid office
Special offices (e.g., athletics, development)
• Computing staff
Operations
Software development and maintenance
• Academic departments
Requirements analysis

2. Understand the requirements in depth:

• Domain understanding
• Understanding of the real requirements of all
stakeholders
Requirements analysis

3. Organize the requirements:

• Classification into coherent clusters
• Recognize and resolve conflicts
 Types of Requirements
 Functional requirements
 Describe the interactions between the system and
its environment independent from the
implementation
“An operator must be able to define a new game“
 Nonfunctional requirements
 Aspects not directly related to functional behavior
“The response time must be less than 1 second”

15
 Realism and verifiability
 Requirements must be realistic, i.e., it must be possible
to meet them.
Wrong: The system must be capable of x (if no known
computer system can do x at a reasonable cost).
 Requirements must be verifiable, i.e., it must be
possible to test whether a requirement has been met.
Wrong: The system must be easy to use.
Right: After one day's training an operator should be able
to input 50 orders per hour.
 New and old systems
In requirements analysis it is important to distinguish:
• features of the current system
• proposed new features
Clients often confuse the current system with the
underlying requirement.
A new system is when there is no existing system.
A replacement system (or subsystem) is when a system is
built to replace an existing system.
 Requirements analysis:
negotiation with the client
Sometimes the client will request some functionality that is very
expensive or impossible. What do you do?
• Talk through the requirement with the client. Why is it
wanted? Is there an alternative that is equivalent?
• Explain the reasoning behind your concern. Explain the
technical, organizational, and cost implications.
• Be open to suggestions. Is there a gap in your
understanding? Perhaps a second opinion might show other
approaches.
Before the requirements phase is completed the client and
development team must resolve these questions.
 Eliciting Requirements
Co n d u c t FAST
m e e t in g s

Ma k e lis t s o f
fu n c t io n s , c la s s e s

Ma k e lis t s o f
c o n s t ra in t s , e t c .

fo rm a l p rio rit iz a t io n ?
Elic it re q u ire m e n t s
ye s no

Us e QFD t o in fo rm a lly d e fin e a c t o rs

p rio rit iz e p rio rit iz e
re q u ire m e n t s re q u ire m e nt s

d ra w u s e -c a s e
writ e s c e n a rio
d ia g ra m

Cre a t e Us e -c a s e s
c o m p le t e t e m p la t e

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 19
Quality Function Deployment
 Function deployment determines the “value”
(as perceived by the customer) of each
function required of the system
 Information deployment identifies data objects
and events
 Task deployment examines the behavior of the
system
 Value analysis determines the relative priority
of requirements

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 20
 Scenarios
 A textual description of the usage of a system. The
description is written from an end user’s point of view
 A concrete, focused, informal description of a single feature
of the system used by a single actor.
 A scenario can include text, video, pictures and story
boards. It usually also contains details about the work
place, social situations and resource constraints.

21
 Scenario Example
Scenario: ATM banking for the week.
1.Sally Jones places her bank card into the ATM.
2.Sally successfully logs into the ATM using her personal
identification number.
3.Sally deposits her weekly paycheck of $350 into her savings
account.
4.Sally pays her phone bill of $75, her electric bill of $145, her
cable bill of $55, and her water bill of $85 from her savings
account
5.Sally attempts to withdraw $100 from her savings account for
the weekend but discovers that she has insufficient funds
6.Sally withdraws $40 and gets her card back

22
Activities of Requirements Elicitation

 Identify scenarios
 Identify actors
 Identify use cases
 Identify relationships among use cases
 Identify non-functional requirements

23
Identifying Actors and Use Cases
 Actors are external entities that interact with
the system
 An actor can be a human or an external system
 Use cases represent a sequence of
interaction for a type of functionality

Functional
Modeling

24
Scenarios  Functional Model
Example: Buy Item Scenario

 The costumer “Mike” pickups bread and chees to

purchase
 Mike arrives at the checkout with the items
 Cashier “Bob” records purchases and collects 150
dollar payment
 Mike leaves with items

 Actors: Customer, Cashier

 Use Case: Purchase Item
 UML (Unified Modeling Language)
• Use case Diagrams
– Describe the functional behavior of the system as seen
by the user.
• Class diagrams
– Describe the static structure of the system: Objects,
Attributes, Associations
• Sequence diagrams
– Describe the dynamic behavior between actors and the
system and between objects of the system
• Statechart diagrams
– Describe the dynamic behavior of an individual object
• Activity Diagrams
– Model the dynamic behavior of a system, in particular
the workflow (essentially a flowchart)
26
 UML Use Case Diagram
Use Case
Watch

Actor.

ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery System boundary

Use case diagrams represent the functionality of the system

from user’s point of view
 Use Case Diagram Example
Scenario:
1. Jon selects the number of zones
to be traveled.
2. Distributor displays the amount of Passenger
30 due.
3. Jon inserts 100 bill
4. Distributor returns 70.
5. Distributor issues ticket.
PurchaseTicket
 Use Case Diagram for Quiz
System

TakeQuiz

QuizTaker
CheckGrades

Request
Regrade
Use Case Diagram for Quiz
System
SetQuiz

Instructor
Grade

Regrade
 <<includes>> Relationship
You can use the «include» stereotype to indicate
that one use case “includes” the contents of
another use case. This enables you to factor out
frequent common behavior.

Get
Order
«includes» «includes»

Place Track
Order Order
31
 <<extends>> Relationship
You can use the «extend» stereotype to indicate
that one use case is “extended” by another use
case. This enables you to factor out infrequent
common behavior.

Validate «extends»
Wrong UserId
User

32
 Relationships Example

Passenger

PurchaseMultiCard

PurchaseSingleTicket
<<includes>>
<<includes>>

CollectMoney
<<extends>> <<extends>>

NoChange Cancel
33
 <<extends>> Relationship Example

Passenger

PurchaseTicket

<<extends>>

<<extends>>

<<extends>>
OutOfOrder <<extends>>
TimeOut

Cancel NoChange
34
 <<includes>> Relationship Example

TakeQuiz <<includes>>

Authenticate
QuizTaker CheckGrades <<includes>>
 <<extends>> Relationship Example

<<extends>> Connection
Fails
QuizTaker TakeQuiz
 Use Cases in the Development
Cycle
• Use cases are a tool in requirements analysis
• Easy to discuss with clients
• Use cases are often hard to translate into class
models
• Scenarios are useful to validate use cases and
the design of a system.
 Elicitation Work Products
 a statement of need and feasibility.
 a bounded statement of scope for the system or product.
 a list of customers, users, and other stakeholders who
participated in requirements elicitation
 a description of the system’s technical environment.
 a list of requirements (preferably organized by function)
and the domain constraints that apply to each.
 a set of usage scenarios that provide insight into the use
of the system or product under different operating
conditions.
 any prototypes developed to better define requirements.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 38
Building the Analysis Model
 Elements of the analysis model
 Scenario-based elements
• Functional—processing narratives for software
functions
• Use-case—descriptions of the interaction between
an “actor” and the system
 Class-based elements
• Implied by scenarios
 Behavioral elements
• State diagram
 Flow-oriented elements
• Data flow diagram

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 39
Satellite Watch
SatWatch is a watch that displays the time
based on its current location. SatWatch
uses GPS satellites (Global Positioning
System) to determine its location data to
convert this location into a time zone.
SatWatch adjusts the time and date
displayed as the watch owner crosses
time zones and political boundaries. For
this reason, SatWatch has no buttons or
controls available to the user.

40
 Bank System
A customer can deposit or withdraw
money from his account. After each
process the system will update the
balance of the customer’s account. If the
deposit amount was more than $100000,
he will get a 1% bonus credit. Consulting a
bank employee is needed when a
customer wants to open a new account.

41
Publishing system
An author can submit a draft of the book
that he wants to publish. An author
should pay the publication fees in order
to proceed the submission process.
Then, an editor will review the book and
send suggestions to the author. After
revising the book, authors send their
revised books to the system in order to
sell them by agents.

42
 Online (website) car rental System
 The website shows different types of cars:
standard, family, and truck. Each category has its
own price.
 Customer can view all cars in all categories with
their related information and select a car for renting.
 If the selected car is not available, the website will
show the returning date for this car.
 The customer must specify the returning date when
he books the car.
 The owner of the agency can add new car, remove
car, and update prices.

43