Chapter 4: Requirements Elicitation

1
Chapter 4 Requirements Elicitation

• Qutaibah Malluhi
• Software Engineering
• Qatar University

Based on slides by Bernd Bruegge Allen H.
Dutoit
2
Overview
3
Agenda

• Overview
• What is requirement elicitation?
• Requirements are challenging
• Concepts
• Problem statement
• Types of requirements
• Requirements validation
• Types of requirement elicitation
• Scenarios
• Use cases
• Requirements elicitation activities

4
Where are we right now?

• Three ways to deal with complexity
• Abstraction
• Decomposition (Technique Divide and conquer)
• Hierarchy (Technique Layering)
• Two ways to deal with decomposition
• Object-orientation and functional decomposition
• Functional decomposition leads to unmaintainable
  code
• Depending on the purpose of the system,
  different objects can be found
• What is the right way?
• Start with a description of the functionality
  (Use case model). Then proceed by finding objects
  (object model).
• What activities and models are needed?
• This leads us to the software lifecycle we use in
  this class

5
Software Lifecycle Definition

• Software lifecycle
• Set of activities and their relationships to each
  other to support the development of a software
  system
• Typical Lifecycle questions
• Which activities should I select for the software
  project?
• What are the dependencies between activities?
• How should I schedule the activities?
• What is the result of an activity

6
Example Selection of Software Lifecycle
Activities for a specific project
The Hacker knows only one activity
Implementation
Activities used this course
System Design
Object Design
Implemen- tation
Testing
Requirements Elicitation
Analysis
Each activity produces one or more models
7
Software Lifecycle Activities
System Design
Object Design
Implemen- tation
Testing
Requirements Elicitation
Requirements Analysis
Implemented By
Expressed in Terms Of
Structured By
Realized By
Verified By
?
?
Application Domain Objects
Solution Domain Objects
Use Case Model
Source Code
SubSystems
Test Cases
8
What is Requirement Elicitation?
9
Requirements

• Elicitation What does the customer want?

10
Requirements Elicitation
I want you to build a game ...
client
game developer
11
Requirements Elicitation
I want an RPG better than anything seen before!
game developer
client
12
Requirements Elicitation
Ok ... off you go! Call me when its done.
game developer
client
13
Requirements

• Problem Statement What does the customer say
  they want?
• Elicitation What does the customer really want?

14
Requirements Elicitation
Oh yeah ... Here is the description of the game.
game developer
client
15
Requirements Elicitation
BTW, it needs to be done in 3 months and I only
want to pay you 3000 to build it.
game developer
client
16
Requirements

• Problem Statement What does the customer say
  they want?
• Elicitation What does the customer really want?
• Analysis Formalize, analyze ? What can provide?

17
Requirements Elicitation
I want an RPG better than anything seen before!
game developer
client
18
Requirements Elicitation
Oh yeah ... Here is the description of the game.
game developer
client
19
Requirements Elicitation
It needs to be ready in 3 months!
game developer
client
20
So how much will it cost?
game developer
client
21
Requirements Analysis
Just write a blank check. Ill fill in the
amount when Im done!
game developer
client
22
Requirements

• Problem Statement What does the customer say
  they want?
• Elicitation What does the customer really want?
• Analysis Formalize, analyze ? What can provide?
• System Requirements Specification What do we
  agree to provide?

23
Requirements Specification
Game Design Document
game developer
client
System Requirements Specification
24
First Step in Establishing the Requirements
System Identification

• The development of a system is not just done by
  taking a snapshot of a scene (domain)
• Important requirement process questions
• How can we identify the purpose of a system?
• How to define of the system boundary
• What is inside, what is outside the system?
• Two general requirement activities
• Requirements Elicitation Definition of the
  system in terms understood by the customer
• Problem Description and System Specification
• Requirements Analysis Technical specification of
  the system in terms understood by the developer
• Analysis model

25
System Specification vs. Analysis Model

• Both models focus on the requirements from the
  user view of the system.
• System specification uses natural language
  (derived from the problem statement)
• The analysis model uses formal or semi-formal
  notation (for example, a graphical language like
  UML)
• The starting point is the problem statement

26
Products of Requirements Process
(Activity Diagram)
Problem Statement
system
specification
Model
analysis
model Model
27
Specifying Requirements is Challenging
28
Requirements are Hard

• The hardest single part of building a software
  system is deciding precisely what to build. No
  other part of the conceptual work is as difficult
  as establishing the detailed technical
  requirements, including all interfaces to people,
  to machines, and to other software systems. No
  other part of the work so cripples the resulting
  system if done wrong. No other part is more
  difficult to rectify later.
