Asking questions during business requirement definition process:

I think I might be missing something here. Can you clarify for me what problem are we
trying to solve?

Let people state their version of the problem. Many might bring up their solutions as
problems. And some might have trouble articulating what the problem really is. Look for
multiple ways to refocus the discussion without sounding irritating and redundant.

1.

If we did XYZ, what would happen?

2.

What benefit does XYZ have?

3.

What would change once XYZ is in place?

4.

How does XYZ change things?

5.

Why should I care about XYZ?

6.

Whats your goal? (or, the goal)

7.

How would XYZ impact you? (good technique to shift the conversation to a nonparticipant)

8.

What else do we need to think about if we do XYZ?

9.

Lets talk about what problem we might be trying to solve here. (yes, its often
necessary to re-iterate, just re-phrase if you can!)

10.

How would your day-to-day work change if we did this?

The purpose of Assess Capability Gaps is:

To identify new capabilities required by the enterprise to meet the business need.
This task involves analysing current capabilities, creating an assessment of new
capability requirements (aka business requirements) and documenting assumptions
about how these new requirements will help us achieve the business need.

Analysing current capabilities is critical, because very often, organizations have existing
capabilities that are not being leveraged and a business need can be met by small change.
If existing capabilities are inadequate, a project will be launched to create the capabilities.
Change can be created in any of the following areas:

Business processes

Features of a software application

Tasks performed by end users

Products that an organization creates

Services delivered

Etc.

It seems we are almost always eliciting something the business need, the solution
requirements, our stakeholders concerns, assumptions and constraints, detailed
requirements, etc.
Step 1 Clarify Elicitation Scope
Before we begin elicitation, we either consciously or intuitively decide what we want
to achieve through the activity. In the best of words, the scope of a phase or session
of elicitation is formally captured in a meeting agenda and communicated to all
involved stakeholders. You might even create a detailed elicitation plan that covers
who will be involved and what their role is. At a minimum, youll mentally prepare for a
conversation before popping your head into someones office.
Step 2 Gather Supporting Materials
Gathering supporting materials is equally significant. This could involve research into what
documentation or artifacts already exist. Or, it could involve completing another task to
create a deliverable, such as using requirements analysis to analyze the as is process as a
starting point for an elicitation discussion.
Another element of your supporting materials will be your requirements questionnaires. A
requirements questionnaire is essentially the list of questions you have about the
requirements related to the scope of the session.

Step 3 Schedule Resources

Finally, there is the need to actually schedule the meeting. In a complex stake holder
environment, this is often easier said than done. You might reschedule the meeting multiple
times to find a time that works for all the participants. At times when a suitable time cannot
be found, Ive restructured the meeting so I can meet with different parts of the group
separately and accommodate various schedules. Scheduling resources also involves nailing
down meeting logistics: the conference room, conference call numbers, securing the
projector, etc. Here are the 9 elicitation techniques defined by the BABOK for business
analysts:

Brainstorming

Document Analysis

Focus Groups

Interface Analysis

Interviews

Observation

Prototyping

Requirements Workshops

Survey/Questionnaire

Once you start digging into each technique, you realize that its actually quite difficult to do
as a stand-alone activity. For example, brainstorming often happens as part of a
requirements workshop which can have an interview component as well. Or, in order to
prepare for an interview, you need to do some document analysis first to come up with a list
of questions. Or, in order to get your interviewees to give you good information, they need to
see a prototype.

The elicitation techniques can be combined any which way to achieve the result you want
out of their project.

In business analysis, the set of techniques used to discover the requirements is called
elicitation. For the most part, elicitation is a fancy word for asking a lot of questions and
getting clarity on the answers. But it also includes techniques such as reviewing existing
documentation, creating draft models for feedback, and observing people in their work to
identify what they really need from a new solution. Requirements can be discovered at all
stages of your project lifecycle. The sooner your team knows about a requirement or
potential requirement, the sooner that stakeholder need can be incorporated into the
planning, solution building, or testing process.