Types of Elicitation Techniques for the Business Analyst

Why requirements elicitation?

One of the first problems a business analyst needs to solve when starting a new project is how to elicit to the requirements. This goes hand-in-hand with how you go about engaging your stakeholders.

This is because there are a number of variables that need to be taken into consideration when planning the work needed to gather all necessary information. Each project is different and will require a different way of approaching requirements elicitation.

The reason why elicitation is important is because the discovery of business requirements is almost never readily available at a business analyst’s fingertips.

Rarely can requirements be quickly looked up from a convenient source of information. Most business and technical requirements are not usually documented anywhere, and if they are, they are likely to be out of date or found in fragmented information sources that need to be analysed and validated with stakeholders. Therefore, the elicitation of requirements involves a high level of stakeholder engagement.

The importance of elicitation cannot be overstated, for it is the linchpin to any requirements project.

Mistakes made in elicitation can be a major cause of systems failure or abandonment, and this has a very large cost either in the complete loss or the expense of fixing mistakes. Adequate study and preparation for elicitation can go a long way to preventing these types of errors. The approach to elicitation must be logical and meticulous.

The purpose of requirements elicitation, therefore, is to thoroughly identify the business needs, risks, and assumptions associated with any given project.

The ability to identify and plan a requirements elicitation effort is a very important skillset that a business analyst contractor or consultant should have to be successful in their career.

In your experience, how has requirements elicitation benefited the outcomes of a project? If possible, think of a project you have been involved in, and write down 3 points of how a planned and executed elicitation strategy made a positive difference to that project.

Preparing for elicitation

Planning for elicitation requires the following:

1. A thorough understanding of the project requirements and business need. During the elicitation process, a business analyst’s strong understanding of the business need will help them guard against scope creep and overrun. It will help them select the appropriate stakeholders and elicitation techniques. A step-by-step guide to identifying project requirements and planning your business analysis activities is given in the this eBook. This resource also provides a business analysis approach template which can be downloaded here. It assumes that all activities will be performed by the business analyst from the very beginning of a project.
2. Ensuring that an adequate amount and mix of stakeholders are secured for the project’s duration. A good business analyst actively engages stakeholders in defining requirements. According to the BABOK, a project’s stakeholders may include customers/end users, suppliers, the project manager, quality analysis, regulators, project sponsors, operational support, domain subject matter experts, and implementation subject matter experts. You must recruit the participation of appropriate stakeholders based on the unique business needs of the project – ensuring that stakeholders representative of all areas of the impacted business are involved.
3. Understanding your stakeholders. After you have identified who you need to talk to, it is useful to perform some analysis to understand how their needs may impact the project, and the contributions that they will make to the requirements elicitation process. See the “Stakeholder analysis” section below.
4. Scheduling enough time with your stakeholders. After you have identified and recruited stakeholders and have chosen the elicitation methods it is important to schedule required time with stakeholders as far in advance as possible to ensure adequate participation.

Understanding your stakeholders

Often projects will have a large number of stakeholders from different areas of an organisation. Each stakeholder’s position and responsibilities, the level of their involvement and their importance to the project will vary.

Stakeholder analysis is more than just identifying project stakeholders. After the stakeholders have been identified it should be determined how involved each stakeholder should be in the requirements elicitation process. It is also important for the business analyst to have some understanding of any particular concerns or issues that a stakeholder may have.

The business analyst should document a number of factors for each stakeholder including, but not limited to:

• Overall stakeholder importance. How important is the stakeholder in the requirements elicitation process? Are they required in order to document all of the critical project requirements, or are they nice to have?
• Impact. How will the project impact the stakeholder? What difference will it make in their daily activities? What difference will it make for their targets?
• Influence. How influential is the stakeholder to the project? Even if they are not needed for the requirements elicitation, are they in a position of authority? Does the stakeholder have the ability to dramatically alter the course of the project?
• Level of engagement. What level of involvement and how much time will be expected of each stakeholder? Do they need to be fully allocated to the project? Do they need to be in every requirements elicitation session? Can they be involved in only key requirements elicitation sessions? Do they only need to attend a final requirements review session?
• Frequency of engagement. How often will each stakeholder need to be involved; daily, every other day, once per week?
• Importance. What is important to the stakeholder? What issues do they have that are of primary concern to them? Do they have any special requirements?
• Contribution. How could the stakeholder contribute to the project? What is their level of skill or knowledge in area? Are they a subject matter expert? How will this knowledge contribute?
• Controlling factors. How could the stakeholder block the project? Are there any sensitive issues that need to be known that may impact negatively on the project? Are there any hidden assumptions or cultural norms that may influence the outcome? (Note that the stakeholder analysis is a confidential document).
• Strategy for engagement. What method will be used to involve each stakeholder? Will they receive email-based status reports? Will they be involved in requirements gathering sessions? Will they be asked to sit in one-on-one requirements interviews? What types of questions should they answer that is relevant to their role and position in the organisation?