• Frederick P. Brooks Jr. in No Silver Bullet
  Essence and Accidents of Software Engineering.

29
Requirements are Hard

• The hardest single part of building a software
  system is deciding precisely what to build. No
  other part of the conceptual work is as difficult
  as establishing the detailed technical
  requirements, including all interfaces to people,
  to machines, and to other software systems. No
  other part of the work so cripples the resulting
  system if done wrong. No other part is more
  difficult to rectify later.
• Frederick P. Brooks Jr. in No Silver Bullet
  Essence and Accidents of Software Engineering.

30
Requirement Errors are Common

• 1992 Iowa State study of safety-critical errors
  in software systems for Voyager and Galileo

The majority of safety-critical software errors
were not caused in the design or implementation
process. They were due to errors in the
requirements specification. The systems as
specified were flawed.
31
Cost of Delay in Fixing Requirements Errors
Data Boehm Papaccio (1988) IEEE Trans.
Software Eng.
200-fold increase after delivery
Nominal unit cost
20-fold increase
32
Why Hard?

• Customers dont usually know what they want/need
• Even if they do know what they want/need, they
  are likely to change their minds
• Requires bridging communication gap between user,
  client and developer

33
Growth in requirements
increase in requirements during project life
Source Applied Software Measurement, Capers
Jones, 1997. Based on 6,700 systems.
34
Communication Gap

• Requires collaboration and communication of
  people with different backgrounds
• Users with application domain knowledge
• Developers with solution domain knowledge (design
  knowledge, implementation knowledge)
• Client with constraints (time, budget, etc.) (can
  be different than the users entity)
• Bridging the gap between user and developer
• Scenarios Example of the use of the system in
  terms of a series of interactions with between
  the user and the system
• Use cases Abstraction that describes a class of
  scenarios

35
Problem Statement
36
Problem Statement

• The problem statement is developed by the client
  as a description of the problem addressed by the
  system
• Other words for problem statement
• Statement of Work

37
Ingredients of a Problem Statement

• Current situation The Problem to be solved
• Description of one or more scenarios
• Requirements
• Functional and Nonfunctional requirements
• Constraints (pseudo requirements)
• Deliverables
• Project Schedule
• Major milestones that involve interaction with
  the client including deadline for deliverables
• Target environment
• The environment in which the delivered system has
  to perform a specified set of system tests
• Client Acceptance Criteria
• Criteria for the system tests

38
Current Situation The Problem To Be Solved

• There is a problem in the current situation
• Examples
• The response time when playing letter-chess is
  far too slow.
• I want to play Go, but cannot find players on my
  level.
• What has changed? Why can address the problem
  now?
• There has been a change, either in the
  application domain or in the solution domain
• Change in the application domain
• A new function (business process) is introduced
  into the business
• Example We can play highly interactive games
  with remote people
• Change in the solution domain
• A new solution (technology enabler) has appeared
• Example The internet allows the creation of
  virtual communities.

39
ARENA The Problem

• The Internet has enabled virtual communities
• Groups of people sharing common of interests but
  who have never met each other in person. Such
  virtual communities can be short lived (e.g
  people in a chat room or playing a multi player
  game) or long lived (e.g., subscribers to a
  mailing list).
• Many multi-player computer games now include
  support for virtual communities.
• Players can receive news about game upgrades, new
  game levels, announce and organize matches, and
  compare scores.
• Currently each game company develops such
  community support in each individual game.
• Each company uses a different infrastructure,
  different concepts, and provides different levels
  of support.
• This redundancy and inconsistency leads to
  problems
• High learning curve for players joining a new
  community,
• Game companies need to develop the support from
  scratch
• Advertisers need to contact each individual
  community separately.

40
ARENA The Objectives

• Provide a generic infrastructure for operating an
  arena to
• Support virtual game communities.
• Register new games
• Register new players
• Organize tournaments
• Keeping track of the players scores.
• Provide a framework for tournament organizers
• to customize the number and sequence of matchers
  and the accumulation of expert rating points.
• Provide a framework for game developers
• for developing new games, or for adapting
  existing games into the ARENA framework.
• Provide an infrastructure for advertisers.

41
Requirement Types

• FURPS
• Functional, Usability, Reliability, Performance,
  and Supportability
• ( constraints)

42
Types of Requirements

• Functional requirements
• Describe the interactions between the system and
  its environment independent from implementation
• Examples
• An ARENA operator should be able to define a new
  game.
• Nonfunctional requirements
• User visible aspects of the system not directly
  related to functional behavior.
