Requirement Elicitation

Advanced Business Analysis Training
Requirement Elicitation

Classification: Restricted
Agenda
• What is Elicitation?
• The elicitation methodology
• The stakeholder connection
• Stakeholder Analysis
• Brainstorming
• One-to-One Interview
• Group Interview
• Document Analysis
• Focus Group
• Interface Analysis
• Observation/Social Analysis
• Prototyping
• Use case and scenarios
• Requirements reuse
• Pre-Project Activity
• Request for Proposal

Some basic points
•Elicitation is not acquisition
•Requirements are not available like sensor data Not
just read them systematically!!
•Elicitation is not specification and modeling

What is Elicitation?
•Process of identifying needs
•Front End to systems development
•Involves social, communicative issues and Technical
issues
•It helps to express the requirements systematically

A common problem
What is your need ?
I need a system that
works OK
Robust and respond
to my wishes

As a problem in social life
AVOID MISUNDERSTANDING !!

Elicitation: a subset of goals
•Identify the relevant parties . The stakeholders
•Gather the Wish List for each stakeholder
•Document and refine the Wish list
•Expected properties
•Unambiguous
•Complete
•Verifiable
•Consistent
•Modifiable
•Traceable

Common generic problems
•Scope : too much or too little
•Understandings : Users and developers
•Users have an incomplete understanding of their
needs
•Analysts and SE have a poor knowledge of problem
domain

The scope problem
•Establish a boundary conditions for the target system

• 56 % of errors were due to poor
communication between user and analyst
•Such errors cost 82% of the available staff time
•Three main issues
•people involved comes from different
backgrounds
•Language used may be too informal or too
formal
•A large amount of information to be
communicated are not really structured

The elicitation methodology
Fact findings
Req Gathering
Evaluation
Prioritisation
Integration
and Validation

The stakeholder connection
•Involves technical staff working with customers to
find out about the application domain, the services
that the system should provide and the system’s
operational constraints
•May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders

Specific Elicitation Techniques
Stakeholder Analysis
Brainstorming
One On One Interview
Group Interview
Document Analysis
Focus Group
Interface Analysis
Observation SocialAnalysis
Prototyping
Brainstorming
One On One Interview
Group Interview
Document Analysis
Focus Group
Interface Analysis
Observation SocialAnalysis
Prototyping
Facilitated sessions
Joint Application Development (JAD)
Questionnaire
Survey
Use cases and scenarios (UCD)
Reused Requirements
Request for Proposal (RFP)
Reverse Engineering

impacted by the
system.
Stakeholder analysis identifies
all users and stakeholders who
may influence or be
impacted by the system. This
helps ensure that the needs
of all those involved are taken
into account
Benefits
1. Ensures that all relevant
stakeholders are considered
2. All important stakeholders
are captured, and yet that
irrelevant actors are not
included
Drawbacks
There is a danger that too much
time is spent on
identifying roles and
relationships, and the team is
swamped with data.

Brainstorming
Basic Rules
1. Start out by clearly
stating the objective
of the
brainstorming
session.
2. Generate as may ideas
as
possible.
3. Let your
imagination soar.
4. Do not allow criticism
or debate while you
are gathering
information.
5. Once information is
gathered, reshape
and combine ideas.
It is utilized in requirements elicitation to
gather good number of ideas from a
group of people. Usually brainstorming is
used in identifying all possible solutions
to problems and simplifies the detail of
opportunities. It casts a broad net,
determining various discreet possibilities.

Brainstorming

One-to-One Interview
The most common
technique for gathering
requirements is to sit
down with the clients and
ask them what they
need. The discussion
should be planned out
ahead of time based on
the type of requirements
you’re looking for
• Privacy of everyone
• in-depth astakeholder’s
thoughts and get his or
her perspective
Benefits
Risks &Drawbacks
• Time Consuming
• Misunderstandings

Group Interview
If there are more then
one person during
interview usually 2 or 4
these people must be on
some level must be on
some level less time
required
• we can get hidden requirements
• uncover a richer set of
requirements in a shorter period
of time
• Uncover ambiguities
Benefits
Risks &Drawbacks
• Not relaxed environment
• Conflicts
• The allotted time have been
exhausted

