CIE 460

Fundamentals of
Software Engineering

Types of Requirements
Manar Elkady, Ph.D.
Object-Oriented Software Engineering
Using UML, Patterns, and Java
Elicitation
Chapter 4, Requirements
Outline
• Software Life cycle definition
• Requirements Process
• Types of Requirements
– Functional requirements
– Non-functional requirements
– Constraints
• Requirements Validation
Software Lifecycle Definition
• Software lifecycle
• Models for the development of software
• Set of activities and their dependency
relationships to each other to support the
development of a software system
• Examples:
• Analysis, Design, Implementation,
Testing
• Typical Lifecycle questions:
• Which activities should I select when I develop
software?
• What are the dependencies between
activities?
• How should I schedule the activities?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 4
Example of an Unintended Feature
From the News: London underground train
leaves station without driver!
What happened?
• A passenger door was stuck and did not close
• The driver left his train to close the passenger
door
• He left the driver door open
• He relied on the specification that said the train
does not move if at least one door is open

• When he shut the passenger door,

the train left the station without him

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 5
Example of an Ambiguous Specification

• During a laser experiment, a laser beam was

directed at a mirror on the Space Shuttle
Discovery.
• The test called for the laser beam to be reflected
back toward a mountain top.
• The user entered the elevation of the mountain
as “10,023,”
• The laser beam was reflected away from Earth.

• What is requirements elicitation?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 6
Requirements Process
:problem
statement

Requirements
Requirements
elicitation Specification

:nonfunctional
requirements

:functional
model

Analysis Analysis Model

:dynamic model

UML Activity Diagram :analysis object

model

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 7
First step in identifying the Requirements:
System identification
• Two questions need to be answered:
1. How can we identify the purpose of a system?
2. What is inside, what is outside the system?
• These two questions are answered during
requirements elicitation and analysis
• Requirements elicitation:
• Definition of the system in terms understood by the
customer (“Requirements specification”)
• Analysis:
• Definition of the system in terms understood by the
developer (Technical specification, “Analysis
model”)
• Requirements Process: Contains the activities
Requirements Elicitation and Analysis.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 8
Requirements Specification vs Analysis
Model
Both focus on the requirements from the user’s
view of the system
• The requirements specification uses natural
language (derived from the problem statement)
• The analysis model uses a formal or semi-formal
notation
• We use UML.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 9
Outline

• Software Life cycle definition

• Requirements Process
• Types of Requirements
• Functional requirements
• Non-functional requirements
• Constraints
• Requirements Validation
• Requirements Elicitation
• Techniques to elicit requirements
• Requirements elicitation activities

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 10
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”
• Constraints
• Imposed by the client or the environment
• “The implementation language must be Java “
• Called “Pseudo requirements” in the text book.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 11
Functional vs. Nonfunctional Requirements

Functional Requirements Nonfunctional Requirements

• Describe user tasks • Describe properties of the
that the system needs system or the domain
to support • Phrased as constraints or
• Phrased as actions negative assertions
“Advertise a new league” “All user inputs should be
“Schedule tournament” acknowledged within 1
second”
“Notify an interest group”
“A system crash should not
result in data loss”.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 13
Types of Nonfunctional Requirements

Constraints or
Quality requirements Pseudo requirements
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 14
Types of Nonfunctional Requirements

• Usability
• Reliability
• Robustness
• Safety
• Performance
• Response time
• Scalability
• Throughput
• Availability
• Supportability
• Adaptability
• Maintainability Constraints or
Quality requirements Pseudo requirements
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25 25
Types of Nonfunctional Requirements

