Requirements Engineering
Chapter 2
Requirements Elicitation
Dr. Eman S. Al-Maghary
Requirements Elicitation Def.
 Requirements Development (RD) - establishes an
agreement between the stakeholders (including the
developing team) on the requirements of the system.
 Elicitation – the process of identifying system
requirements from various sources through interviews,
workshops, workflow and task analysis, document
analysis, and other mechanisms.
 Elicitation is a collaborative process
2
Requirements Elicitation Def. (Cont.)
 “Elicitation“ is not the best word, because it
implies that requirements exist ‘out there’ in the
minds of stakeholders, and need only to be
discovered.
 But this term is very common, so we will use it also.
 However, remember that requirements are not
discovered, they are constructed in a collaborative
process.
 Also remember that the requirements engineer’s
job is to help users discover what they really need.
3
User Requirements
Traditionally, elicitation from stakeholders
of type “users” is considered to be a separate
important activity.
4
User Requirements Elicitation
Techniques
 Interviews – face-to-face communication with one or
a few users, closed (fixed questions) or open.
 Workshops – discussion in a focus group, facilitated
by an analyst.
 Market surveys – collecting a large amount of data
from a broad spectrum of potential users, usually with
a questionnaire.
 Examination of problem reports – analysis of users’
feedback on existing systems.
5
User Requirements Elicitation
Techniques (Cont.)
 Observation – watching users performing their jobs
and using legacy systems.
 It is difficult to explain how to tie a shoelace, but easy to
understand when see
 Ethnography – instead of passively observing, the
analyst actively participates in the users’ work
activities, in so achieving a deeper level of
understanding.
6
User classes
 Users classes may differ with respect to:
 The task they perform and the product features they use
(e.g. online auction’s buyer vs. seller).
 Their application domain experience and computer
systems expertise (e.g. novice vs. expert).
 The frequency with which they use the product (e.g.
regular vs. occasional).
 Their access privilege or security levels (e.g. guest vs.
ordinary).
 Some user classes may be defined as ‘favored’.
 Users in different user classes may have different
requirements.
7
Finding the voice of the user
 For every (in ideal case) user class, a representative (or
group) should be found.
 Traditional approaches:
 Focus group – a small group of ~10 people, may span
several user classes.
 Product champion – a single representative for a user
class.
8
Finding the voice of the user (Cont.)
 Important in both cases that:
 Representatives should be typical for their classes.


If a focus group includes only early adopters or blue-sky
thinkers, you may end up with many sophisticated and
technically difficult requirements that many of your target
users do not find interesting.
If a product champion is a more experienced, power user, you
may end up with a system that is difficult to use and learn for
most of your target users.
 Representatives speak for their class. Not for other
classes, and not just for themselves (personal views not
shared by others).
9
Surrogate users
 When it is impossible to involve an actual member of a
user class, surrogate user might be the only option.
 Dangers of surrogates:
 Former members of the user class: may have outdated
understanding
 Managers of real users: may lack understanding of the
user needs, will not be able to spend enough time on the
project
 Software developers who think they can speak for the
users: may lack understanding of the user needs, have
too much technical expertise as compared to normal
users.
10
Surrogate users (Cont.)
 Persona is a fictitious character that is created (and
well-described) to represent a user class.
 Using
a carefully crafted persona to explore
requirements might be better than appointing an
actual person who has too many biases to serve as a
representative user.
11
Hearing the voice of the user
 Interviews (one or a few users)
 Elicitation workshop (focus group)
 Both are, basically, brainstorming sessions.
 Important to ask good questions:
 “What do you want from the system?” is bad.
 “What do you need to do with the system?” is better.
 I.e. start with user requirements, not functional
requirements.
 Do not just ask, propose alternatives to consider.
 Keep everyone engaged, otherwise some may
dominate.
12
Human, Social and Organizational
Factors – Stakeholders (Cont.)
 Stakeholders
 software engineers
 system end-users
 managers of system end-users
 external regulators who check to make sure system
meets legal requirements
 domain experts
13
Hearing the voice of the user (Cont.)
 Make clear to everyone that discussing about some
functionality is not yet a commitment to
implement it – so they can feel free.
 On the other hand, it is important to stay in scope
