Lecture 4 - Requirements Elicitation
Lecture 4 - Requirements Elicitation
Ebrahim Karami
ENGI-9838
Software Engineering Practice
Winter 2024
Outline
Today:
Motivation: Software Lifecycle
Requirements elicitation challenges
Problem statement
Requirements specification
Types of requirements
Validating requirements
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
Design depends on analysis, testing can be done before
implementation
A Typical Example
of Software Lifecycle Activities
Use Case
Model
Software Lifecycle Activities
...and their models
Expressed in
terms of
Expressed in Structured
terms of by
Expressed in Structured
Realized by
terms of by
Implemented by
Expressed in Structured
Realized by
terms of by
class...
class...
class...
Use Case Application Solution
Domain Sub- Source
Model Domain
Objects systems Code
Objects
Software Lifecycle Activities
...and their models
Implemented by
Expressed in Structured
Realized by Verified
terms of by
By
class...
class... ?
class... ?
class....
Use Case Application Solution
Domain Sub- Source Test
Model Domain
Objects systems Code Case
Objects
Model
What is the best Software Lifecycle?
Typical Lifecycle questions:
Which activities should I select when I develop software?
What are the dependencies between activities?
How should I schedule the activities?
For now we assume we have a set of predefined activities:
Requirements Elicitation, Analysis, System Design, Detailed Design,
Implementation, Testing
Today we focus on the activity Requirements Elicitation.
Software Lifecycle Activities
Requirements System Detailed Implemen-
Analysis Testing
Elicitation Design Design tation
Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By
class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Case Model
Objects
First step in identifying the Requirements:
System identification
Two questions need to be answered:
1. How can we identify the purpose of a system?
What are the requirements, what are the constraints?
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
and/or user (“Requirements specification”)
Analysis:
Definition of the system in terms understood by the developer (Technical
specification, “Analysis model”)
Requirements Process: Consists of the activities Requirements
Elicitation and Analysis.
Techniques to elicit Requirements
Bridging the gap between end user and developer:
Questionnaires: Asking the end user a list of pre-selected
questions
Task Analysis: Observing end users in their operational
environment
Scenarios: Describe the use of the system as a series of
interactions between a specific end user and the system
Use cases: Abstractions that describe a class of scenarios.
Scenarios
Scenario
“that which is pinned to the scenery“ (Italian)
A synthetic description of an event or series of actions and events
A textual description of the usage of a system. The description is
written from an end user’s point of view
A scenario can include text, video, pictures and story boards. It
usually also contains details about the work place, social situations
and resource constraints.
More Definitions
Scenario: “A narrative description of what people do and
experience as they try to make use of computer systems and
applications”
[M. Carroll, Scenario-Based Design, Wiley, 1995]
A concrete, focused, informal description of a single feature
of the system used by a single actor
Scenario become the basis of interaction for a new design or
allow better understanding of the new design.
Scenario-Based Design
Scenarios can have many different uses during the software
lifecycle
Requirements Elicitation: As-is scenario, visionary scenario
Client Acceptance Test: Evaluation scenario
System Deployment: Training scenario
Scenario-Based Design: The use of scenarios in a software
lifecycle activity
Scenario-based design is iterative
Each scenario should be consisered as a work document to be
augmented and rearranged (“iterated upon”) when the
requirements, the client acceptance criteria or the deployment
situation changes.
Scenario-based Design
Participating actors
Bob, Alice and John.
After the scenarios are formulated
Find all the use cases in the scenario that specify all instances of how
to report a fire
Example from the Warehouse on Fire scenario:
“Bob… notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from
her car”
“Report Emergency“is a candidate for a use case
Describe each of these use cases in more detail
Participating actors
Describe the entry condition
Describe the flow of events
Describe the exit condition
Describe exceptions
Describe nonfunctional requirements
The set of all use cases is the basis for the Functional Model(see next
lecture)
Requirements Elicitation: Difficulties
and Challenges
Accurate communication about the domain and the system
People with different backgrounds must collaborate to bridge
the gap between end users and developers
Client and end users have application domain knowledge
Developers have solution domain knowledge
Requirements Requirements
elicitation Specification
:nonfunctional
requirements
:functional
model
:dynamic model
Constraints or
Quality requirements Pseudo requirements
Types of Nonfunctional Requirements
Usability
Reliability
Robustness
Safety
Performance
Response time
Scalability
Throughput
Availability
Supportability
Adaptability
Maintainability
Constraints or
Quality requirements Pseudo requirements
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
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
Some Quality Requirements Definitions
Usability
The ease with which actors can perform a function in a system
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
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.
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
What should not be in the
Requirements?
System structure, implementation technology
Development methodology
A rational design process: How and why to fake it (Parnas,
1986)
Development environment
Implementation language
Reusability
Additional Readings
Scenario-Based Design
John M. Carrol, Scenario-Based Design: Envisioning Work and Technology in System Development, John
Wiley, 1995
Usability Engineering: Scenario-Based Development of Human Computer Interaction, Morgan Kaufman,
2001
David Parnas
A rational design process: How and why to fake it, IEEE Transactions on Software Engineering, Volume 12
, Issue 2 (February 1986)
Heathrow Luggage System:
http://blogs.zdnet.com/projectfailures/?p=610
http://www.bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=FDX:US&sid=aY4IqhBRcytA