Lecture 5: Requirements Elicitation

Requirements Management and Systems Engineering

(ITKS451), Autumn 2008

Artem Katasonov
University of Jyväskylä

University of Jyväskylä
 In the previous episode:
g RE, and a software/system development project as such, starts with defining
business requirements, and a vision of the solution, consisting of set of
features enabling satisfaction of those business requirements.
g Those are documented in the project’s vision and scope document.

1.1. Background 1.2. Business 2.1. Vision

Opportunity Statement

1.3. Business Objectives

2.2. Major Features
1.4. Customer Needs

1.5. Business Risks 2.3. Assumptions

University of Jyväskylä
 In the previous episode (2):
g Vision and scope document should also include the stakeholders analysis and
a definition of project priorities.
g Project scope is the portion of the ultimate product vision that the current
project will address.
g Definition of the scope should be based on some quantitative analysis. This is
studied in detail in the Project Management discipline.
Feature Release 1 Release 2 Release 3

FE-1 Standard meals from lunch menu Accept orders also for breakfasts and
only; delivery orders may be paid dinners; accept credit and debit card
for only by payroll deduction payments

FE-2 Not implemented Not implemented Fully implemented

FE-3 Implemented if time permits Fully implemented

(medium priority)

FE-4 Register for payroll deduction Register for credit card and debit card
payments only payments

FE-5 Meals will be delivered only to Add delivery from cafeteria to selected off-
company campus sites site locations

FE-6 Fully implemented

FE-7 Not implemented Not implemented Fully implemented

FE-8 Not implemented Fully implemented

FE-9 Fully implemented

University of Jyväskylä
 Requirements elicitation
Requirements Engineering (RE)

Requirements Development (RD) Requirements Management (RM)

Elicitation Change control

Analysis
Version control
Negotiation
Status tracking
Documentation
Validation Tracing

g Requirements Development (RD) - establishes an agreement between the stakeholders

(including the developing team) on the requirements of the system.
g Elicitation – the process of identifying system requirements from various sources
through interviews, workshops, workflow and task analysis, document analysis, and
other mechanisms.
4

University of Jyväskylä
 Requirements elicitation (2)
g “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.
g But this term is very common, so we will use it also.
g However, remember that requirements are not discovered, they are
constructed in a collaborative process.
g Also remember that the requirements engineer’s job is to help users discover
what they really need (Ken Orr).

Stakeholder X 4
Negotiation Other stakeholders
1 Elicitation

Requirements Analyst
Validation 2
3 Analysis A shareable
document

University of Jyväskylä
 Elicitation is a collaborative process

University of Jyväskylä
 User requirements
g Traditionally, elicitation from stakeholders of
Business
Requirements
Features type “users” is considered to be a separate
important activity.
Vision and Scope Document

Business
Rules
User
Requirements
Quality
Attributes

Use-Case Document
Constraints

System Functional
Requirements Requirements External
Interfaces

Software Requirements
Specification (SRS)

University of Jyväskylä
 User requirements elicitation techniques
g Interviews – face-to-face communication with one or a few users, closed
(fixed questions) or open.
g Workshops – discussion in a focus group, facilitated by an analyst.

g Market surveys – collecting a large amount of data from a broad spectrum of

potential users, usually with a questionnaire.
g Examination of problem reports – analysis of users’ feedback on existing
systems.

g 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
g Ethnography – instead of passively observing, the analyst actively
participates in the users’ work activities, in so achieving a deeper level of
understanding.

University of Jyväskylä
 User classes
g In stakeholders analysis, all the users were probably seen as one group. Now
it is time to classify users into different user classes.

g 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).

g Some user classes may be defined as ‘favored’.

University of Jyväskylä
 User classes (2)
g Users in different user classes may have different requirements.

© Juba
- After drinking coffee, - Why??!! - Again something that
Viivi moves cakes, - It is somehow neater only woman
which have left like this. understands..
uneaten, to a smaller
plate.