• Examples
• The response time must be less than 1 second
• The ARENA server must be available 24 hours a
  day
• Constraints (Pseudo requirements)
• Imposed by the client or the environment in which
  the system operates
• The implementation language must be Java
• The system must interface to the dispatcher
  system written in 1956

43
Functional Requirements for SatWatch

• SatWatch is a wrist watch that displays the time
  based on its current location. SatWatch uses GPS
  satellites to determine its location and internal
  data structure to convert the location into a
  time zone.
• The information stored in SatWatch and its
  accuracy measuring time is such that the watch
  owner never needs to reset the time. 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.
• SatWatch determines the location using GPS
  satellites and, as such, suffers from the same
  limitations as all other GPS devices (e.g.,
  inability to determine location at certain times
  of the day in mountainous regions).
• SatWatch has a two-line display showing, on the
  top line, the time (hour, minute, second, time
  zone) and on the bottom line, the date (day,
  date, month, year). The display technology used
  is such that the watch owner can see the time and
  date even under poor light conditions.
• When the political boundaries change, the watch
  owner may upgrade the software of the watch using
  the WebifyWatch device (provided with the watch)
  and a personal computer connected to the Internet.

Focus on interactions between SatWatch and
external world (owner, GPS, WebifyWatch). No
implementation details (language, display tech,
etc.)
44
Nonfunctional Requirements

• URPS categories of nonfunctional requirements
• Usability ease of use
• E.g. GUI guidelines by client, color schemes,
  fonts, logos, help, documentation
• Reliability
• E.g. acceptable MTBF, ability to detect certain
  faults or to withstand specific security attacks
• Performance
• Response time, throughput, availability, accuracy
• Supportability ease of change after deployment
• Portability, adaptability (deal with additional
  application concepts), maintainability (deal with
  new technology, fix defects), internationalization
  (additional conventions, languages, etc.)

45
URPS Requirements Example (SatWatch)

• Any user who knows how to read a digital watch
  and understands international time zone
  abbreviations should be able to use SatWatch
  without the user manual
• As the SatWatch has not buttons, no software
  faults requiring the resetting of the watch
  should occur
• Satwatch should display the correct time zone
  within 5 minutes of the end of a GPS blackout
  period
• SatWatch should measure time within 1/100th
  second over 5 years
• SatWatch should display time correctly in all 24
  timezones
• SatWatch should accept upgrades to its onboard
  via the Webify Watch serial interface

46
Constraints (Pseudo Nonfunc. Reqs.)

• Implementation Requirements
• Tools, Programming Lang., hardware platforms
• Interface Requirements
• Imposed by external systems
• E.g., Formats, standards, legacy systems
• Operations Requirements
• E.g. sys administration and management req.
• Packaging Requirements
• E.g., installation media, internet download, etc.
• Legal Requirements
• Licensing, government regulations, certification
  issues

47
Constraints Example (SatWatch)

• All related software associated with SatWatch ,
  including the onboard software, will be written
  using Java, to comply with the current company
  policy
• SatWatch complies with the physical, electrical,
  and software interfaces defined by the
  WebifyWatch API 2.0

48
What is usually not in the requirements?

• It is desirable that none of the following is
  constrained by the client. Fight for it!
• System structure, implementation technology
• Development methodology
• Development environment
• Implementation language
• Reusability
• Notice we are considering budget and schedule to
  be project attributes rather than software
  requirements

49
Requirements Validation

• Critical step in the development process
• Usually after requirements elicitation or
  requirements analysis. Also at delivery (client
  acceptance test).
• Requirements validation criteria
• Correctness
• The requirements represent the proper clients
  view.
• Completeness
• All possible scenarios, in which the system can
  be used, are described, including exceptional
  behavior by the user or the system
• Consistency
• There are functional or nonfunctional
  requirements that contradict each other
• Realism
• Requirements can be implemented and delivered
  within constraints
• Traceability
• Each system function can be traced to a
  corresponding set of functional requirements

50
Types of Requirements Elicitation

• Greenfield Engineering
• Development starts from scratch, no prior system
  exists
• Triggered by user needs
• Requirements extracted from the end users and the
  client
• Re-engineering
• Re-design and/or re-implementation of an existing
  system using newer technology
• Triggered by technology enabler
• Requirements extracted from existing system
  users and client
• Interface Engineering
• Provide the services of an existing system in a
  new environment
• Triggered by technology enabler or new market
  needs
• Requirements extracted from existing systems
  users and client