A stakeholder analysis template is provided here. It is provided as a guideline and can be adapted for your project.

Understanding stakeholder requirements will help ensure that:

• The project will meet its goals and objectives, and that critical requirements are not missed.
• The most influential stakeholders are updated on a regular basis with the project status.
• The necessary people are made available to the project for the right amount of time.
• The business analyst has everything they need to plan and schedule the necessary meetings accordingly.

This information will also aid in development of a communication plan and the appropriate selection of communication techniques.

Elicitation techniques and when to use them

There is a myriad of requirements elicitation methods, however the BABOK lists nine. They are:

1. Brainstorming
2. Document Analysis
3. Focus Groups
4. Interface Analysis
5. Interviews
6. Observation
7. Prototyping
8. Requirements Workshops
9. Survey/Questionnaire

Many business analysts feel they should be using all of the techniques and worry they are not getting elicitation right. However, this is an area that all business analysts never stop improving, even senior business analysts.

Each technique is 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. A common approach is a combination of an interview and a requirements workshop.

Elicitation techniques can be combined in any way that will achieve the best possible result. However, elicitation is not about using as many techniques as possible. It is about discovering the real needs behind the project. Keeping it simple is the best approach.

Deciding on which technique or combination of techniques to use is important to make best use of time. The organisation’s makeup, political climate, the nature of the project, and personal strengths and preferences will have a lot to do with which methods work best.

The more relevant they are to the business analysis process and stakeholder preferences, the easier the technique will be to execute.

Below is a description of the 9 main elicitation techniques, their pros and cons, and some pointers for further research on how to perform them.

Brainstorming

According to the BABOK, brainstorming aims to answer a specific question, such as how to resolve an issue, what factors are holding a group or organization from moving ahead, what may be causing a delay in a development, or what may be done to solve a problem. Brainstorming is most effective when it seeks to focus on one specific topic, rather than covering a broad spectrum. The brainstorming group is normally composed of organizational stakeholders who are generating ideas that will be refined later.

Pros

• Ability to elicit many requirements and ideas quickly.
• Brainstorming has the most potential to prevent potential future issues including unknown needs, processes not previously mentioned, and other things not previously thought of.
• Encourages stakeholders take ownership of the direction of a project.
• Enables the business analyst to take in a wide amount of information at once, helping them figure out next steps.
• Fun, engaging and productive.

Cons

• Depends on the participants being able to sufficiently think outside the box.
• Depends on the skill of the facilitator to keep ideas flowing and maintain neutrality.

How to facilitate a Brainstorming session:

• Schedule participants.
• Be sure everyone is on the same page regarding the process.
• Give participants a small amount of time to brainstorm on their own before bringing their ideas to the group.
• Once the session has started, keep everyone on topic.
• Do not limit creativity, free association, or the number of ideas.
• Build in some break times.
• Write all ideas down in plain view of the entire group.
• Once the session is over, begin the refining process.

Document Analysis

The document analysis technique is one of the most effective ways of kick-starting the requirements elicitation phase. This is where the business analyst reviews relevant business, system, and project documentation with the objective of understanding the business, the project background and identifying requirements or opportunities for improvement. It is a means of gathering information before scheduling interviews or other elicitation sessions with stakeholders.

Pros

• Useful where the stakeholder is unavailable or no longer with the organisation.
• Ensures that the business analyst does not start from a blank page.
• Acts as a means of cross-checking requirements with other sources.
• Compliments other elicitation activities like workshops, interviews, and prototyping by serving as a means of verifying requirements.

Cons

• Document Analysis is limited to the as-is situation.
• Documents usually need to be updated to reflect current circumstances.
• It can be time-consuming to find and sift through masses of information.

Some sources for document analysis are:

