Sei sulla pagina 1di 2


According to the IIBA:
"A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and
validate requirements for changes to business processes, policies and information systems. The business
analyst understands business problems and opportunities in the context of the requirements and
recommends solutions that enable the organization to achieve its goals."3
In essence, the business analyst helps the team move from ambiguity about the goals and scope to
clarity. Regardless of the processes used, moving from ambiguity to clarity is an iterative process.
Sometimes its like peeling an onion, layer by layer, but other times the route can be more complex and
the road less focused.

Elicitation is the process of working with stakeholders to understand what they want to achieve through
the project or change effort. A project stakeholder is someone who owns or provides input on a specific
aspect of a project. Elicitation involves bringing out the best thoughts and ideas about the change from
all the stakeholders.

The Business Analysis Body of Knowledge (BABOK) lists the following techniques for eliciting
Document Analysis
Focus group
Interface analysis
Requirements work-shops
By far the most common technique used is a variation of the interview, whether one-on-one or in a
group interview session. Because interviews are a common technique to address many different
business problems you have probably done an interview somewhere in your previous work.
Interviews involve thoughtful questioning and active listening. As a BA, you want to internalize as much
of what the others have to say as possible. During elicitation it is less important that you fully analyze
what you hear than that you actually comprehend it, have the tools in place to remember the salient
points (most likely by taking notes) and can follow-up with the analysis at a later time.
During elicitation you will typically work with a variety of stakeholders from all levels of the organization.
Stakeholders can include:

Business Owners of the system or project from a business perspective, often at the executive level.
Users of the new system or process, often called subject matter experts.
Product managers or other user proxies who represent the end user or customer of the system.
Technical or Enterprise Architects and other technical stakeholders who are responsible for overseeing
the overall IT strategy.

Key skills for elicitation include:

Organizing meetings: Inviting the right people, setting a meeting goal, crafting an agenda, and
documenting and distributing meeting notes.
Facilitating discussions: Ability to facilitate a meeting by initiating discussions and keeping the dialog
moving and focused on the topic at hand. The best meeting facilitators keep track of the discussion,
elicit input from everyone, redirect conversation around overly forceful personalities or off-topic
comments, and drive follow up on open points in the discussion.
Planning. As you peel the onion you will be progressing toward a defined system. Part of elicitation
involves having a plan to get from nothing to something.
Conducting walk-throughs and demos: Elicitation involves obtaining feedback on concepts, rules, and
deliverables. This activity might involve a document walk-through or a demo of a wireframe or
Asking good questions. Ability to get to the heart of the matter and ask a question that drives deeper
understanding of the problem or solution space.
Relationship Building. Elicitation requires trust and foundational to trust is building relationships with
your stakeholders. They need to trust that you are on their side and will do what you can to help them
see their ideas through to fruition.

Although elicitation will be one of the first BA activities on a project, it does not end with the initial
requirements elicitation activities. You will come back to elicitation throughout the requirements
lifecycle as you help the team achieve a clearer picture of what the change entails.