Document Analysis
Document Analysis is an
important gathering
technique. Evaluating the
documentation of a
present system can assist
when making AS-IS
process documents and
also when driving the gap
analysis for scoping of the
migration projects.
• validating the requirement
completeness.
• Chunks of information are mostly
buried in presentdocuments
• Abeginning point fordocumenting
all current requirements.
Benefits
Risks &Drawbacks
• Time Consuming
• Conflicts
• Exhausted
• Not Found RealFigures

Focus Group
A focus group is actually gathering of
people who are customers or users
representatives for a product to gain
its feedback. The feedback can be
collected about opportunities,
needs, and problems to determine
requirements or it can be collected
to refine and validate the already
elicited requirements.
• Managed process withparticular
participants
• refine and validate the already
elicited requirements
• Allows analyst to rapidly obtain a
wide variety of user views and
possibly aconsensus.
Benefits
• following the crowd and some
people think that focus groups
are at best unproductive
• end up with is with least common
denominator features.
• Recruitment effortto
• Assemble groups. Dominant
participants may influence group
disproportionately
Risks &Drawbacks

Interface Analysis
Interface for any software product will either be human or
machine. Integration with external devices and systems is
another interface. The user centric design approaches are quite
effective to ensure that you make usable software. Interface
analysis- analyzing the touch points with another external
system- is vital to ensure that you do not overlook requirements
that are not instantly visible to the users.

Observation/Social Analysis
Social analysis is also known as
Observation. Observation is the
method of collecting requirements
by observing the people doing their
normal work.
This method is generally used to find
the additional requirements needed
by the user, when the user is
unable to explain their expected
requirements from the new product
and problems with the existing
product
• The ability to record and
report all findings that are
true
• it is morepractical
• no long calculation has to be
done
Benefits
• The viewer's or researcher's
own perception
• few trials/studies/or objects
observed to make an end
conclusion
• results may containhuman
error
Risks &Drawbacks

Prototyping
Prototyping is a relatively modern technique
for gathering requirements. In this approach,
you gather preliminary requirements that you
use to build an initial version of the solution —
a prototype. You show this to the client, who
then gives you additional requirements. You
change the application and cycle around with
the client again. This repetitive process
continues until the product meets the critical
mass of business needs or for an agreed
number of iterations.
• prototypes can beideal
reduce design risk
• it is more practical
• Screen mock-ups
• Using animation tools
• provides an understanding
of functionality
Benefits
• takes time tobuild
• morecostly to build
• false sense ofsecurity
Risks &Drawbacks

Facilitated Sessions
In a facilitated session, you bring a larger
group (five or more) together for a
common purpose. In this case, you are
trying to gather a set of common
requirements from the group in a faster
manner than if you were to interview
each of them separately.
• Less Time
• Reach Group Of People
• Brainstorming sessions
(virtual or face-to-face)
Benefits
• More Expensive
• need for extra facilities
to allow for group work
etc
• Handouts, readings
Risks &Drawbacks

Joint Application Development
JAD or joint application design, these
workshops can be efficient for
gathering requirements. The
requirements workshops are more
organized and structured than a
brainstorming session where the
involved parties get together to
document requirements. Creation
of domain model artifacts like
activity programs or static diagrams
is one of the ways to capture the
collaboration. A workshop with two
analysts is more effective than one
in which on works as a facilitator
and the other scribes the work
together.
• group typically stays in the
session until the session
objectives are completed
• participants stay insession
until a complete set of
requirements
• documented andagreed to
Benefits
• takes time tobuild
• morecostly to build
• false sense ofsecurity
Risks &Drawbacks

Questionnaire
Questionnaires are much more
informal, and they are good tools
to gather requirements from
stakeholders in remote locations or
those who will have only minor input
into the overall requirements.
Questionnaires can also be used
when you have to gather input from
dozens, hundreds, or thousands of
people.
• Less cost
• Reach Large No ofPeoples
• The responses are gathered
in a standardized way
Benefits
Risks &Drawbacks
• Difficult filling for users
• participants may forget
important issues
• Stockholders may not be
willing to answer the
questions