and not to blue-sky thousands of requirements
14
Interpreting stakeholders’ input
Plus:
 Project requirements,
like a need to have a
manual,
 Development
constraints – time,
cost, Assumptions,
 Historical and context
setting information.
15
Interpreting stakeholders’ input (Cont.)
 Business requirements, e.g. “Save $Z per year in
maintenance costs that are consumed by legacy system
W..”
 User requirements, e.g. “I need to print label for a
package..”
 Business rules, e.g. “Must comply with <some law or
corporate policy>..”
 Functional requirements, e.g. “The system should send
an email to the Idea Coordinator whenever someone
submits a new idea..”
 Quality attribute, e.g. ”It would be distracting to wait
more than a couple of seconds for the response..”
16
Interpreting stakeholders’ input (Cont.)
 Constraints, e.g. “The browser must use 128-bit
encryption for all secure transactions..”
 External interface requirements, e.g. “Must be able to
read and write files in <some format>..”
 Data definitions, e.g. “The ZIP code consists of 5 digits
followed by an optional hyphen and four more digits..”
 Solution ideas, e.g. “Then I select the destination state
from a drop-down list..”
17
Design solution ideas
 User: “Then I select the destination state from a drop-down list..”
 Analyst: “Why from a drop-down list?”
 User: “This just seemed like a
good way to do it..”
 User: “Because we do the same
thing in several other places,
and I want it to be consistent.
Also, it prevents from entering
invalid data.”
 Analyst should disregard this,
while stating a user
requirement “The system
shall permit the user to
specify the state where he
wants to send the package”
 Analyst should consider
including this as a constraint.
 Still, the basic requirement is
“The system shall permit the
user to specify..”
18
Use-case approach
 The best-known and probably the best of known
approaches to user requirements elicitation.
 Use cases are central in the Unified Process and
UML.
 Is good because explicitly shifts the perspective
from functional (what system must do) to user’s
(what users must be able to do with the system).
 Functional requirements are then developed based
on the use cases.
19
Use-case approach (Cont.)
 A use case describes a sequence of interactions
between a system and an external actor(s).
 An actor is a person, another software system, or a
hardware device that interacts with the system to
achieve a useful goal.
 Type of actors do not correspond to user classes.
They rather represent the roles, which a user can
play.
 One of the actors is an end-user
20
 Case:
 Prepare a mailing label
 Scenario:
 Prepare a mailing label to send a package by
second-day air by carrier X
 Story:
 Chris wants to send a 2.5 pound package by
second-day air from Clackamas, Oregon, to
Elba, New York. He wants it insured for 75$
and wants a return receipt. The package has
to be marked fragile.
Level of abstraction
Use cases, scenarios, stories
21
Requirements Diagrams:
Traditional and OO Models
Systems Analysis and Design in a Changing World, 3rd Edition
22
The System Activities –
A Use Case / Scenario View
 Use case analysis used to identify and define all
business processes that system must support
 Use Case - single function performed by system for
those who use that function
 Actors
 Role played by user
 Outside automation boundary and organization
Systems Analysis and Design in a Changing World, 3rd Edition
23
Use Case Diagram
 Graphical models that summarize information about
actors and use cases
 System developer
 Looks at system as whole
 Identifies major uses from event table
 Identifies functions to be supported by new system
 Organizes use cases
Systems Analysis and Design in a Changing World, 3rd Edition
24
Simple Use Case with an Actor
Systems Analysis and Design in
a Changing World, 3rd Edition 25
Use Case Diagram with System
Boundary
Systems Analysis and Design in
a Changing World, 3rd Edition
26
Use Case of Customer Support System
27
Systems Analysis and Design in a Changing World, 3rd Edition
All Use Cases Including
Customer
Systems Analysis and Design in
a Changing World, 3rd Edition 28
<<Includes>> Relationships
 Documents situation where one use case requires the
services of a common subroutine
 Another use case is developed for this common
subroutine
 A common use case can be reused by multiple use cases
Systems Analysis and Design in a Changing World, 3rd Edition
29
Example of Order-Entry
Subsystem with <<Includes>>
Use Cases
Systems Analysis and Design in a Changing World, 3rd Edition
30
Developing a Use Case Diagram
 Starting points for use case development
 Use event table
 Identify all actors of the system
 Identify functions actors perform with system
 Develop flow of activities to identify various scenarios
 Common internal use cases can be identified and
