Chapter 3

Requirement Elicitation and Analysis

By Yengusie D.
Contents
Requirements Elicitation
Difficulties of Requirements Elicitation
Components of Elicitation
Analysis & Negotiation
Elicitation , Analysis & Negotiation
The requirements elicitation process
The requirements Analysis & Negotiation Process
Elicitation Techniques
Traditional techniques
Collaborative techniques
Cognitive techniques
Contextual approaches
 Requirements elicitation
Encompass all activities involved in
discovering the requirements of a system
System developers and engineers work in
close relationship with customer and end-
users to
Find out and understand the problems to be
solved
Find out and understand the functionalities
of the system
Find out the required “performance” of the
It issolution
not as simple as “let’s ask the users
what they
Find outwant.”
constraints, such as hardware and
other, on the solution
Why ?
 Difficulties of Requirements
User/Customer:
Elicitation
1. Don’t always know all the requirements; may
only know their own respective areas
 May not know the grand, organizational
needs and objectives
 May not know the “politics” at play
2. May give conflicting requirements
3. May prioritize differently among themselves
4. May not have time or forget to give the
complete picture etc.

Requirements Analyst:
1. May not be a good listener
2. May not understand the domain (the domain
specific language) and misinterpret the
user/customer meaning
3. May not be trained, prepared or organized for
 Difficulties of Requirements
Elicitation…
Requirements elicitation is complicated by
three endemic syndromes.

The "Yes, But" Syndrome

For whatever reason, we always see two
immediate, distinct, and separate
reactions when the users see the system
implementation for the first time.
1. "Wow, this is so cool; we can really use this,
what a neat job" and so on.
2. "Yes, but, hmmmmm, now that I see it, what
about this ... ? Wouldn't it be nice if . . . ?
Whatever happened to . . . ?“
The "Yes, But" Syndrome

The "Yes, But" syndrome is human nature

and is an integral part of application
development.
 We should plan for it.
We can significantly reduce this syndrome
by applying techniques that get the "Buts"
out early.
In so doing, we elicit the "Yes, But"
response early, and we then can begin to
invest the majority of our development
efforts in software that has already passed
the "Yes, But" test.
 Difficulties of Requirements
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
 Difficulties of Requirements
Elicitation…
The "User and the Developer“
Syndrome
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.
Reasons for this problem and some suggested
solutions.
Components of Elicitation
Application domain
understanding
Application domain knowledge is
knowledge of the general area
where the system is applied.
 Problem understanding
 details of the specific customer
problem where the system will be
applied must be understood.
Business understanding
Understanding the needs and constraints of
understand how systems interact
system stakeholders
and contribute to overall business
understand, in detail, the specific needs of people
goals.
who require system support in their work.
Analysis & Negotiation
The objectives of requirement analysis &
negotiation is to establish an agreed set of
requirements which are complete and
consistent.
During analysis process
Missing requirements
Requirements conflict
Ambiguous requirements are
discovered
Overlapping requirements
Unrealistic requirements
For conflicting & ambiguous requirements
stakeholders should negotiate and agree on
Elicitation, analysis and
negotiation
The requirements elicitation
process

Objective setting: establish the overall

organizational objectives: why is the system
necessary?
Background of knowledge acquisition:
The requirements elicitation
process…

Knowledge organization: organize, prioritize

and collate/compare the large amount of data
collected in the previous phases
Stakeholder requirements collection:
Process of Requirements Elicitation:
Products of Requirements Process
.

uses natural language

uses formal (Z, pi-calculus) or semi-formal

notation (UML)
 Problem Statement
 The problem statement is developed by the
client as a condensed description of the
requirements that should be addressed by the
system
Describes the problem that should be solved
 It describes “what” is needed, not “how” it should be
reached
 The problem statement contains
