Author Topic: Elicitation Techniques in Business Analysis  (Read 8590 times)


  • Global Moderator
  • Newbie
  • *****
  • Posts: 12
Re: Elicitation Techniques in Business Analysis
« Reply #15 on: February 07, 2018, 05:16:20 pm »
Requirements elicitation techniques

Numerous elicitation techniques can be used for software projects. A project team should not expect to use only one elicitation technique. There are always many types of information to be discovered, and different stakeholders will prefer different approaches.

They are two types of elicitation techniques, they are facilitated activities and independent elicitation techniques.

Facilitated activities :In which BA interacts with stakeholders to elicit requirements. The Facilitated activities primarily focus on discovering business and user requirements.

Independent activities: In which BA works on his own to discover information. The independent elicitation techniques supplement the requirements that users present and reveal needed functionality that end users might not be aware of. Most projects will use a combination of both facilitated and independent elicitation activities.

The most obvious way to find out what the users of a software system need is to ask them. A BA will facilitate either a individual or small-group interviews to elicit requirements.
Interviews are appropriate for eliciting business requirements from executives who do not have a lot of time to meet.
Establish rapport  To begin an interview, A BA will introduce him self if the attendees don’t already know him, review the agenda, remind attendees of the session objectives, and address any preliminary questions or concerns attendees have.
Stay in scope  :keep the discussion focused on its objective. Even when talking with just one person or a small group, there’s a chance the interview will go off topic.
Prepare questions and straw man models ahead of time ,such as a list of questions to guide the conversation.
Suggest ideas  Rather than simply transcribing what customers say, a creative BA proposes ideas and alternatives during elicitation
Listen actively 

Workshops encourage stakeholder collaboration in defining requirements
A requirements workshop is “a structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, refine, and reach closure on deliverables  that represent user requirements.”

Workshops are facilitated sessions with multiple stakeholders and formal roles, such as a facilitator and a scribe. Workshops often include several types of stakeholders, from users to developers to testers. They are used to elicit requirements from multiple stakeholders concurrently. Working in a group is more effective for resolving disagreements.

workshops are helpful when quick elicitation turnaround is needed because of schedule constraints.

The facilitator plays a critical role in planning the workshop, selecting  participants, and guiding them to a successful outcome.

A scribe assists the facilitator by capturing the points that come up during the discussion

Establish and enforce ground rules  The workshop participants should agree on some basic operating principles
Fill all of the team roles  A facilitator must make sure that the following tasks are covered by people in the workshop: note taking, time keeping, scope management, ground rule management, and making sure everyone is heard.

Plan an agenda Create the plan and workshop agenda ahead of time, and communicate them to participants so they know the objectives and what to expect and can prepare accordingly.

Stay in scope  Refer to the business requirements to confirm whether proposed user requirements lie within the current project scope

Timebox discussions  Consider allocating a fixed period of time to each discussion topic

Keep the team small but include the right stakeholders

Keep everyone engaged

Focus groups
A focus group is a representative group of users who convene in a facilitated elicitation activity to generate input and ideas on a product’s functional and quality requirements. Focus group sessions must be interactive, allowing all users a chance to voice their thoughts. Focus groups are useful for exploring users’ attitudes, impressions, preferences, and needs


When you ask users to describe how they do their jobs, they will likely have a hard time being precise. Often this is because tasks are complex and it’s hard to remember every minute detail. Or it is because users are so familiar with executing a task that they can’t articulate everything they do.
Observations are time consuming, so they aren’t suitable for every user or every task.
Observing a user’s workflow in the task environment allows the BA to validate information collected from other sources, to identify new topics for interviews, to see problems with the  current system, and to identify ways that the new system can better support the workflow.
Observations can be silent or interactive. Silent observations are appropriate when busy users cannot be interrupted. Interactive observations allow the BA to interrupt the user mid-task and ask a question. This is useful to understand immediately why a user made a choice or to ask him what he was thinking about when he took some action. Document what you observe for further analysis after the session.

