CSE-862 SOFTWARE

REQUIREMENTS
ENGINEERING
LECTURE 4
Topic: Requirements
Elicitation-I
Reference: Text Book
Chapters 6, 7

Agenda
Requirements Elicitation
Elicitation Concerns
Barriers to Elicitation

Elicitation Plan
Stakeholders

What does the Customer

say?

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.

Requirements Elicitation
Elicitation is concerned with user
(second level) requirements
Addresses the following concerns:
Understanding the application domain
Understanding the problem
Identifying stakeholders
understanding stakeholder needs

Agenda
Requirements Elicitation
Elicitation Concerns
Barriers to Elicitation

Elicitation Plan
Stakeholders

Requirements Elicitation
Concerns
Application domain understanding
Knowledge of the general area where
the system is applied

Problem understanding
The details of the specific customer
problem where the system will be
applied must be understood

Requirements Elicitation
Concerns
Identifying stakeholders
understanding
needs/constraints

stakeholder

Understand, in detail, the specific needs

of people who require system support in
their work

Agenda
Requirements Elicitation
Elicitation Concerns
Barriers to Elicitation

Elicitation Plan
Stakeholders

Barriers to Elicitation
The "Yes, But" Syndrome
"Yes, but, hmmmmm, now that I see it,
what about this . . . ? Wouldn't it be nice
if . . . ? Whatever happened to . . . ?
Software development as an intangible
intellectual process.
Development teams typically compound
the problem by rarely providing anything
earlier than production code for the users
to interact with and to evaluate.

Barriers to Elicitation
The "Yes, But" syndrome is human
nature and is an integral part of
application development.
We should plan for it.
We can drastically reduce this
syndrome by applying techniques
that get the "Buts" out early.

Barriers to Elicitation
The "Undiscovered Ruins" Syndrome
In many ways, the search for requirements is
like a search for undiscovered ruins: the more
you find, the more you know remain.
You never really feel as though you have
found them all, and perhaps you never will.
Indeed,
software
development
teams
everywhere continually struggle to determine
when they are done with requirements
elicitation, that is, when have they found all
the requirements that are material or when
have they found at least enough?

Barriers to Elicitation
The "User
Syndrome

and

the

Developer"

arises from the communication gap

between the user and the developer.
Users and developers are typically from
different worlds, may even speak
different languages, and have different
backgrounds,
motivations,
and
objectives

Barriers to Elicitation
User and analyst speak different
languages
Even in same country
Miss-communication
Ease
of
omitting
obvious
information
Some people think that this is such
an obvious information that it does
not need to be conveyed explicitly

Barriers to Elicitation
Users have incomplete understanding
of their needs
Users have poor understanding of
computer capabilities and limitations
Analysts have poor knowledge of
problem domain

Barriers to Elicitation
Problem
Users do not know what
they want, or they know
what they want but
cannot articulate it.
Users think they know
what they want until
developers give them
what they said they
wanted.

Solution
Recognize the user as
domain expert; try
alternative communication
and elicitation techniques.
Provide alternative elicitation
techniques earlier:
storyboarding, role playing,
throwaway prototypes.

Analysts think they

Put the analyst in the user's
understand user problems place. Try role playing for an
better than users do.
hour or a day.

Agenda
Requirements Elicitation
Elicitation Concerns
Barriers to Elicitation

Elicitation Plan
Stakeholders

Elicitation Plan (1/2)

1. Elicitation objectives

such as validating market data, exploring use cases,

understanding application domain, understanding the
problem, understanding organizational context, or
developing a detailed set of requirements for the
system
2. Elicitation strategies and processes

for example, strategies for identifying stakeholders,

some combination of surveys, workshops, customer
visits, individual interviews, and other techniques,
possibly using different approaches for different
stakeholder groups
3. Products of elicitation efforts

Could be a list of use cases, a detailed SRS, an

analysis of survey results, or performance and quality
attribute specifications

Elicitation Plan (2/2)

4. Schedule and resource estimates
identify both development and customer
participants in the various elicitation
activities, along with estimates of the effort
and calendar time required

5. Elicitation risks
identify factors that could impede your
ability to complete the elicitation activities
as intended, estimate the severity of each
risk, and decide how you can mitigate or
control it

Agenda
Requirements Elicitation
Elicitation Concerns
Barriers to Elicitation

Elicitation Plan
Stakeholders

Stakeholder Identification
Stakeholder involvement is the only way
to avoid an expectation gap.
It's not enough simply to ask a few
customers what they want and then
start coding.
Identify major stakeholder categories
Select
representatives
from
each
category
Decide decision makers in case of
conflicts

Major Stakeholder
Categories
The Client
If building a product for in-house
consumption, the cost of construction
is most likely borne by the manager of
the users who will be the ultimate
operators of the product.
If building products for sale to people
outside
the
organization,
the
marketing department may assume
the role of client. In other words, it is
the marketers who have to be
satisfied.

Major Stakeholder
Categories
The
client
should
always
be
represented on the project.
Where many potential clients exist,
there
is
a
need
to
choose
representatives. For example
A member of the marketing department
A representative from a user/customer group
A combination of domain and usability
experts from within the organization.

Major Stakeholder
Categories
The Users
people who will ultimately operate your
product
build a checklist of the categories of people
who might conceivably use the product.
Role/job or work title.
any abnormal or unusual attributes, such as
users who would use your product while driving
or simultaneously with another product.
Also consider the user's physical location outside,
on an aircraft, in a public place etc.

User Classes
The frequency with which they use the
product
Their application domain experience
computer systems expertise
The features they use/tasks they perform
Their access privilege or security levels
(such as ordinary user, guest user, or
administrator)

Finding User
Representatives
For
in-house
deployment,
gain
access to actual users
For commercial software, engage
people from your current beta-testing
or early-release sites.
Setting up focus groups of current
users of your products or your
competitors' products.

Other Stakeholders

Consultants
Management
Subject Matter Experts
Core Team
Inspectors
Market Forces
Legal

Other Stakeholders

Negative Stakeholders
Industry Standard Setters
Public Opinion
Government
Special Interest Groups
Cultural Interests
Adjacent Systems

Other Stakeholders: Organizational

Chart

Stakeholder Map (Onion

Diagram)

Decision Makers Among

Stakeholders
Decisions should be made as low in the
organization's hierarchy as possible by
people who are close to the issues and well
informed about them.
Every group should select an appropriate
decision rulean agreed-upon way to
arrive at a decisionprior to encountering
their first decision (Gottesdiener 2001).
Participative
or
consultative
decision
making is preferable over consensus
decision making.

Decision Makers Among

Stakeholders
Requirements expressed by user managers
sometimes conflict with those from the
actual users in their departments.
the user requirements must align with the
business requirements,
managers who aren't members of the user class
should defer to the product champion who
represents their users.

When the product that the developers think

they should build conflicts with what
customers say they want,
the customer
decision.

should

normally

make

the