• Usability • Implementation
• Reliability • Interface
• Robustness • Operation
• Safety • Packaging
• Performance • Legal
• Response time
• Licensing (GPL, LGPL)
• Scalability
• Certification
• Throughput
• Regulation
• Availability
• Supportability
• Adaptability
• Maintainability Constraints or
Quality requirements Pseudo requirements
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26 26
Some Quality Requirements Definitions
• Usability
• The ease with which actors can use a system
to perform a function
• Usability is one of the most frequently misused
terms ((“The system is easy to use”)
• Usability must be measurable, otherwise it is
marketing
• Example: Specification of the number of
steps – the measure! - to perform a
internet-based purchase with a web
browser
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28 28
Some Quality Requirements Definitions
• Robustness: The ability of a system to maintain
a function
• even if the user enters a wrong input
• even if there are changes in the environment
• Example: The system can tolerate
temperatures up to 90 C
• Availability: The ratio of the expected uptime of a
system to the aggregate of the expected up and
down time
• Example: The system is down not more than 5
minutes per week.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29 29
Nonfunctional Requirements: Examples
• “Spectators must be able to watch a
match without prior registration and
without prior knowledge of the match.”
 Usability Requirement
• “The system must support 10 parallel
tournaments”
 Performance Requirement
• “The operator must be able to add new
games without modifications to the
existing system.”
 Supportability Requirement
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30 30
What should not be in the Requirements?

• System structure, implementation technology

• Development methodology
• Parnas, How to fake the software development process
• Development environment
• Implementation language
• Reusability (what components are you reusing
from other systems).

• It is desirable that none of these above are

constrained by the client.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31 31
Outline

• Software Life cycle definition

• Requirements Process
• Types of Requirements
• Functional requirements
• Non-functional requirements
• Constraints
• Requirements Validation
• Requirements Elicitation
• Techniques to elicit requirements
• Requirements elicitation activities

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32 32
Requirements Validation
Requirements validation is a quality assurance
step, usually performed after requirements
elicitation or after analysis
• Correctness:
• The requirements represent the client’s
view
• Completeness:
• All possible scenarios, in which the system
can be used, are described
• Consistency:
• There are no requirements that contradict
each other.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33 33
Requirements Validation (2)
• Clarity: Requirements can only be
interpreted in one way
• Realism: Requirements can be implemented
and delivered
• Traceability: Each system behavior can be
traced to a set of functional requirements
• Verifiability: Once the system is built,
repeatable tests can be designed to
demonstrate that the system fulfills the
requirements specification.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34 34
Requirements Validation (3)

• Problems with requirements validation:

• Requirements change quickly during
requirements elicitation
• Inconsistencies are easily added with
each change
• Tool support is needed!

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35 35
Requirements Validation
• Correctness:
• Car rental prices shall show all applicable
taxes (including 6% state tax).
• Completeness:
• REQ1 A destination country does not need to
be displayed for flights within the U.S.
• REQ2 For overseas )‫ (السفر للقارات األخرى‬flights, the
system shall display a destination country.

Reference:
https://www.informit.com/articles/article.aspx?p=1152528&se
qNum=4

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36 36
Requirements Validation (2)
• Consistency:
• REQ1 Payment by PayPal shall be available.
• REQ2 Only credit card payments shall be
accepted.

Reference:
https://www.informit.com/articles/article.aspx?p=1152528&s
eqNum=4

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37 37
Requirements Validation (3)
• Clarity:
• REQ1 The system shall not accept
passwords longer than 15 characters
• Realism:
• REQ1 The system shall have a natural
language interface that will understand
commands given in English, Hebrew,
Arabic, Persian, and French languages.
• Traceability:
• REQ1 The system shall provide the
opportunity to book the flight, purchase a
ticket, reserve a hotel room, reserve a car,
and provide information about attractions.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38 38
Requirements Validation (4)
• Verifiability:
• Ex. 1: The interface shall be user-friendly

• Ex. 2: The search facility should allow the

user to find a reservation based on Last
Name, Date, etc.

• Ex. 3: The product shall respond to the

user with 1 second for most cases.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39 39
Required Reading

• Chapter 4: Sections 4.1, 4.2, and 4.3 from

Bruegge, Bernd, and Allen H. Dutoit. "Object-
‐Oriented Software Engineering. Using UML,
Patterns, and Java." Learning 5.6 (2009): 7.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44 44