51
Scenarios and Use Cases
52
Key conceptsUse cases and scenarios
abstract / general descriptions
Id like it to blah blah
When ABC, the system shall XYZ
John, the Dispatcher, is alerted to the emergency
by a beep of his workstation. The system queries
everyones online and . . .
Blahing
concrete / specific descriptions
53
Scenarios

• A narrative description of what people do and
  experience as they try to make use of computer
  systems and applications M. Carrol,
  Scenario-based Design, Wiley, 1995
• A concrete, focused, informal description of a
  single feature of the system used by a single
  actor.
• A single instance (of a use case)
• Does not attempt to describe all possible
  situations
• Expresses a specific occurrence of the use case
• a specific actor ...
• at a specific time ...
• with specific data.
• Can have many different uses during software
  lifecycle
• Requirements Elicitation As-is scenario,
  visionary scenario
• Client Acceptance Test Evaluation scenario
• System Deployment Training scenario

54
Types of Scenarios

• As-is scenario
• Used in describing a current situation. Usually
  used in re-engineering projects. The user
  describes the system.
• Example Description of Letter-Chess
• Visionary scenario
• Used to describe a future system. Usually used in
  greenfield engineering and reengineering
  projects.
• Can often not be done by the user or developer
  alone
• Example Description of an interactive
  internet-based Tic Tac Toe game tournament.
• Evaluation scenario
• User tasks against which the system is to be
  evaluated
• Example Four users (two novice, two experts)
  play in a TicTac Toe tournament in ARENA.
• Training scenario
• Step by step instructions that guide a novice
  user through a system
• Example How to play Tic Tac Toe in the ARENA
  Game Framework.

55
Scenario Example Warehouse on Fire

• Bob, driving down main street in his patrol car
  notices smoke coming out of a warehouse. His
  partner, Alice, reports the emergency from her
  car.
• Alice enters the address of the building, a brief
  description of its location (i.e., north west
  corner), and an emergency level. In addition to a
  fire unit, she requests several paramedic units
  on the scene given that area appear to be
  relatively busy. She confirms her input and waits
  for an acknowledgment.
• John, the Dispatcher, is alerted to the emergency
  by a beep of his workstation. He reviews the
  information submitted by Alice and acknowledges
  the report. He allocates a fire unit and two
  paramedic units to the Incident site and sends
  their estimated arrival time (ETA) to Alice.
• Alice received the acknowledgment and the ETA.

56
Documentation schema for the scenario

• Scenario name warehouse0nFire
• Participating actor instances
• bob, alice FieldOfficer
• john Dispatcher
• Flow of events
• Bob, driving down main street in his patrol car
  notices smoke coming out of a warehouse. His
  partner, Alice, activates the Report Emergency
  function from her FRIEND laptop.
• Alice enters the address of the building, a brief
  description of its location (i.e., northwest
  corner), and an emergency level. In addition to a
  fire unit, she requests severa1 paramedic units
  on the scene, given that the area appears to be
  relatively busy. She confirms her input and waits
  for an acknowledgment.
• John, the Dispatcher , is alerted to the
  emergency by a beep of his workstation. He
  reviews the information submitted by Alice and
  acknowledges the report. He creates allocates a
  fire unit and two paramedic units to the Incident
  site and sends their estimated arrival time (ETA)
  to Alice.
• Alice receives the acknowledgment and the ETA.

57
Observations about Warehouse on Fire Scenario

• Concrete scenario
• Describes a single instance of reporting a fire
  incident.
• Does not describe all possible situations in
  which a fire can be reported.

58
Next goal, after the scenarios are formulated

• Find all the use cases in the scenario that
  specifies all possible instances of how to report
  a fire
• Example Report Emergency in the first
  paragraph of the scenario 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 Special Requirements (Constraints
  Nonfunctional)

59
Use Cases

• A use case is a flow of events and actions that a
  user performs in order to complete a given task
• It is initiated by an actor
• The objective of use cases is to model the system
• from the point of view of how users interact with
  this system
• when trying to achieve their objectives.
• A use case model consists of
• a set of use cases
• an optional description or diagram indicating how
  they are related

60
Example Use Case Model for Incident Management
61
Use Case Example ReportEmergency

• Use case name ReportEmergency
• Participating Actors
• Field Officer (Bob and Alice in the Scenario)
• Dispatcher (John in the Scenario)
• Exceptions
• The FieldOfficer is notified immediately if the
  connection between her terminal and the central
  is lost.
• The Dispatcher is notified immediately if the
  connection between any logged in FieldOfficer and
  the central is lost.
• Flow of Events See next slide

62
Use Case Example ReportEmergency(Cont.)