Survey
When gathering information from many
people: to many to interview with time
constraints and less budget: a
questionnaire survey can be used. The
survey insists the users to choose from
the given options agree / disagree or
rate something. Do not think that you
can make a survey on your own but try to
add meaningful insight in it. A well
designed survey must give qualitative
guidance for characterizing the market.
It should not be utilized for prioritizing
of requirements or features.
• Less cost
• Reach Large Noof
Peoples
• Adetailed critical
inspection
Benefits
Risks &Drawbacks
• Difficult filling for users
• participants may forget
important issues
• Stockholders may not be
willing to answer the
questions

Difference between questionnaire and survey?
The Oxford dictionary defines them as quoted below:
Survey:
A general view, examination, or description 2. An investigation of the
opinions or experience of a group of people, based on a series of
questions. 3. An act of surveying. 4. A map or report obtained by
surveying.
Questionnaire:
Noun a set of printed questions, usually with a choice of answers, devised
for a survey or a statistical study.

Use case and scenarios
Use cases are basically stories that
describe how discrete processes
work. The stories include people
(actors) and describe how the
solution works from a user
perspective. Use cases may be
easier for the users to articulate,
although the use cases may need
to be distilled later into the more
specific detailed requirements.
• provide the best return on
invested effort
• explain how that system will
be implemented
• Each use case provides a set
of scenarios thatconvey how
thesystem should interact
Benefits
Risks &Drawbacks
• Poor identification of
structure and flow
• Time-consuming togenerate
• Scenario management is
difficult

Requirements reuse
In the field of software
engineering reusing the
requirements of the existing
system is common method of
requirements elicitation. Using
the existing knowledge to
develop the new product has
many advantages that include
low cost and less time.
Though each product has their
own type of stake holders and
users, there is still number of
situations that the reusing of
the requirements take places
• Reused requirements
are already validated
and analyzed thus
reducing the time of
testing
Benefits
• Some time proposed
product iscompletely
different form the
existing product
Risks &Drawbacks

Pre-Project Activity
• Client realizes his need for a
software application.
• He will do an initial analysis on the
required features of the Software
Application and will prepare
Requirements Document.
Request for Proposal (RFP)
RFP is a document in
which Business need
appear.
Request for Information
(RFI) is a form that is
attached to RFP
Request for Quotation (RFQ)
A request for quotation
(RFQ) is a standard
business process whose
purpose is to invite
suppliers into a bidding
process to bid on specific
products or services
Statement of Work (SOW)
A document that defines
project-specific activities,
deliverables, and
timelines for a vendor
providing services to the
client.

Request for Proposal
If you are a vendor, you may receive
requirements through an RFP. This list
of requirements is there for you to
compare against your own capabilities
to determine how close a match you
are to the client’s needs.
The RFP presents preliminary
requirements for the commodity or
service, and may dictate to varying
degrees the exact structure and
format of the supplier's response.
Effective RFPs typically reflect the
strategy and short/long-term
business objectives, providing
detailed insight upon which suppliers
will be able to offer a matching
perspective

Reverse Engineering
Is this a last resort or starting point? When a migration project
is not having enough documentation of the current system,
reverse engineering will determine what system does? It will
not determine what the thing went wrong with the system and
what a system must do?
A critical activity for any ERP implementation is gathering
business requirements
Often we spend too much time and effort focusing on
gathering requirements that do not support key business
results and then gloss over the key business activities
because of implementation time constraints. Prioritizing
business results is an activity that we need to initiate
before gather requirements, not during fit/gap when
expectations are harder to manage and negotiate.

Effectiveness of method used for requirement
elicitation

Selecting Appropriate Techniques
Interview JAD Question
-naires
Documen
t Analysis
Observati
on
Type of
information
As-is,
improves,
to-be
As-is,
improves,
to-be
As-is,
improves
As-is As-is
Depth of info High High Medium Low Low
Breadth of info Low Medium High High Low
Info integration Low High Low Low Low
User
involvement
Medium High Low Low Low
Cost Medium Low-
medium
Low Low Low-
medium
As-is : understanding current system
Improves: identifies improvements
To-be: developing the newsystem

Summarize
• The meaning of requirement elicitation
• The people involved in elicitation
• Requirement elicitation methodology
• The requirement elicitation techniques

Thank You!

Requirement Elicitation

More Related Content

What's hot

Similar to Requirement Elicitation

More from Ravikanth-BA

Recently uploaded

Requirement Elicitation