g So, for a “pulla management system”, Wagner should be assigned to one

user class, while Viivi to another.

10

University of Jyväskylä
 Finding the voice of the user
g For every (in ideal case) user class, a representative (or group) should be
found.

g Traditional approaches:
– Focus group – a small group of ~10 people, may span several user classes.
– Product champion – a single representative for a user class.

g 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).

11

University of Jyväskylä
 Surrogate users
g When it is impossible to involve an actual member of a user class, surrogate
user might be the only option.
g 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.

g 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 (Wiegers, 2006)

12

University of Jyväskylä
 Hearing the voice of the user
g Interviews (one or a few users)
g Elicitation workshop (focus group)
– Both are, basically, brainstorming sessions.

g 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.
g Do not just ask, propose alternatives to
consider.
g Keep everyone engaged, otherwise some
may dominate.

13

University of Jyväskylä
 Hearing the voice of the user (2)
g Make clear to everyone that discussing about some functionality is not yet a
commitment to implement it – so they can feel free.

g On the other hand, it is important to stay in scope and not to blue-sky

thousands of requirements.

14

University of Jyväskylä
 Interpreting stakeholders’ input
Plus:
g Project requirements,
like a need to have a
manual,
g Development
constraints – time, cost,
g Assumptions,

g Historical and context-

setting information.

And all mixed together

Wiegers, 2003

15

University of Jyväskylä
 Interpreting stakeholders’ input (2)
g Business requirements, e.g. “Save $Z per year in maintenance costs that are
consumed by legacy system W..”
g User requirements, e.g. “I need to print label for a package..”
g Business rules, e.g. “Must comply with <some law or corporate policy>..”
g Functional requirements, e.g. “The system should send a email to the Idea
Coordinator whenever someone submits a new idea..”
g Quality attribute, e.g. ”It would be distracting to wait more than a couple of
seconds for the response..”
g Constraints, e.g. “The browser must use 128-bit encryption for all secure
transactions..”
g External interface requirements, e.g. “Must be able to read and write files in
<some format>..”
g Data definitions, e.g. “The ZIP code consists of 5 digits followed by an optional
hyphen and four more digits..”
g Solution ideas, e.g. “Then I select the destination state from a drop-down list..”

16

University of Jyväskylä
 Design solution ideas
g User: “Then I select the destination state from a drop-down list..”
g Analyst: “Why from a drop-down list?”

g User: “This just seemed like a g User: “Because we do the same

good way to do it..” thing in several other places, and
I want it to be consistent. Also, it
prevents from entering invalid
g Analyst should disregard this, data.”
while stating a user requirement
“The system shall permit the user
to specify the state where he g Analyst should consider including
wants to send the package” this as a constraint.
g Still, the basic requirement is
“The system shall permit the user
to specify..”

17

University of Jyväskylä
 Use-case approach
g The best-known and probably the best of known approaches to user
requirements elicitation.
g Use cases are central in the Unified Process and UML.
g 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).
g Functional requirements are then developed based on the use cases.

g A use case describes a sequence of interactions between a system and an

external actor(s).
g 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.
g One of the actors is an end-user

18

University of Jyväskylä
 Use cases, scenarios, stories
g Case:
– Prepare a mailing label

g Scenario:

Level of abstraction
– Prepare a mailing label to send a package by
second-day air by carrier X

g 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.
Wiegers, 2006

19

University of Jyväskylä
 Use-case diagram

Pay Bill

<<include>>

Write Check

<<include>>

Reconcile
Credit Card

Wiegers, 2003

20

University of Jyväskylä
 From major features to use cases