Current situation: The Problem to be solved (a few
pages)
Description of one or more scenarios
Some initial requirements ( Functional and Non-
functional requirements. No complete description)
 Project Schedule ( Major milestones that involve
interaction with the client including deadline for delivery
Example: Library System
Idea: A Library Management System should be

designed. Information on books, CDs, DVDs, Journals,

etc. can be stored and retrieved. (problem statement)
Possible Requirements:

Searching by Title, Author, and/or ISDN should be possible

 User Interface should be web-based (accessible via WWW

Browser)
At least 20 transactions per seconds should be possible

All services should be available within 10 minutes

 Users have no access to personal data of other users

Elicitation techniques -
Introduction
Specific techniques which may be used to collect
knowledge about system requirements
This knowledge must be structured
Partitioning - aggregating related knowledge
Abstraction - recognizing generalities
 Projection – organizing knowledge from several
perspectives
 Requirements elicitation is cooperative process
involving requirements engineers and system
stakeholders.
Problems:
Not enough time for elicitation
Inadequate preparation by engineers
Stakeholders are unconvinced of the need for a new
system
 Elicitation techniques
Traditional techniques Cognitive techniques
 Introspection Task analysis
Reading existing documents
Protocol analysis
 Analyzing hard data
 Interviews Knowledge Acquisition
Open-ended Techniques
Structured Card Sorting
Surveys / Questionnaires Laddering
 Meetings Repertory Grids
Collaborative techniques Delphi Techniques
Group techniques Contextual
Focus Groups
Brainstorming
approaches
JAD/RAD workshops Ethnographic techniques
Prototyping Participant Observation
Participatory Design Ethnography
 Domain Analysis
 Introspection
Is the mental thoughts of the requirements engineering
about the wants and needs of the stakeholders about the
systems.
It amounts to imagining what kind of system I would want if I were
doing this job, using this equipment, etc.
The introspection technique is the starting point for other
requirement elicitation techniques.
Advantages
It helps the other elicitation techniques. So it is a good starting
activity for requirement elicitation.
There are almost no costs of this technique.
Disadvantages
In case of using the introspection the analyst should not only
be familiar with the domain and goals of the system, but also
should be expert in the business processes of the users.
In other words this technique requires a huge experience of the
requirement analyst.
Background Reading
Sources of information:
Company reports, organization charts, policy
manuals, job descriptions, reports, documentation of
existing systems, etc.
Advantages:
 Helps the analyst to get an understanding of the
organization before meeting the people who work
there.
Helps to prepare for other types of fact finding
e.g. by being aware of the business objectives of
the organization.
 May tell you the detailed requirements for the
current system.
Disadvantages:

“Hard Data” Collection
Identify Collections of Hard Data
Facts and figures, financial information,…
Reports used for decision making,…
Survey results, marketing data,…
Sampling
Sampling used to select representative set
from a population
Purposive Sampling - choose the parts you think
are relevant without worrying about statistical
issues
Simple Random Sampling - choose every kth
element
Stratified Random Sampling - identify
strata/class and sample each
“Hard Data” Collection…
Sample Size is important
balance between cost of data collection/analysis
and required significance
Process (How?):
Decide what data should be collected - e.g.
banking transactions
Determine the population to be sampled - e.g. all
transactions at 5 local branches over one week
Choose type of sample - e.g. simple random
sampling
Choose sample size - e.g. every 10th transaction
Example
of
hard data
 Interview
Probably the most common technique of
requirements elicitation.
Interviewers must be open-minded and should
not approach the interview with pre-conceived
notions about what is required
Stakeholders must be given a starting point
for discussion (a question, a requirements
proposal, an existing system)
 Interviewers must be aware of organizational
politics
 Some requirements may not be discussed because
of their political implications
Interviews with different stakeholders
Interviews Different Techniques
Structured (closed) interviews
Stakeholders answer a predefined set of
questions
Easy to analyze (+)
 Well-formed questions generate well-formed
answers (you have to know your goals) (+)
Knowledge about what and how to ask (-)
Non-structured (open) interviews
No predefined agenda
Generating new ideas (experimental, brain
storming) (+)
 sometimes hard to handle (dynamics of
discussion) (-)
Interviews: Written vs. oral interviews,
group vs. single
Oral interviews:
possibility to discussion (+)
interviewer may influence interviewee (-)
Written interviews
problems in understanding (-)
already transcribed, thus easy to analyze (+)
Interviewing a single person:
 individual opinions (+)

Interviewing a group of people: -

Involvement of many perspectives
Developer need experience to moderate (-)
Sometimes single or silent opinions are not noticed
(-)
Interviewing Tips
Prepare some initial questions  good entry
point
Do not press the interviewee through the
questionnaire
Restrict the time frame for the questionnaire
(approx. 1 hour)
Announce the estimated time for the interview
Short introduction for the purpose of the
interview
Make notes to the answers
Explain the purpose of the records (reduces
potential fear!)

Interviewing …
Advantages
Rich collection of information
Good for uncovering opinions, feelings, goals, as
well as hard facts
Can probe in depth, & adapt follow up questions
to what the person tells you
Disadvantages
Large amount of qualitative data can be hard to
analyze
Hard to compare different respondents
Interviewing is a difficult skill to master
Surveys and Questionnaires
Advantages
Can quickly collect info from large numbers of
people
Can be administered remotely
Can collect attitudes, beliefs, characteristics
Disadvantages
Simplistic (presupposed) categories provide very
little context
No room for users to convey their real needs
 Meetings
Used for summarization and feedback
E.g. meet with stakeholders towards the end of
each stage:
to discuss the results of the information gathering
stage
 to conclude on a set of requirements
 to agree on a design etc.
 Use the meeting to confirm what has been
learned, talk about findings
Meetings are an important managerial tool
Used to move a system development project
forward.
Need to determine objectives for the meeting:
E.g. presentation, problem solving, conflict
Meetings…
Plan the meeting carefully
Schedule the meeting and arrange for facilities
Prepare an agenda and distribute it well in
advance
Keep track of time and agenda during the
meeting
Follow up with a written summary to be
distributed to meeting participants.
 Group techniques
In the group work, different stakeholders are invited to
conduct the group meeting in a collaboration to elicit
the requirements of the system to be developed.
Two types:
Focus Groups
Brainstorming
Focus Groups
A kind of group interview
Groups are brought together to discuss some topic of
interest
produces data and insights that would be less
accessible without interaction found in a group setting
—listening to others’ verbalized experiences
stimulates memories, ideas, and experiences in
participants
 Brainstorming
Brainstorming refers to the process of systematic and
liberal generation of a large volume of ideas from a
number of participants.
So much severe criticism is not allowed in this type of
technique because due to this the biasness can be
generated.
The ideas are freely explained and everyone has to
interpret it in a very pleasant environment with some
informal discussion.
Brainstorming can be structured or unstructured
Unstructured brainstorming
Participants can give ideas as these come to mind
Quite often not very efficient
Structured brainstorming
Participants must follow in order to make the gathering of
inputs more orderly and more efficiently.
 Process of Structured
Brainstorming
State the central brainstorming theme in question form and
write it down where every participant can see (white board
or flipchart)
Ensure that all the members have a full understanding the question
Let each team member have a turn to give his or her input
as answer to the question.
If a team member can't think of any input when his or her turn comes,
he simply needs to say 'Pass,' and the next member gets the turn.
Write each input on the board or flipchart as it is given.
Nobody is allowed to criticize an input, no matter what.
Moderator writes down the input on the board or flipchart using exactly
the same words used by the input giver.
Repeat the brainstorming rounds until everybody says 'Pass'
in the same round ( ideas are exhausted).
Review each of the listed inputs for further improvement and
maximize its clarity.
Other team members can ask the input giver what he or she actually
means by his or her input.
 Group techniques: Pros &
Cons
Advantages
More natural interaction between people than
questioner & formal interview
It promotes free thinking and expression of
ideas.
Brainstorming provides the innovative ideas
about the project to be developed.
Disadvantages
May create unnatural groups (uncomfortable
for participants)
Brain storming is seriously affected by
exploring the critique ideas.
May only provide superficial responses
 Joint Application
Development
is a process used in the prototyping life cycle area of
the Dynamic Systems Development Method (DSDM)
to collect business requirements while developing
new information systems for a company.
involves continuous interaction with the users and
different designers of the system in development.
centers around a workshop session that is
structured and focused.
Participants of these sessions would typically include
a facilitator, end users, developers, observers,
mediators and experts.
It also refers to a development methodology which
aims to involve the client in the design and
development of an application.
 JAD: pros & Cons
Advantages
decreases time and costs associated with
requirements elicitation process.
 During 2-4 weeks information not only is collected, but
requirements, agreed upon by various system users, are
identified.
JAD sessions help bring experts together giving them
a chance to share their views, understand views of
others, and develop the sense of project ownership.
Well known and can easily be applied
Disadvantages
valuable time of professionals can be wasted easily.
The wrong problem can be addressed, the wrong
people can be invited to participate, inadequate
resources for problem-solving can be used…
 Prototyping
A prototype is an initial version of a system which is
available early in the development phase
Prototypes are valuable for requirements elicitation
because users can experiment with the system and
point out its strengths and weaknesses of the
implemented requirements
Rapid development of prototypes is essential so that
they are available early in the elicitation process
In prototypes
Some functionality may be left out
Non-functional requirements (e.g. performance) are less
stringent
No secondary functions (e.g. maintenance)
No complete documentation
 Prototyping: Types
Throw-away prototyping
 Intended to help elicit and develop the system
requirements.
The requirements which should be prototyped are those
which cause most difficulties to customers and which are the
hardest to understand.
Requirements which are well-understood need not be
implemented by the prototype.
Evolutionary prototyping (Increment)
Intended to deliver a workable system quickly to the
customer.
Therefore, the requirements which should be supported by
the initial versions of this prototype are those which are well-
understood and which can deliver useful end-user
functionality.
It is only after extensive use that poorly understood
requirements should be implemented.
 Prototyping: Approaches
Paper prototyping
a paper mock-up of the system is developed and used
for system experiments
 ‘Wizard of Oz’ (WOZ) prototyping
a person simulates the responses of the system in
response to some user inputs
Executable prototyping
a programming language or other rapid development
environment is used to develop an executable prototype
Executable Prototype Development
Visual programming languages such as Visual Basic
Internet-based prototyping solutions [ HTML browsers, Java)
Visualization Tools like Microsoft Visio
 Powerful CASE tools ( Eclipse, NetBeans )
 Prototyping: benefits
The prototype allows users to experiment and discover
what they really need to support their work
Establishes feasibility and usefulness before high
development costs are incurred
Can even reduce the development costs
Essential for developing the ‘look and feel’ of a user
interface
Probably the only technique to validate interface requirements
Can be used for system testing and for further
development of documentation
Back-to-Back testing: same tests are applied to both
prototype and final system
Forces a detailed study of the requirements which
reveals inconsistencies and omissions
 Prototyping: Disadvantages
Insufficient analysis- The focus on a limited prototype can
distract developers from properly analyzing the complete
project.
User confusion of prototype and finished system - Users can
begin to think that a prototype, intended to be thrown away, is
actually a final system that merely needs to be finished or
polished.
Expense of implementing prototyping - the start up costs for
building a development team focused on prototyping may be
high
Excessive development time of the prototype- A key property
to prototyping is the fact that it is supposed to be done
quickly.
Possibility of implementing systems before they are ready.
Producer might get too attached to it (might cause legal
involvement)
Not suitable for large applications
 Knowledge Elicitation
Techniques in RE
Background
Knowledge elicitation is concerned with discovering ‘expert’
knowledge
Originally focused on deriving expert’s “rules” for Rule-based
Systems
More recently, focused on understanding “problem solving
methods”
Task analysis
Task analysis provides the tasks in a hierarchical fashion with a top-
down manner.
In this approach main task and the sub-tasks are described by
different levels in the tree format and hence this detail continues
until the root tasks are encountered.
The primary objectives of this technique is to construct a hierarchy
of the tasks performed by the users and the system, and determine
the knowledge used or required to carry them out.
The task analysis is also useful for representing design analysis,
integration with business models and model of requirements
change.
 Task analysis…
Advantages
Task analysis provides the interaction of both
user and the system with respect to some
task that takes place.
Task analysis is used by the project manager
to manage the user and system tasks.
Disadvantages
 The task analysis requires a lot of effort as
compared to interview.
The detail of level is mandatory in task
analysis and hence it needs a lot of detail for
the low level tasks.
 Protocol analysis
Protocol analysis is a sort of meeting where participants
discuss the requirements of the customer while talking
loudly. (psychological research method )
Protocol Analysis also provides the required actions to be
taken for fulfilling the user requirements by using rationale.
Advantages
This technique can provide the analyst with specific
information and rationale for the processes the target system
must support.
 This technique enables all the stakeholders to provide active
participation.
Disadvantages
Sometime this technique does not provide the true picture of
the requirements as talking through operations.
Conflicts can occur among the participants while talking
loudly.
 Card Sorting
In card sorting technique the customer is provides with a
set of cards to sort it according to the names of domain
entities.
Also the costumer has to provide the criteria according to
which the cards are sorted.
Advantages
It provides the requirements prioritization by sorting and
placing the most important requirements at the top of the
cards.
It provides how much the customer has the knowledge about
the problem domain.
elicits classification knowledge
Disadvantages
It requires deep knowledge about the domain and also all the
entities should be included in the process otherwise this
technique gives wrong results.
Complex cards can confuse the novice stakeholder.
 Laddering
A series of simple questions are asked from the stakeholders
which are answered in a clear way by the stakeholders.
These questions are arranged into a hierarchical format
which is useful to show the order of the questions that has
been asked and priority.
The stakeholder domain information is vital for the success
of this technique.
Advantages
provides the close contact with the stakeholders by asking
them about their prioritized needs.
arranges the customer requirements in proper hierarchical
format that is easy to be understood.
Disadvantages
becomes more complex for a large numbers of requirements
The maintenance of this technique becomes very hard when
adding and deleting the requirements anywhere in the
laddering.
 Delphi Technique
Is an iterative technique in which information
is exchanged in a written form until a
consensus is reached.
For example participants may write down their
requirements, sorted in order of importance.
The sets of requirements obtained are
distributed to all participants, who reflect on
them to obtain a revised set of requirements.
 The procedure will be repeated several times
until sufficient consensus is reached.
Used where contact between experts is
difficult
 Delphi Technique: pros & cons
Advantage
Anonymous
Freedom from individual influence or
dominance
Can reach consensus in hostile groups
Insulates from lobbying
Disadvantages
Time consuming
Information only as good as participants
Needs good written communication skills
Best method for complex problems
 Repertory Grids
develop a grid in the form of a matrix used to
store the requirements involve asking
stakeholders to develop attributes and assign
values to a set of domain entities.

Used to detect terminological differences

Get the experts to agree a set of entities
Each expert provides attributes and values
For each attribute in expert A's grid, find the closest
match in expert B's grid. (i.e. are there attributes
which have the same discriminatory function?)
Experts then rate the entities using each other's
attributes
 Contextual approaches:
Participant Observation
People often find it hard to describe what they do because it is
so natural to them.
Actual work processes often differ from formal, prescribed
processes
Sometimes the best way to understand it is to observe them at work
This technique is often used with the conjunction of other
requirements engineering techniques like interview and task
analysis.
Advantages
highly authentic requirements engineering tool
mostly used in order to validate and verify the requirements.
Disadvantages
very much expensive to be performed because of the travelling
costs.
Mostly the results of observations are wrong as the customer
problems cannot be understand as they are being watched during
observations and adjust themselves.
 Ethnography
Ethnography means how the people understand the
problem.
From the software requirements engineering context, the
ethnography defines how people perceive their needs to
be fulfilled by the software.
An ethnographer spends some time observing people at
work and building up a picture of how work is done
Fundamental Theory:
The full understanding of a culture emerges only when an
observer becomes part of it, relates to the people involved and
knows the importance of the detailed practices to go on
Rationale for incorporating ethnography in the software
development process
Realization of developers: understanding the domain in which a
system is operating is of tremendous importance
Software is produced for human beings that have social
characters
 Ethnography Guidelines
Assume that people are good at doing their job
and look for nonstandard ways of working (resist
on individual experience)
Spend time getting to know the people and
establish a trust relationship
Keep detailed notes of all work practices.
Analyze them and draw conclusions from them
Combine observation with open-ended
interviewing
Organize regular de-briefing session where the
ethnographer talks with people outside the
process
Integrate other methods to elicit requirements
(prototyping)
 Ethnography Guidelines…

