Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

I have seen many Business Analysts perform elicitation and efficiently capture stakeholder’s needs. However, I have not seen many trying to understand the underlying business needs. Most of the Business Analysts don’t try to understand “why” stakeholders have those needs.

Organization’s Business Environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.


Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time. As elicitation progresses and Business Analyst improves her/ his understanding of the business and stakeholder’s needs, Business Analyst should identify additional stakeholders and elicit additional requirements.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current (or “As-is”) state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, while developing models such as process models or use case models, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.


So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to uncover requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.


It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to progressively ask probing questions to uncover detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.


“Expectation is the root of all heartache”Shakespeare

In such situation, your understanding of the underlying business needs would be helpful. You can validate which business requirements are getting fulfilled by these stakeholder requirements and if the organization as a whole (and multiple stakeholders) are likely to be benefited from it. If you are able to establish a clear lineage than it is a genuine stakeholder requirement otherwise they are just their wants (whims and wishes!).

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interview is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge, ability to ask probing questions and active listening.

Information elicited using interviews may not demonstrate how stakeholders are actually performing their work. Many time stakeholders explain how things should happen as per written procedures and such information do not capture informal communication and collaboration between stakeholders or how exceptions are handled. To understand this, elicitation technique such as an Observation would be useful.

Most of age-old organizations have legacy solutions and key stakeholders involved in its implementation may have left the organization and so not available for interviews. At such times, elicitation technique such as Document Analysis can be useful.

With only interviews, it is difficult to reach consensus or have common understanding of requirements among stakeholders. To achieve this, elicitation technique such as Prototyping (if used effectively) can be useful.


So, a Business analyst should have knowledge of commonly used elicitation techniques and should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated, knowingly or unknowingly, based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false. Similarly, constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.


Assumptions and constraints are identified through elicitation from stakeholders. Along with requirements, assumptions and constraints need to be elicited, clarified, documented and traced back to. If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many novice Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work in their first meeting itself.

However, most of times, stakeholders are not aware why they are being contacted. So, when a Business Analyst meets a stakeholder for the first time, s/he needs to introduce themselves and explain why stakeholder’s assistance is needed and address any initial concerns. After their first meeting, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to come more prepared and give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. Documenting the elicited information for review allows stakeholder to check the information and identify items that are incorrect, incomplete or missing. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a shared common understanding of requirements.

Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems. Instead of creating textual requirements documents, Business Analyst can also help to achieve shared common understanding of requirements by creating an appropriate prototype based on elicited requirements, context and envisaged solution to validate stakeholder’s needs.


Want to acquire skill to elicit requirements?

Attend Fundamentals Requirements Elicitation Course