Major features for the 1st resease: Use Cases Actor
g FE-1: Order meals from the cafeteria 1.Order Meal Patron
menu to be picked up or delivered. 2.Change Meal Order
g FE-3: Create, view, modify, and delete 3.Cancel Meal Order
meal service subscriptions. 4.View Menu
5.Register for Payroll Deduction
g FE-4: Register for meal payment 6.Unregister for Payroll Deduction
options (1st release - payroll deduction 7.Subscribe to Standard Meal
payments only). 8.Modify Meal Subscription
g FE-5: Request meal delivery. 9.Override Meal Subscription
g FE-6: Create, view, modify, and delete 1.Create Menu Menu
cafeteria menus. 2.Modify Menu Manager
g FE-9: Provide system access through 3.Define Meal Special
corporate Intranet or through outside 1.Prepare Meal Cafeteria
Internet access by authorized 2.Generate Payment Request Staff
employees. 3.Request Delivery
4.Generate System Usage Reports
1.Deliver Meal Meal
2.Record Meal Delivery Deliverer
K. Wiegers 3.Print Delivery Instructions

21

University of Jyväskylä
 Use case description
g 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.

22

University of Jyväskylä
 Use case description (2)
g Each use case is a collection of related usage scenarios. 3 main types:
– Normal course (primary scenario) – 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.

© Juba

- I bought an electric - Damn electricity - Where will we sleep now?

adjustable bed. interruption! The -Well, it is OK for one night.
mattress is stuck.

23

University of Jyväskylä
 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 1.1 Order multiple meals (branch after step 4)

Flows: 1.Patron asks to order another meal.
2.Return to step 2.

K. Wiegers 24

University of Jyväskylä
 A use case example (2)
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 1.Patron shall be able to cancel the meal order at any time prior to confirming the order.
Requirements: 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.

K. Wiegers 25

University of Jyväskylä
 Use cases documentation template
g Karl Wiegers’ web-site - http://www.processimpact.com/goodies.shtml
g Template and an example

26

University of Jyväskylä
 A trap of the use-case approach
g Focusing on individual use cases and overlooking their interaction.

g Example:
– An airplane attempted landing on a wet runway.
– The plane's wheels were aquaplaning instead of turning.
– The plane's guidance system thought something like "I'm on the ground, but my
wheels aren't turning. So I must not be moving“.
– So, the system did not allow the pilot to engage reverse thrust.
– In result, the airplane overshot the runway.
(Jackson, 1995)

g The use case “Engage reverse thrust” was analyzed somewhat

independently of the use case “Land the Plane”, which resulted in an
oversimplified precondition – wheels must be turning.

27

University of Jyväskylä
 A trap of the use-case approach (2)
g Another example:
– A US air controller in Afghanistan used a Precision Lightweight GPS Receiver, a
“plugger”, to calculate coordinates for an air strike.
– Then the receiver’s battery died. The air controller changed the battery. Then he
sent the coordinates from the GPS receiver to a B-52 bomber.
– The device was programmed, on starting or resuming operation after a battery
change, to initialize the coordinates back to its own location.
– A 2,000-pound, satellite-guided bomb landed, not on the Taliban outpost, but on a
US battalion command post. Three soldiers were killed and 20 were injured.
(“‘Friendly Fire’ Deaths Traced to Dead Battery: Taliban Targeted, but US Forces Killed,”
Washington Post, 24 Mar. 2002, p. 21)

g It is mainly a human mistake, because the device was not especially

designed for coordinating air strikes. However, such design defect might
appear also in a dedicated device, if “Calculate and send coordinates” and
“Restart” use cases were analyzed completely independently.

28

University of Jyväskylä
 Verification on-the-fly – CRUDL
g 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.

Entity Vendor Note: None of

Use Case Order Chemical Requester use cases
Catalog
can delete a
Place Order C R R R, L
Requester.
Wiegers, 2003

Change Order U, D R R, L
This is
Manage Chemical possibly a
C, U, D
Inventory problem –
Report on Orders R R, L R, L missing use
Edit Requesters C, U, L case or step.

g Missing requirements or use cases might be identified.