Two phases:
Analysis: Initial understanding of the system
and application domain
Focused Ethnography: discover answers from
questions which are raies during prototyping
 Ethnography: Pros & Cons
Advantages
useful to collects the quality attribute
requirements such as usability and efficiency etc…
which are necessary for the success of the project.
much effective when to determine the social
factors
Disadvantages
fails in many cases because there are so much
diverse communities of people belonging to
different social and ethical sects.
It is difficult to analyze the social requirements of
the people and hence the psychologists are
required to provide their
 Domain Analysis
Domain analysis provides domain knowledge, and
identification of reusable concepts and
components.
It is an earlier eliciting technique which
investigates the thorough domain area by the
domain expert.
These types of investigations are particularly
important when the project involves the
replacement or enhancement of an existing legacy
system.
Domain requirements are fundamental for software
reuse and are the product of domain analysis.
The domain analysis is so much important and it is
usually found inside the requirement analysis.
Domain Analysis…

The Domain Analysis of SADT diagr

 Domain Analysis: pros & cons
Advantages
is useful for eliciting requirements from documents,
instruction manuals of existing systems and other files
and forms used in the current business process.
used in the conjunction of other elicitation techniques
as an input.
provides the opportunity to reuse specifications and
validate new requirements against other domain
instances
Disadvantages
quite complex task because it needs to focus on
different type of domains and hence is very much
complex technique.
requires a lot of expertise and skills from diverse fields
of software engineering.
 Selection Criteria
There numerous elicitation techniques. The choice
depends on
System to be created
Greenfield Engineering
Reengineering
Interface Engineering
Highly interactive (Cooperation Support System)
Specific applications like Games
Budget/Time
Degree of User Participation
Time
Experience of users
 …. (many more)