What is Requirements Elicitation?

“Requirements elicitation in not just gathering the shattered information from

numerous stake holders. Requirements Elicitation is the process of discovering the
requirements for a system by communication with customers, system users and
others who have a stake in the system development”.

Many of the times, stake holders are not clear about the top to elementary level of
requirements. It is the key role where business analyst comes into picture to get all
the stake holders together realize and agree upon the set of requirements
unanimously. More the stake holders to be impacted, complex may be the project.

To start requirements elicitation, business analyst will require certain things to be

identified and the output of elicitation will act as input for various activities to be
carried out. The input to and out of elicitation are discussed later in this document.

When we talk about requirements elicitation, there is no defined way or method or

technique which is the only way that business analysts do follow. There are various
techniques which will be used, based on the nature of project and the requirements
to be captures. There can be more than one technique used to elicit the
requirements in a single project.

Following are requirements elicitation techniques to be taken later in detail.

• Interviewing and questionnaires

• Requirements workshops

• Braining Storming and idea reduction

• Storyboards

• Use Cases

• Role Playing

• Prototyping

When should Requirements Elicitation begin?

Requirements Elicitation is an intermediate phase. It can be driven effectively only if

the essential information if available from the requirements planning and
management phase.

There is lot work needs to be done well before the requirements elicitation. The
information coming out of requirements planning and management will set the
good base to kick-off the requirements elicitation process.
 • The Enterprise Analysis activities define the overall scope of the problem
and solution domain and the goals. The business analyst uses the scope
definition and goals to provide the boundaries for all requirements elicitation.

• The Requirements planning and Management activities identify and

describe:

• The stakeholders

• The requirements documentation and the deliverables that will

be created,

• The appropriate technique(s) to elicit requirements that will be

employed

• The requirements traceability strategy that will be followed

• The requirements’ attributes that will be captured, and

• The outputs of requirements elicitation.

It’s very much needed for the business analyst to thoroughly understand the
artifacts available on the above mentioned points, before starting the elicitation.

Skills

The business analyst must be skilled in:

• Eliciting and assessing information

• Interviewing

• Facilitating collaborative sessions

• Observation

• Resolving conflicts; eliminating root cause of conflicts; reaching

consensus

• Thinking abstractly; finding and leveraging patterns

• Writing, business documentation

• Listening and oral communication.

Elicitation Techniques:
Some people tend to see each rejection of requirements validation from customer
as a failure to get the right information from customer. When the captured
requirements are not approved by customer, it gives a chance to get into more
business detail. There is also a possibility that the analyst may not have used a
right elicitation technique, because of which the correct understanding of the
requirements were not brought to the light. In other way this process of rejection
helps the client focus on what is important to their organization and helps analyst
know the core expectations.

Here we will discuss various elicitations techniques & try to understand the key
utility of each, if not into great details. Each one of these techniques is deep enough
to have white paper on them, but will try to get crux of each in this paper

Requirements • Gathers all key stake holders together for an

Workshops – intensive focused period
“Gather wide and key • Provides a framework for applying other elicitation
audience” technique
• Triggers the overall elicitation process
• Promotes participation by everyone
• Clearly state the objective/needs of the stakeholder
Brainstorming –
• Generate as many ideas as possible
“Criticism & debate • Let imagination soar
shouldn’t be allowed” • Condense ideas
• Prioritize & refine the ideas
• Provide stakeholders perspective
• Promote discussion
o Why it the system needed?
Use Case workshop – o Condense ideas
o Who/what will interact with the system
“Focuses to identify
key functionalities”
(actors)?
o What do users want to achieve by using the
system
o What interfaces should the system have?
• Produce the initial model of the system quickly
Storyboard – • Visually tell and show:
o Who the players are
“Helps to overcome
o What happens to them
BLANK PAGE
syndrome” o When it happens
• Help gather and refine customer requirements in a
user friendly way
• Encourage team view
 • Prevent features that no one wants
• Gain understanding of problem and solutions
• Consider Users, Customers, Other Stake holders.
Interview –
• Avoid asking people to describe things they don’t
“Simple & direct usually describe
technique” Eg :- Do you any crush? What is your girl friend’s
name?
• Ask open-end questions
• Analyst should turn as a good listener ..Listen, listen,
listen !
• Useful data gathering technique from wide audience
Questionnaires – • It appears scientific because of statistical analysis
• Information coming out of questionnaires should be
“Reach out to wide complemented with the interviews
audience”
• Its used when facts are required on the board
• Relatively inexpensive to administer

Role Playing –
• Analyst learns and performs the user’s job
“Reach out to wide • Performs a scripted walkthrough
audience”
• Gain real insight into the problem domain
• Understand problem that users may face

Prototype – • Demonstrate understanding on the problem domain

“Gain feedback on • Validate known requirements
proposed solution” • Discover unknown requirements
• Its used when facts are required on the board
• Get feedback on proposed solution

Conclusion
There may be more than the above
mentioned elicitation techniques
available to capture the requirements.

As an analyst, if choosing the available

option don’t get you to an ideal
solution. One may have to go out of
options for actual analysis to be done.

Clearly understanding the

requirements and customer being
happy validating the quality of
requirements are the ultimate result of
requirements elicitation process, no
matter which technique is used.