• Business cases.
• Project plans.
• Business requirements / process documentation.
• Functional specifications of existing system.
• Contracts / tender documentation.
• Organisational structure.
• Meeting minutes.
• Market research.
• Customer complaints / feedback.
• User manuals.

Focus Groups

A focus group is normally composed of stakeholders who are giving their feedback about the already-refined ideas (i.e. as outcomes of other elicitation activities such as brainstorming). It is used to gather the attitudes (in forms of comments and feedback) about an idea, a solution, or a process. For instance, it can be used after the development of a prototype, to get an idea of how the market will respond to certain features of the solution.

Pros

• Can save time and cost by eliciting many requirements in one session.
• A healthy interchange among members is effective to elicit attitudes and perspectives.

Cons

• While focus groups allow you to dig into the thought processes of a select group of users, there is the danger that a small group may not be reflective of the entire audience of users.
• Participants must feel comfortable speaking honestly about their needs without fear of offending the moderator or stakeholders, or the benefit of the focus group is moot.

How to facilitate a Focus Group:

• Employ the principles of brainstorming.
• Ensure the objectives of the group are clear.
• Select participants carefully.
• Establish the ground rules.
• Document the facts.
• Include an observer.
• Conduct a survey at the end to get additional information.

Interface Analysis

The business analyst observes how a system interacts with users and other systems. This method is used frequently with projects involving IT components. It can be conducted with both internal and external systems and users. Requirements are traced to specific functions carried out by the system or hardware involved in the process. The business analyst can uncover potential requirements, limitations, functionality, and interoperability between systems or hardware.

Pros

• Provides valuable detail about which system requirements are necessary.
• Saves time and expense by enabling the business analyst to accurately determine testing and integration requirements.

Cons

• Limited in providing stakeholder perspective and non-system requirements.
• Does not provide a complete understanding of business process requirements.

Further research

A quick way to gain insight into interface requirements is by reviewing the existing system and building a context diagram which displays at a glance, the entities that send data to and receive data from it at a high level. The context diagram can then be broken down into data flow diagrams for more detailed analysis.

Interviews

One-on-one interviews provide an efficient way to collect large amounts of data quickly. The business analyst can choose to conduct a one-on-one or group interview to elicit requirements through a series of questions directly asked to stakeholders, end users, or subject matter experts. The interview can be structured or unstructured, conducted in a formal or informal setting. Questions are either open-ended (eliciting a thoughtful, expressive response) or closed-ended (requiring a direct, coded response). Interviews should be unstructured enough to be sure that the interviewees knowledge is sufficiently mined and structured enough to be sure that all basic questions are covered without going too off topic.

Pros

• By exploring someone’s knowledge and needs in-depth the business analyst ensures that they understand the real, not just the perceived, need.
• Provides a simple, direct way of eliciting requirements directly from stakeholders.
• Maintains focus throughout the elicitation process.
• Allows for complete explanation and discussion of attributes and needs.

Cons

• The results of interviews, such as the usefulness of the information gathered, can vary significantly depending on the skill of the interviewer.
• Does not allow the business analyst to reach consensus among stakeholders easily.
• Requires substantial time commitment and stakeholder involvement.
• The interviewer must be highly skilled to generate appropriate information.

Further research

The key to accurate requirements elicitation using this method is to determine the most appropriate interview subject and designing the most useful questions. Follow up questioning should be used to clarify vague, incomplete, or hard to understand responses. The questions must be presented in a logical order to enable the business analyst to understand the complexity and dependencies of the requirements. For the interview to be effective, the business analyst must be persistent and use the five Ws—Who, What, When, Where and Why.

Observation

This is an effective method of understanding a stakeholder’s needs through observation of their work environment and process flow. Sometimes called job shadowing, the business analyst follows a subject matter expert or end user through the business process to be improved or re-engineered. This method establishes a baseline from which modifications can be made.

Pros

• Observation is primarily useful for capturing what’s already in existence and enables several other types of requirements tools, not the least of which is existing use-case scenarios.
• Provides actual and practical insight to current workflows.
• Elicits information that is not captured through documentation or questioning.

Cons

• Provides requirements only on existing systems, structure, or process.
• May be disruptive to business unit.
• Limited observation period may miss unusual occurrences.
• Responses to issues can be time consuming to observe entire process.

Further research