Questionnaires are a way to survey large groups of users to understand their needs. They are inexpensive, making them a logical choice for eliciting information from large user populations, and they can be administered easily across geographical boundaries.
Preparing well-written questions is the biggest challenge with questionnaires.

Brain storming
It can be done in groups or individually. The ideas collected must be reviewed and analyzed and if they are relevant should be included. It helps in coming with innovate requirements and generating many ideas. And later these ideas must be prioritized. 
1)   Prepare for brainstorming : Define the area, time limit, stakeholders to be included and the roles, criteria to rate the ideas.
2)   Conduct the session: Record all ideas, share ideas without criticism.
3)   Wrap-up the session: Evaluate the ideas, rate the ideas, communicate the finalized ideas.

Reverse Engineering:
Reverse engineering is used to elicit the requirements from the implemented software code, if this software system has outdated or little existing documentation.
Reverse engineering is of two types.
Black Box: The system is studied without examining its internal structure.
White box: The inner working of system is studied.

It is an extended facilitated workshop. It involves collaboration between internal and external stake holders to identify the requirements in a concentrated and focused effort.


A software prototype is a partial, possible, or preliminary implementation of a proposed new product.
Prototypes can serve three major purposes,

Clarify, complete, and validate requirements: User evaluation of the prototype points out problems with requirements and uncovers overlooked requirements, which you can correct at low cost before you construct the actual product. This is especially helpful for parts of the system that are not well understood or are particularly risky or complex.

Explore design alternatives: They’re useful for confirming the developers understanding of the requirements before constructing actual solution.

Create a subset that will grow into the ultimate product.

The primary reason for creating a prototype is to resolve uncertainties early in the  development process. A prototype is useful for finding and solving ambiguity and incompleteness in the requirements.
Three classes of prototype
Scope : A mock-up prototype focuses on the user experience
Future use:  A throwaway prototype is discarded after it has been used to generate feedback, whereas an evolutionary prototype grows into the final product through a series of iterations
Form : A paper prototype is a simple sketch drawn on paper, a whiteboard

System interface analysis

Interface analysis is an independent elicitation technique that entails examining the systems to which your system connects. System interface analysis reveals functional requirements regarding the exchange of data and services between systems
For each system that interfaces with yours, identify functionality in the other system that might lead to requirements for your system.

User interface analysis
User interface (UI) analysis is an independent elicitation technique in which you study existing systems to discover user and functional requirements.

Document analysis
Document analysis means examining any existing documentation for potential software requirements. The most useful documentation includes requirements specifications, business processes, lessons-learned collections, and user manuals for existing or similar applications. Documents can describe corporate or industry standards that must be followed or regulations with which the product must comply. When replacing an existing system, past documentation can reveal functionality that might need to be retained, as well as obsolete functionality.
A risk with this technique is that the available documents might not be up to date. Requirements might have changed without the specifications being updated, or functionality might be documented that is not needed in a new system.


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #16 on: February 08, 2018, 11:25:16 am »
Elicitation techniques as below 

1. Brainstorming
2. Document Analysis
3. Reverse Engineering
4. Focus Groups
5. Observation
6. Workshop
7. JAD Sessions
8. Interview
9. Prototyping
10. Questionnaire


  • Global Moderator
  • Newbie
  • *****
  • Posts: 34
Re: Elicitation Techniques in Business Analysis
« Reply #17 on: February 13, 2018, 04:07:11 pm »
Requirement Elicitation Technique:-

3.Questionnaire- open closed
5.Document Analysis- (AS-IS)
6.Focus Group- Active/Inactive- Homogeneous/Heterogeneous
8.Interface Analysis-(i/p,o/p)


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #18 on: March 10, 2018, 01:08:24 pm »
Requirement elicitation is the process of obtaining information from the stakeholders and it is the crux of requirement documentation. The different techniques used are-
o   Brainstorming
o   Document analysis
o   Reverse engineering
o   Interviews
o   Focus groups
o   Workshops
o   JAD workshops
o   Observation
o   Prototyping
o   Questionnaire


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #19 on: March 13, 2018, 11:02:57 pm »
Elicitation involves the actions that are taken to understand the users and discover their needs. 