separated into different use cases
Systems Analysis and Design in a Changing World, 3rd Edition
31
Use Case Detailed Descriptions
 Scenario, or use case instance, details sequence of
activities within use case
 Shows actor interacting with computer system stepby-step to carry out business activity
 May have several scenarios for single use case
 Analysts prefer to write narrative descriptions of use
cases instead of building activity diagrams
 Three levels: brief, intermediate, and fully developed
description
Systems Analysis and Design in
a Changing World, 3rd Edition 32
Brief Description of Create New Order
Use Case
Systems Analysis and Design in
a Changing World, 3rd Edition 33
Intermediate Description of the Telephone
Order Scenario for Create New Order
Systems Analysis and Design in
a Changing World, 3rd Edition
34
Web
Order Scenario for Create New
Order
Systems Analysis and Design in
a Changing World, 3rd Edition 35
Fully Developed Description of
Telephone Order Scenario for
Create New Order
Systems Analysis and Design in
a Changing World, 3rd Edition 36
Web
Order Scenario for Create New
Order
Systems Analysis and Design in
a Changing World, 3rd Edition 37
Use-case diagram
38
From major features to use cases
 Major features for the 1st release:
 FE-1: Order meals from the cafeteria





menu to be picked up or delivered.
FE-3: Create, view, modify, and
delete meal service subscriptions.
FE-4: Register for meal payment
options (1st release - payroll
deduction payments only).
FE-5: Request meal delivery.
FE-6: Create, view, modify, and
delete cafeteria menus.
FE-9: Provide system access through
corporate Intranet or through
outside Internet access by
authorized employees.
Use Cases
Actor
1.Order Meal
2.Change Meal Order
3.Cancel Meal Order
4.View Menu
5.Register for Payroll Deduction
6.Unregister for Payroll Deduction
7.Subscribe to Standard Meal
8.Modify Meal Subscription
9.Override Meal Subscription
Patron
1.Create Menu
2.Modify Menu
3.Define Meal Special
Menu
Manager
1.Prepare Meal
2.Generate Payment Request
3.Request Delivery
4.Generate System Usage Reports
Cafeteria
Staff
1.Deliver Meal
2.Record Meal Delivery
3.Print Delivery Instructions
Meal
Deliverer
39
Use case description
 The essential elements of a use case:
 A unique identifier.
 A name that states the user task, e.g. “Place an Order”.
 A short description.
 A list of preconditions – conditions that must be satisfied or states




in which the system must be in before the use case may begin.
A list of postconditions – conditions describing the state of the
system after the use case is successfully completed.
A numbered list of steps that shows the sequence of dialog
interactions between actors and the system that leads from the
preconditions to the postconditions.
a set of quality attributes attached to the use case, e.g. performance,
usability, etc. (elicitation may be difficult).
a set of business rules applicable to the use case.
40
Use case description (Cont.)
 Each use case is a collection of related usage scenarios. 3
main types:
 Normal course (primary scenario)(main flow) – the default
sequence of actions, which leads to satisfying the
postconditions and letting the users to achieve the goal.
 Alternative courses (secondary scenarios) – paths, which also
lead to success but involves a variation from the normal
course.
 Exceptions – conditions, which are, unless some recovery