g Interaction of uses cases might be revealed, e.g. when several use cases
update a data entity and in so may interfere (as in “plugger” case).
29

University of Jyväskylä
 What's Wrong with Use Cases? (S. Ferg)
g What's wrong with chocolate?
– Rich of calories and giving energy fast.
– Delicious, almost addictive.
– As a result, chocolate tempts us to ignore other foods and eat only chocolate.
– However, there aren't many essential nutrients in chocolate.
– So, if we eat only chocolate, we eat an unbalanced diet, and our health suffers.
g Salesmen push use cases as The Solution For All Your Requirements Methodology
Needs. But similarly to chocolate,
– Yes, use case approach gives good results, and gives them fast.
– Use cases are extremely attractive, due to their simplicity.
– As a result, people are tempted to ignore all other elicitation techniques.
– However, use cases are “nutritionally deficient”.
– So, if we utilize use case only, the quality of our software will suffer.

g There is nothing wrong with use cases, as such.

g Remember, however, that use cases elicit only user requirements, and that they are
neither the first nor the last step in requirements development.

30

University of Jyväskylä
 From use cases to functional requirements
g Programmers do not implement business requirements or use cases, they
implement functional requirements, specific bits of system behavior.
g A use case can be usually translated into a set of functional requirements.
g However, then this set is to be extended with other functional requirements,
coming from other stakeholders.

g 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.

31

University of Jyväskylä
 Elicitation from other stakeholders
g The choice of techniques is mostly restricted to interviews and workshops.

g Already developed use cases provide good basis for discussion.

g 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’.

32

University of Jyväskylä
 Governmental requirements

33

University of Jyväskylä
 Business rules
Business Rules

Facts Inferences Computations Action Enablers Constraints

g Fact – immutable truth about data entities and their attributes. E.g. “Sales tax is not
computed on shipping charges”.
g Inference – establishes some fact based on the truth of certain conditions. E.g.
“Explosive chemicals are considered expired one year after its manufacture date”.
g 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”.
g 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”.
g 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”.

Wiegers, 2003

34

University of Jyväskylä
 Examples of business rules
ID Rule Definition Type May change? Source
BR-1 Delivery time windows are 15 minutes, Fact Static Cafeteria
beginning on each quarter hour. Manager
BR-2 Deliveries must be completed between Constraint Dynamic Cafeteria
10:00am and 2:00pm local time. Manager
BR-4 All meals in a single order must be paid for Constraint Static Cafeteria
using the same payment method. Manager
BR-12 Order price is calculated as the sum of each Computation Dynamic cafeteria
food item price times the quantity of that food policy; state
item ordered, plus applicable sales tax, plus a tax code
delivery charge if a meal is delivered outside
the free delivery zone.
BR-33 Network transmissions that involve financial Constraint Static corporate
information or personally identifiable information security
require 128-bit encryption. policy
BR-88 An employee may register for payroll deduction Constraint Dynamic Corporate
payment of cafeteria meals if no more than 40 Accounting
percent of his gross pay is currently being Manager
deducted for other reasons.

K. Wiegers 35

University of Jyväskylä
 Lecture 5: Main points
g Requirements elicitation is a collaborative process, in which a system
stakeholder and a requirements analyst attempt to construct a proposition of
a solution to those problems of that stakeholder, which are to be solved by
the developed system.

g For elicitation from stakeholders of type “users”, use case approach is good.

g Remember, however, that users are not the only stakeholders to consider,
and that use cases can be neither the first nor the last step of requirements
development.

g Remember also to consider different user classes, analyze alternative

courses and exceptions for a use case, and consider possible interferences
and dependencies among use cases.

36

University of Jyväskylä
 Following next:

g Requirements validation and verification, including:

g Little is invented beyond basic reviewing..

g However, different reading techniques may help..

g Rewriting requirements in alternative forms turns out to be useful..

g Prototypes, visualizations, test cases, etc..

37

University of Jyväskylä