Elicitation includes the discovery and some invention, as well as recording those bits of requirements information that customer representatives and subject matter experts (users) offer to the analyst. 

Below are few techniques used by BA,
1. Brainstorming
2. Document Analysis
3. Focus Group
4. Interface Analysis
5. Interview
6. Observation
7. Prototyping
8. Requirements Workshop
9. Reverse Engineering
10. Survey / Questionnaire


  • Global Moderator
  • Newbie
  • *****
  • Posts: 2
Re: Elicitation Techniques in Business Analysis
« Reply #20 on: March 21, 2018, 09:53:53 pm »
these all are mainly used techniques by BA
1. Brainstorming
2. Document Analysis
3. Focus Groups
4. Interface Analysis
5. Interviews
6. Observation
8.Requirements Workshops
9. Survey/Questionnaire


  • Global Moderator
  • Newbie
  • *****
  • Posts: 9
Re: Elicitation Techniques in Business Analysis
« Reply #21 on: March 26, 2018, 12:00:33 pm »
Elicitation Techniques : help to get more information with the clear understanding
Such technique's Are:
*Document Analysis
*Focus Groups
*Interface Analysis
*Requirements Workshops


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #22 on: April 07, 2018, 01:47:49 pm »
In the business environment, it is required to have an effective way of market research to understand what a customer wants and how to be successful over competitors. We need to focus on how to make the users to achieve their goals. The Requirements gathering process will help in understanding the needs of a customer, especially in the IT industry.

There are several different requirement gathering techniques that can be used. Several tools and techniques are used by the stakeholders and business analyst to facilitate this process and capture the exact and detailed requirements. The Requirements gathering techniques should help in breaking down Requirements and Gathering into digestible steps thereby providing instructions to complete each step.

Let us take a look at some of the requirements gathering techniques. Some commonly used methods include:

1. Interviews

Interviews are of primary ways for information gathering where the system analyst will  have face-to-face interaction with relevant stakeholders or subject matter experts. The business analyst will spend most of the time to interview system users and system owner during the early stages of project life cycle.

It is important to be very clearly articulate of the objectives of interviews and the questions could be prepared ahead of time or asked spontaneously and the responses should be recorded. Interviews could also be done with multiple interviewers and / or multiple interviewers.  Interviews could be either one on one or group interviews.

Types of Interviews
There are two types of interviews namely unstructured interviews and structured interviews.

These involve a conversation by the interviewee asking general questions. It is usually inefficient technique as it has a tendency to go off track from the main goal and the analyst will have to redirect the interview in the right path.

The interviewer will be the one making specific questions in order to obtain the required information from the interviewee. This type of interview is considered to be efficient.

It begins with focused questions and moves to open-ended discussion.  The data of interest will have to be predetermined.  Some of the questions that need to be asked are mentioned below.

How should a task be performed?
Why is this task being performed?
Under what conditions, this task should be performed?
What information do you need to complete the task
Whom should the communication be sent to?

2. Questionnaires

It is an informal technique in which a document is used to collect   information and opinion from respondents. It allows the system analyst to collect information from a target population which is very large and in remote locations or those who will have only minor input into the overall requirements. The responses could be sent for further statistical analysis if needed. It makes clear and specific questions and involves some closed questions with a range of answers.

Format for Questionnaires
Free format questionnaires will allow users to answer freely for each question. A question is asked and the respondent records the answer in the space provided after the question. An example of free format questions is “Are there any problems with the current functionality? If yes, please explain”

Fixed-format questionnaires contains questions that require a selection of predefined responses from individuals. Respondents need to select an answer from a set of answers given. An answer from this format is much easier to analyze. But, on the other hand, it is more static; respondents cannot give their opinion or answers other than provided.

3. Observations
Observation or job shadowing involves an analyst watching their client performing their daily tasks and asking questions about what they are doing and why. It is a great way to understand what the user might go through in their job and can provide some immediate requirements for how a process can be improved.