• Flow of Events
• The FieldOfficer activates the Report Emergency
  function of her terminal. FRIEND responds by
  presenting a form to the officer.
• The FieldOfficer fills the form, by selecting the
  emergency level, type, location, and brief
  description of the situation. The FieldOfficer
  also describes possible responses to the
  emergency situation. Once the form is completed,
  the FieldOfficer submits the form, at which
  point, the Dispatcher is notified.
• The Dispatcher reviews the submitted information
  and creates an Incident in the database by
  invoking the OpenIncident use case. The
  Dispatcher selects a response and acknowledges
  the emergency report.
• The FieldOfficer receives the acknowledgment and
  the selected response.

63
Use Case Example ReportEmergency(Cont.)

• Entry Condition
• Field Officer his logged in to the system
• Exit Condition
• The Field Officer has received an acknowledgemetn
  and the selected response from the dispatcher, OR
• The Field Officer has received an explanation
  indicating why the transaction could not be
  processed
• Special Requirements
• The FieldOfficers report is acknowledged within
  30 seconds. The selected response arrives no
  later than 30 seconds after it is sent by the
  Dispatcher.

64
Use Case Associations

• A use case association is a relationship between
  use cases
• Important use case association types
• Include
• Used to represent functional decomposition
• Helps in reusing existing functionality
• Extends
• Make optional interactions explicit
• Handle exceptional cases.
• Generalization
• An abstract use case has different specializations

65
ltltIncludegtgt Functional Decomposition

• Problem
• A function in the original problem statement is
  too complex to be solvable immediately
• Solution
• Describe the function as the aggregation of a
  set of simpler functions. The associated use case
  is decomposed into smaller use cases

ltltincludegtgt
ltltincludegtgt
ltltincludegtgt
CloseIncident
HandleIncident
CreateIncident
66
ltltIncludegtgt Reuse of Existing Functionality

• Problem
• There are already existing functions. How can we
  reuse them?
• Solution
• The include association from a use case A to a
  use case B indicates that an instance of the use
  case A performs all the behavior described in the
  use case B (A delegates to B)
• Example
• The use case ViewMap describes behavior that
  can be used by the use case OpenIncident
  (ViewMap is factored out)

Base Use Case
Supplier Use Case
Note The base case cannot exist alone. It is
always called with the supplier use case
67
ltExtendgtgt Association for Use Cases

• Problem
• The functionality in the original problem
  statement needs to be extended.
• Solution
• An extend association from a use case A to a use
  case B indicates that use case B is an extension
  of use case A.
• Example
• The use case ReportEmergency is complete by
  itself , but can be extended by the use case
  Help for a specific scenario in which the user
  requires help

Note The base use case can be executed without
the use case extension in extend associations.
68
Generalization association in use cases

• Problem
• You have common behavior among use cases and want
  to factor this out.
• Solution
• The generalization association among use cases
  factors out common behavior. The child use cases
  inherit the behavior and meaning of the parent
  use case and add or override some behavior.
• Example
• Consider the use case ValidateUser, responsible
  for verifying the identity of the user. The
  customer might require two realizations
  CheckPassword and CheckFingerprint

CheckPassword
Parent Case
Child Use Case
CheckFingerprint
69
How to Specify a Use Case (Summary)

• Name of Use Case
• Actors
• Description of Actors involved in use case)
• Entry condition
• This use case starts when
• Flow of Events
• Free form, informal natural language
• Exit condition
• This use cases terminates when
• Exceptions
• Describe what happens if things go wrong
• Special Requirements
• Nonfunctional Requirements, Constraints

70
Requirements Elicitation Activities

• Identify actors
• Identify scenarios
• Identify use cases
• Identify relationships among use cases
• Refine use cases
• Identify nonfunctional requirements
• Identify participating objects

71
Summary

• The requirements process consists of requirements
  elicitation and analysis.
• Requirements elicitation is a challenging
  activity
• Scenarios
• Great way to establish communication with client
• Different types of scenarios As-Is, visionary,
  evaluation and training
• Use cases Abstraction of scenarios
• Pure functional decomposition is bad
• Leads to unmaintainable code
• Pure object identification is bad
• May lead to wrong objects, wrong attributes,
  wrong methods
• The key to successful analysis
• Start with use cases and then find the
  participating objects
• If somebody asks What is this?, do not answer
  right away. Return the question or observe the
  end user What is it used for?

72
Additional Slides
73
Defining the System Boundary is Often Difficult
What do you see here?
74
Where are the System Boundaries?
Animal Ear?
75
Where are the System Boundaries?
Dalmatian Dog?
76
Where are the System Boundaries?
Flying Eagle?