mechanism is possible, prevent a use case from successfully
concluding.
41
A use case example
Use Case ID:
1
Use Case Name:
Order Meal
Actors:
Patron
Description:
A Patron accesses the Cafeteria Ordering System from the corporate intranet or from home,
optionally views the menu for a specific date, selects food items, and places an order for a
meal to be delivered to a specified location within a specified 15-minute time window.
Preconditions:
1.Patron is logged into COS.
2.Patron is registered for meal payments by payroll deduction.
Postconditions:
1.Meal order is stored in COS with a status of “accepted”.
2.Inventory of available food items is updated to reflect items in this order.
3.Remaining delivery capacity for the requested time window is updated to reflect this
delivery request.
Normal Flow:
1.0 Order a Single Meal
1.Patron asks to view menu for a specified date.
2. System displays menu of available food items and the daily special.
…
12. System stores order in database, sends e-mail to notify Cafeteria Staff, sends food
item information to Cafeteria Inventory System, and updates available delivery times.
Alternative Flows:
1.1 Order multiple meals (branch after step 4)
1.Patron asks to order another meal.
2.Return to step 2.
42
A use case example (Cont.)
Exceptions:
1.0.E.1 Current time is after order cutoff time (at step 1)
1. System informs Patron that it’s too late to place an order for today.
2a. Patron cancels the meal order.
2b. System terminates use case.
3a. Patron requests to select another date.
3b. System restarts use case.
1.0.E.2 No delivery times left (at step 1)
1.2.E.1 Can’t fulfill specified number of identical meals (at step 1)
Includes:
None
Priority:
High
Frequency of Use:
Approximately 400 users, average of one usage per day
Business Rules:
BR-1, BR-2, BR-3, BR-4, BR-8, BR-11, BR-12, BR-33
Special Requirements:
1.Patron shall be able to cancel the meal order at any time prior to confirming the order.
2.Patron shall be able to view all meals he ordered within the previous six months and repeat
one of those meals as the new order, provided that all food items are available on the menu
for the requested delivery date.
(Priority = medium)
Assumptions:
1.Assume that 30 percent of Patrons will order the daily special (source: previous six months of
cafeteria data).
Notes and Issues:
1.The default date is the current date if the Patron is using the system before today’s order cutoff time.
Otherwise, the default date is the next day that the cafeteria is open.
2.If Patron doesn’t want to have the meal delivered, the precondition requiring registration for payroll
deduction is not applicable.
3.Peak usage load for this use case is between 8:00am and 10:00am local time.
43
Use cases documentation template
 (See document “use case template”)
 Template and an example (Rational RequisitePro)
44
CRUD analysis
 CRUD – Create, Read/Report, Update, Delete
 Information Engineering (IE) technique to identify
event table events or develop use case diagram
 Compares identified use cases with domain model
class diagram
 Every class in class diagram must have use cases to
support creating, reading, reporting, updating, and
deleting object instances
 Confirms system integration requirements
Systems Analysis and Design in a Changing World, 3rd Edition
45
Verification on-the-fly – CRUDL
 CRUDL technique– Create, Read, Update, Delete, List
 Useful for quick, e.g. in the course of elicitation, analysis of
correlation between use cases and various data entities.
 Missing requirements or use cases might be identified.
 Interaction of uses cases might be revealed, e.g. when
several use cases update a data entity and in so may
interfere.
46
From use cases to functional
requirements
 Programmers
do
not
implement
business
requirements or use cases, they implement functional
requirements, specific bits of system behavior.
 A use case can be usually translated into a set of
functional requirements.
 However, then this set is to be extended with other
functional requirements, coming from other
stakeholders.
47
From use cases to functional
requirements (Cont.)
 Three possibilities for final documentation:
 Use Cases document only – all the additional functional
requirements are added to a use case description
 SRS only – software requirements specification
(focusing on functional requirements) is organized in
the following way: use cases or features are sections,
while functional requirements are the contents of those
sections.

Wiegers uses this alternative. Use cases document is an
intermediary only
 Use Case document and SRS – two separate documents
with traceability links defined.
48
Elicitation from other stakeholders
 The choice of techniques is mostly restricted to
interviews and workshops.
 Already developed use cases provide good basis for
discussion.
 Business rules (and implied by them requirements)
and other domain knowledge are elicited from experts
or, alternatively, from published documents.
 Compliance to a standard or regulation is often an
absolute requirement, which cannot be negotiated.
Thus, elicitation of such requirements has more of
‘discovery’.
49
Business rules
 Fact – immutable truth about data entities and their attributes. E.g. “Sales tax
is not computed on shipping charges”.
 Inference – establishes some fact based on the truth of certain conditions. E.g.
“Explosive chemicals are considered expired one year after its manufacture
date”.
 Computation – a rule involving a formula or an algorithm. E.g. “The unit price
is reduced by 10% for orders of 6 to 10 units, and by 20% for orders of more
than 10”.
 Action enabler – something that is to be done under specified conditions. E.g.
“When a chemical container expires, the person who possesses it must be
notified”.
 Constraint – a restriction on possible actions. E.g. “A borrower under 18 must
have a parent or a legal guardian as cosigner on a library loan”.
50
Examples of business rules
51