The observation can either be done passively or actively. Passive observation requires the business analyst to watch the business process without involvement or discussion. Active observation involves discussion with end users and/or performing functions within the flow (hands on approach). The business analyst can document what they observe through numerous types of diagramming and business process models besides use cases.

Prototyping

On software development projects, users and business owners can visualise a model of the new software before it is developed to refine requirements.

Pros

• Allows user interaction with model and early feedback.
• Encourages stakeholders to play an active role in developing the requirements.
• A low fidelity, throw away model can be a quick, inexpensive way to uncover requirements.
• A high fidelity provides smooth transition to an implemented system.

Cons

• Can be expensive and time consuming if the product or system is complex.
• Need to manage stakeholder expectations.
• Initial model can lead to unrealistic expectations for final design.

How to perform Prototyping:

• Elicit requirements.
• Produce prototypes:
  • Low fidelity (wireframes, mock-ups), or
  • High fidelity (as part of ongoing development)
• Validate main flow using prototypes with the client.
• Define final user stories.

Requirements Workshops

For complex projects involving multiple stakeholders, a workshop is one of the quickest and most cost-effective ways of eliciting requirements. The business analyst works with a group of stakeholders to scope, define, analyse, and prioritise requirements. It is a highly productive focused event attended by carefully selected stakeholders and subject matter experts for a short, intensive period.

Pros

• Basic requirements are done in a hurry.
• Stakeholders are more likely to become invested in the project.
• Get everyone on the same page regarding the purpose of the project.
• Stakeholders can collaborate and reach a mutual understanding.
• Resolve conflicting requirements between stakeholders.
• Can conduct the workshop like an interview.

Cons

• Scheduling can be a challenge.
• Success is highly dependent upon a skilled facilitator and appropriate participants.
• It is not the easiest of techniques because of the diversity of stakeholders involved and their often-conflicting interests.
• The number of participants can have a negative effect on outcome (too many can slow the schedule; too few can produce low quality requirements).
• Need to manage dominant stakeholders and ensure everybody has a chance to provide input.

How to run Workshops:

• Do your homework (research background information, desktop analysis, interface analysis).
• Plan activities to be completes before the day of the workshop.
• Be clear on workshop outcomes.
• Produce an agenda.
• Ensure best timing for optimal participation.
• Get the right stakeholder mix.
• Get the right venue to accommodate attendance and supporting materials (whiteboards, etc).
• Ensure stakeholders are prepared.
• Get there early and set up.
• Stick to the plan and maintain focus.

Survey/Questionnaire

If requirements are to be elicited from many stakeholders, the business analyst may choose to use a survey which provides a questionnaire to be completed. Surveys can be sent simultaneously to stakeholders, end users, and subject matter experts. The questions used, as with the interview method, can be open-ended or closed, depending upon the level of detail sought.

Pros

• Effective for many stakeholders and in different locations.
• Can be effective at obtaining quantitative as well as qualitative results.
• Can very quickly yield large sets of results.
• Short surveys can be completed quickly.
• It is usually less expensive and easier to administer than other methods.

Cons

• Can be difficult to ask follow-up questions or let a user interact with a prototype.
• Provides limited opportunity for the participants to request clarification or correct misunderstandings.
• Open-end questions can require time to analyse.
• Statistical sampling methods may be required to achieve unbiased results.
• May require follow up interview or re-survey if information is incomplete or missing.
• Not suited to uncover actual work process attributes or unwritten behaviours.

When writing the questions, the BA should keep in mind the following caveats:

• Communicate the survey’s purpose and objectives to provide scope to respondents.
• Focus on the requirements being elicited.
• Keep survey short (IIBA prefers 10 items or less).
• Make sure wording and syntax can be clearly understood.
• Avoid negative questions.
• Avoid complex concepts or question structure.
• Attempt to elicit as much detail as necessary.
• Avoid questions that may put respondents on the defensive.

Commonly used elicitation techniques

In my experience, I have used mainly these techniques to elicit requirements: document analysis, requirements workshops, interviews, brainstorming, and interface analysis. Over time, and with practice, I have been able to refine my skill in these techniques. The most challenging part has been the communication and interaction aspects of working with people to elicit requirements.

In your experience, what elicitation techniques have you used mostly, and how do you think you can improve on them next time?

Think of a project where you successfully carried out a combination of techniques. Why did it work for you? What qualities did you bring to this work that made it a success? What other favourable conditions made it a success?