Types of Observation
Here the analyst does not interact with the worker at all while the observation is going on, but takes notes. The analyst can ask questions by using a prepared list of questions of the worker on completion of the entire process, but they are not to interrupt the person while they work. Some jobs are too hectic or dangerous for the worker to be constantly stopped and questioned. In those cases passive observation works the best.

Here the analyst can interrupt the worker to ask questions during the observation session. Some questions to ask include:

“Why are you doing this at this point?”
“What is usually the next step?”

4. Facilitated Workshops

Facilitated Workshops bring a larger group on a common platform to discuss and reach agreements. They help to define cross-functional requirements for a product in a faster manner than if you were to interview each of them separately. A successful facilitated session requires planning. The facilitator will need to consider a common meeting location, the session duration, how consensus will be achieved and the agenda.

5.Focus Groups

Focus groups involve synergistic discussion among people who are representative of the users or customers related to the expectations, features and other aspects of a product. A feedback will be collected about needs / opportunities / problems to identify requirements.

The discussion is facilitated by a trained moderator. The participants will be selected and their roles, topics to be discussed and logistics will be prepared for the focus group and a group report records about what was learned will be made.

6. Joint Application development (JAD)

It is a technique where a workshop is facilitated and the entire system participants sit and discuss for the system analysis and defining requirements. The discussion continues until the session objectives are completed and complete set of requirements is documented and agreed to.

It has been used to obtain and gather information from the group about the problems, objectives and system requirements. During the session, they sit together to discuss and get the ideas from the participants.

7. Brainstorming

It involves self-generated contribution of ideas by the group members around a specific issue, problem or requirement. The appropriate subject matter experts will start creatively brainstorming about what the solution might look like. The ideas gathered from the group members will be prioritized depending on the ones they think are the best for this solution. The resulting consensus of best ideas is used for the initial requirements.

The objective of brainstorming in a group is to reduce social suppression among group members and stimulate fresh ideas generation leading to an increase the overall creativity of the group.


In this approach, the preliminary requirements will be gathered which is used to build an initial version of the solution called a prototype. The prototype may not have all the functionality but serves as a proof of concept for idea verification/further analysis. An iterative process of prototype creation, testing and feedback is followed before reaching a final stage.

This repetitive process continues until the product meets the final goal of business for an agreed number of iterations.

9.Documentation Analysis

The technique involves written documentation of procedures and tasks that often exist, particularly in business contexts. It describes how things should be done rather than how they are. This also helps the Business Analyst to prepare questions for validating the requirement correctness and completeness. Most of the information is mostly buried in present documents that assist us in putting questions as a part of validating the requirement completeness.

The core of system analysis is to get as much as information needed to develop the system. Hence it is in our hands in deciding which techniques will best do the job in the time and with the resources available. During the requirement gathering, the analyst will identify what types of techniques will be used and what type of information will collected.

Satish kumar Gajula

  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #23 on: April 25, 2018, 09:27:21 pm »
Elicitation Techniques in Business Analysis are as follows:
   Brainstorming
   Document Analysis
   Reverse Engineering
   Focus Groups
   Observation
   Workshop
   JAD (Joint Application Development) – Requirements Workshop
   Interview
   Prototyping
   Questionnaire (Survey)


  • Global Moderator
  • Newbie
  • *****
  • Posts: 11
Re: Elicitation Techniques in Business Analysis
« Reply #24 on: May 19, 2018, 08:39:28 am »
Elicitation Techniques in Business Analysis:
1. Stakeholder Analysis: Stakeholder Analysis identifies all the users and stakeholders who may influence or be impacted by the system. This helps to ensure that needs of all those involved are taken into account
2. Brainstorming: It is utilized in the requirement elicitation to gather good number of ideas from a group of people. Usually brainstorming is used in identifying all he possible solutions to problems and simplifies the detail of opportunities.
3.Interviews:It is most important technique for gathering requirements is to sit down with the clients and ask them what they need .
4.Document Analysis: Document Analysis is an important technique in which present system is evaluated through documents and assist in AS-IS process documents and also driving the gap analysis .
5.Focus Groups: A Focus group is actually gathering of people who are customers or users representatives for a  product to gain its feedback. The feedback can be collected about opportunities, needs and problems to determine requirements or it can be collected to refine and validate the already elicited requirements.
6.Interface Analysis: It is a process of analyzing the touch points with another system and is vital to ensure that requirements are not overlooked that are not instantly visible to the users.
7.Observations: It is method of collecting requirements by observing the people doing their normal work.This method is generally used to find the additional requirements needed by the user,when user is unable to explain their expected requirements from the new product and problem in their existing product.
8.Prototyping:In this approach preliminary requirements are gathered to build the initial version of the solution and then ask client to provides the additional requirements for the application.This repetitive process continues until the product meets the critical mass of business needs or for an agreed number of iterations.
9.JAD(Joint Application development): This technique is most efficient for gathering requirements. The requirements workshops are more organized and structured where all the parties get together to document requirements.
10.Questionnaire: These are much more informal and they are good tools to gather requirements from stakeholders in remote locations or those who will have minor input to overall requirements .
11. Surveys: This technique is used when requirement gathering needs to be done from many people and interviews needs to be conducted with less time and less budget. In this techniques users are insisted on choose from the given options agree/disagree or rate something for requirements.


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #25 on: May 29, 2018, 01:09:01 pm »
Here I will explain couple of Elicitation Techniques.

A Business Analayst's job is to draw out the requirements from the Business Users and communicating the same to Developers and Testers.
Thus, there are several methods in which a BA will communicate to these Business Users. These methods are called Requirement Elicitation Techniques.
Below are the Requirement Elicitation Techniques:
1. Brainstorming
2. Document Analysis
3. Workshop
4. Observation
5. Reverse Engineering
6. JAD (Joint Application Development)
7. Interview
8. Questionnaire
9. Prototyping

A Brainstorming session is organized where multiple Business Users (6 to 8) come along with the creative ideas and thus, making it easy for BA to draw out
the requirements.

Observation are of 2 types:
1. Active Observation
2. Passive Observation

In Active Observation, the BA actively participates in the discussion with Business Users to elicit the requirements
In Passive Observation, the BA acts as a Spectator during the discussion happening among the Business Users. If a BA feels that the discussion is going
out of track, the BA pitches in and makes sure that the discussion continues related to the Product being discussed.

One of the effective methods to draw out accurate requirements is JAD sessions where other stakeholders such as Developers and testers may participate along with
the BAs and the Business Users.

In case the Business Users are not readily available for the discussion on requirements, a Questionnaire is sent to the users and the Business Users has
to make sure that the queries in Questionnaire are addressed within specified time range.

To make sure that the requirements are understood well by the BA, the BA prepares a prototype of the given product and the same is provided to stakeholders to give
a clear picture on the look and feel of the product.

After elicitating all possible requirements from the Business Users, the BA prepares the Functional Requirements specification document which contains the
detailed explanation of the requirements. The same is sent to Business Users for approval.
A meeting is then scheduled with the Developers to communicate the requirements so that the same can be implemented. During the product development phase,
the requirements are communicated to Testers and the required walkthrough sessions are scheduled where BA communicates with Testing team and make them understand
the requirements well.


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #26 on: June 03, 2018, 07:48:37 pm »
Elicitation techniques that can be used by a BA are mentioned below:

-Document Analysis
-Focus Groups
-Interface Analysis
-Requirements Workshops


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #27 on: June 15, 2018, 03:01:05 pm »
Pretty much what everyone mentioned before, depending on the situation, you can employ any of these,
Interviews, surveys, questionnaires, workshops, document analysis, focus groups, reverse engineering, brainstorming and many more situational techniques


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #28 on: June 22, 2018, 07:53:21 pm »
Below are the requirement elicitation technique

Document Analysis.
Focus Groups.
Interface Analysis.
Requirements Workshops


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Elicitation Techniques in Business Analysis
« Reply #29 on: June 25, 2018, 08:11:00 am »
Document Analysis
Focus Groups
Interface Analysis
Requirements Workshops