The requirement elicitation method involves studying and finding system needs from users, customers, and other stakeholders. In this comprehensive guide, you will introduce with the popular techniques like brainstorming, requirement workshops, interviews, surveys, observation, document review, and prototyping, highlighting their benefits and practical applications.

Quick Links to Topic:

Requirement Elicitation Basics

Eliciting requirements is the process of determining what the system is doing and what the system should be doing. Not knowing what to do. The requirements process begins with elicitation.

What Requirement Elicitation is?

Requirement Elicitation is the process of gathering business requirements from users and stakeholders through various activities and being able to establish their expectations as well as understand their system constraints.

  • So it’s really all about getting them,
  • Interacting with them,
  • Asking them well-thought-out questions to find out what their needs are for this specific product, system, or process,
  • and understanding what they’re doing today
  • and what they need for it to work in the future, and so on.

What Requirement Elicitation is not?

Requirement Elicitation is the process of developing a large number of models and working through them to determine how things will be completed. After requirement elicitation, the system’s operation or buttons, UI, and so on will be defined.

There are three further processes after elicitation to develop those requirements, to massage them, to bring them together, and to make them ready for the design phase.

Requirement Elicitation VS Requirement Gathering

Gathering requirements is similar to Taking orders in a restaurant. Customers already know what the system is supposed to accomplish, and you’re simply writing it down. There is no room for doubt. Nothing can go wrong; everything is simple.

But the things are not the way it is.

You must be able to ask valid questions, elicit needs from users and stakeholders, and record those requirements. That sounds like hard labor. That is why it is termed eliciting rather than gathering requirements.

Requirement Elicitation Techniques

There are several approaches you may use to go through and pull requirements from stakeholders, documents, and so on.

And this will identify all those different technique. Each technique has their benefits, advantages, and disadvantages and some best practices well. So let’s get into the first particular technique and this is brainstorming.

  1. Brainstorming: Brainstorming sessions encourage open and creative thinking, allowing stakeholders to generate and share ideas freely. This technique fosters collaboration, enhances communication, and surfaces innovative requirements.

  2. Requirement Workshops: Workshops bring together stakeholders to collaboratively define and prioritize requirements. These sessions promote engagement, resolve conflicts, and ensure a shared understanding of project objectives.

  3. Interviews: One-on-one interviews with stakeholders enable in-depth discussions and the gathering of detailed requirements. Interviews provide valuable insights, uncover hidden needs, and clarify expectations.

  4. Surveys: Surveys allow for collecting a large volume of information from a diverse set of stakeholders. This technique provides quantitative and qualitative data, enabling a broader understanding of requirements.

  5. Observation: Observing users or processes in their natural environment helps uncover implicit requirements and identify pain points. This technique provides valuable context and aids in designing user-centric solutions.

  6. Document Review: Reviewing existing documentation, such as business reports or system specifications, helps identify relevant requirements and uncover potential gaps or inconsistencies.

  7. Prototyping: Creating prototypes, whether low-fidelity sketches or interactive mockups, helps stakeholders visualize the proposed solution, provide feedback, and refine requirements.

Effective requirements elicitation is crucial for project success. By utilizing techniques like brainstorming, workshops, interviews, surveys, observation, document review, and prototyping, organizations can ensure comprehensive and accurate capture of stakeholder needs, leading to the development of successful and user-centric solutions.

Essential Steps for Successful Gathering of Requirements

Requirement elicitation is a critical process in software development that involves gathering and documenting requirements from stakeholders. By following this checklist, you can ensure a systematic and effective approach to requirement elicitation.

  1. Identify Stakeholders: Identify all relevant stakeholders who will provide valuable insights and input during the requirement elicitation process.

  2. Define Objectives: Clearly define the objectives and goals of the project to align the requirement gathering process with the project’s purpose.

  3. Establish Communication Channels: Set up effective communication channels to facilitate open and clear communication with stakeholders throughout the elicitation process.

  4. Plan Elicitation Techniques:

Select and plan appropriate requirement elicitation techniques, such as interviews, workshops, questionnaires, or prototypes, based on the project’s complexity and stakeholder preferences.

  1. Prepare Documentation Templates: Prepare templates for documenting requirements to ensure consistency and ease of analysis.

  2. Conduct Elicitation Sessions: Schedule and conduct requirement elicitation sessions with stakeholders, using the chosen techniques to gather and capture their requirements.

  3. Analyze and Prioritize Requirements: Analyze the gathered requirements, identify dependencies, and prioritize them based on their importance and impact on the project.

  4. Validate Requirements: Validate the requirements with stakeholders to ensure their accuracy, completeness, and alignment with their needs and expectations.

  5. Document Requirements: Document the elicited requirements using the agreed-upon templates, ensuring clarity, traceability, and ease of understanding.

  6. Review and Refine: Conduct periodic reviews of the requirements to address any changes or updates, refining them based on feedback and evolving project needs.

Best Practices for Requirement Elicitation:

  • Stakeholder Engagement: Engage with stakeholders from diverse backgrounds and roles to gain a holistic understanding of requirements.
  • Clear Communication: Establish effective communication channels to ensure a shared understanding among all stakeholders.
  • Use a Variety of Techniques: Utilize a combination of techniques such as interviews, workshops, surveys, and observation to gather comprehensive requirements.
  • Active Listening: Actively listen to stakeholders to uncover implicit requirements and identify potential gaps.
  • Prioritize and Validate Requirements: Prioritize requirements based on their importance and validate them with stakeholders to ensure accuracy.
  • Iterative Approach: Embrace an iterative approach to requirement elicitation, allowing for continuous refinement and validation.

Let’s dive deep with requirements elicitation techiniques:

Brainstorming: Elicitation Technique

Brainstorming is used in requirement capturing to acquire as many ideas from a group of individuals as feasible. Generally used to find potential answers to issues and to explain specifics of possibilities.

It was invented in 1953 by advertising executive Alex Osborn, brainstorming is a creative approach used by groups of people to develop ideas to solve a specific problem.

So you may use brainstorming to help solve an existing problem that may have arisen very early stages of the project, in the middle of the project, or towards the end of the project.

It might also be to generate thoughts and ideas, which is a common misperception or perspective held by many people. Gather in a room to brainstorm alternative solutions to a problem or to achieve an agreement.

What are the different kinds of brainstorming?

  • Individual Brainstorming
  • Open Brainstorming
  • Structured Brainstorming

  1. The first type is an individual brainstorming. As a result, a project team member compiles a list of ideas. It’s more like you submitted them a question or a problem, and then they brainstormed solutions.

  2. The second method is open brainstorming, which is the most popular. So, you get folks in a room and just say, OK, here’s the agenda, here’s the problem, here’s what we’re going to do. You start with something and then let them go, and people start chatting, tossing ideas around, and becoming enthusiastic. Other people are feeding off the ideas that are being spoken, and you’re just kind of rolling, with a scribe writing everything. As the business analyst, you may be that person. Hopefully not. You’d want to provide some of those brainstorming thoughts.

  3. The last type is a structured brainstorming session. So, participants are jotting down their thoughts, and then a facilitator goes around the room one by one. They’ll go around the table until everyone has exhausted their whole list of ideas. The work is organized such that people (shy, afraid, or experienced) may feel comfortable sharing their views.

What are the advantage and disadvantage of Brainstorming?

Why would you use this elicitation method?

Advantage of Brainstorming:

  • ✅ It creates a lot of ideas quickly, especially if you have an open brainstorming session.
  • ✅ If you’ve done a good job of bringing in the proper stakeholders and people for the brainstorming session, you’ll receive multiple perspectives.
  • ✅ It promotes equal participation. Whether in an organized or unstructured atmosphere.
  • ✅ It assists in avoiding biases toward any one point of view.
  • ✅ It develops companionship and a sense of ownership.

Disadvantage of Brainstorming:

  • ❌ One big thing is ideas aren’t discussed or explored - just get lots of ideas out of the way and start looking at them.
  • ❌ You don’t really dive into it, so that’s kind of one of the cons. As well as the true meaning of that idea could be ambiguous or misunderstood.
  • ❌ And high level of discussion can cause some issue there.
  • ❌ Some dump suggestions may be allowed for evaluation as well
  • ❌ It is possible for ideas to overlap.
  • ❌ Some emotional and environmental mental impediments may occur, such as dissatisfaction with chaos, fear of criticism, and the continuation of wrong assumptions.

Brainstorming Best Practices:

  • 🎯 Determine type of brainstorming meeting ahead of time
  • 🎯 Publish an agenda prior to the brainstorming session
  • 🎯 Clearly state the objective of the meeting
  • 🎯 Create environment to encourage participation
  • 🎯 Establish ground rules:
    • Do not discuss ideas during the brainstorming session – only questions to clarify
    • Do not dismiss or discount an idea or person
    • Do build on others’ suggestions and ideas
    • Do have fun
  • 🎯 Establish roles:
    • Timekeeper
    • Scribe
    • Facilitator
  • 🎯 Create process for combining, categorizing, and summarizing like ideas
  • 🎯 If complex, create multiple meetings to keep meeting fatigue low
  • 🎯 Schedule follow-up meetings
  • 🎯 Prioritize final ideas to plan further analysis
  • 🎯 Allow votes for top ideas

Requirement Elicitiation Workshop

The first thing is, What is a requirement elicitition workshop?

A requirements workshop is a planned and facilitated event that brings together carefully selected stakeholders to find, refine, prioritize, validate, and debate needs. Workshop sessions are often managed by a competent facilitator. It is collaborative in nature and has its origins in Joint Application Design (JAD).

A requirement workshop is an organized gathering in which many organizations and users participate. It involves end users, subject matter experts, who might be from the business or from the technology side, the IT side. Any sort of businessperson who will be making decisions. As with most elicitation approaches, it works to define, clarify, and complete requirements. You have an agenda, an issue to select and attack, and subject matter experts to collaborate with.

So there are a few various sorts of requirement elicitition workshops, and a lot of them revolve with what you want to gather and the type of project you have.

What are the different kinds of requirement workshops?

  • Formal requirement elicitition workshop
  • Business process improvement workshop
  • Agile requirements workshops

The first type is a formal requirements workshop. This is a highly planned and official meeting in which you invite stakeholders, have a very specific agenda that you’re seeking to follow, and have a formal sit down discussion to address these needs.

You also have a carefully selected set of stakeholders; you want to make sure that you’re adding people who will contribute value to the project and this specific demand discussion without derailing it.

That is, you are defining, verifying, clarifying, and completing some needs and documenting them in the requirements document. This is the most popular type of workshop.

So the method comes next, the business process improvement workshop. This one, you’re actually diving into a specific process; it may be their as-is process, or you could be diving into their as-is process and working to mold it into the to-be process. So you have them in the room, and what you’re going to do is work through and determine what those process improvements are.

You write the action or event on the (Sticky Note) and stick it on the board. You can move them around without having to erase or redraw anything, and doing so with a group of people seated around a table is incredibly simple.

Agile requirements workshop is the third method. As you can expect, it is used in an agile setting. And they are frequently less regimented and more casual.

As you may know, with agile, you must include the product backlog and requirements as part of the sprint that you are working on. This is often used at the outset of a project to grasp the complete scope of the project and to begin writing out some of the early requirements that will be utilized as part of the project.

What are the advantage and disadvantage of Requirement Workshop?

Advantage of Requirement Workshop:

  • It helps you actually really get into the details and there are the real requirements
  • The brief intense session facilitates the collecting of relevant expressed criteria
  • Having the relevant stakeholders in attendance fosters buy-in.
  • The conditions put up are addressed and understood properly before moving to approval
  • The required accuracy from them is significantly faster, and you can also receive that confirmation.
  • It is a little more quick in terms of both decisions and communication to users.

Disadvantage of Requirement Workshop:

  • Workshops can be expensive, not just financially, but also in terms of time and coordination.
  • It might be challenging to gather all of the relevant stakeholders in one place at the same time, especially those with decision-making authority.
  • To obtain a final decision, workshops may need to be repeated
  • The facilitator must be persuasive in order to lead the debate in the appropriate path. If they don’t do a good job of directing the conversation, it might deviate and waste everyone’s time.

Requirement Workshop Best Practices:

And these are best practices that We can come up with in utilizing requirement workshops. It help in those projects that are larger in size when they have multiple groups that can bring the groups together.

Number one thing is, you need to determine the type of workshop ahead of time. In addition, as always when you’re getting a group of people together you want to be very clear on what the objective of that meeting is and be very clear on what that session will deliver in the end.

  • What are the end deliverables?
  • How will it help?
  • And what problems are you ultimately solving?
  • Why did you bring all these people together to have this discussion? It’s really important for everybody to understand what everybody else is talking about and the best way and you’ve heard it a probably a million times, as a visual or a picture is worth a thousand words, and that really rings true here.

Writing requirement in word, you can definitely do that in a smart way. But writing that in a way that everybody can understand within a meeting can be a little bit difficult, so it’s nice to use some type of visual models, whether it’s the post-it notes to identify that process or whether you’re creating some quick models, a Venn diagram or maybe just a quick view of kind of a visualization of that requirement how that could be solved.

The next thing everyone kind of alluded to this, the facilitator should be experienced, you shouldn’t be throwing a junior.

The next thing is don’t invite everybody. You need to make sure grabbing one or two people out of those key areas and pull them into the room. Target between 8 to 12 people.

The last thing is you need to remember you’re an analyst, not a facilitator, so you’re not there to take the order. You need to be bringing your experience and expertise to the table and kind of working through and massaging these requirements.

If there’s requirements that are conflicting with other requirements, call that out in this meeting, this is the perfect time to address those conflicting requirements and to come up with a solution for it.

Interviewing: Requirement Elicitation Technique

What is interviewing?

It is like job interview but here you will be interviewing your stakeholders through a structured question to identify and elicit requirement.

  • Systematic discussion to drive out accurate requirements quickly
  • Gain understanding of high-level needs, constraints, and assumptions
  • Reduces misunderstanding due to cultural differences, lack of openness, and acronyms/vocabulary
  • One on one or with a small group
  • Can be formal or informal
  • See the process or requirements from interviewee’s perspective

What are the different kinds of interviewing?

  • Personal interviews:
    • Scripted questions – interviewee’s answers are documented
    • Exploratory questions to clarify and validate requirements, while removing assumptions
  • Job shadowing:
    • Walk through a work day with a user or user group observing them
  • Customer site visits:
    • Understand operational environment to discover prerequisites for job success
  • Task analysis:
    • Ask end-users to walk through their current jobs
    • Show as-is process in order to identify essential and frequent tasks
    • Interviewer asks questions to understand what works well and what doesn’t

What are the advantage and disadvantage of Interviewing?

Advantage of Interviewing :

  • Promote interactive discussions to explore detailed information
  • Identify conflicts or discrepancies about stated needs or requirements
  • Encourage participation and build relationships by establishing rapport with the stakeholder
  • Enable observations of nonverbal behavior
  • Allow immediate follow-up to ensure understanding Disadvantage:
  • Require access and commitment of stakeholders
  • Creation of scripted interview questions can be time consuming
  • Stakeholders have difficulty describing their future needs, so the focus is usually focused on what they do currently
  • Resulting documentation is subject to interpretation of the interviewer
  • Transcription and analysis of interview data can be complex and expensive

Interviewing Best Practices

  • Determine the best interview type to accomplish your goals
  • Appropriately prepare for the interview
  • Schedule interviews ahead of time
  • Respect the person by being on time and display interest in the subject
  • Match the pace of the interviewee
    • If they are cautious, talk slow. If they are in a hurry, talk quickly
  • Check understanding often
  • Let interviewee know what will be done with the information
  • One person conducts interview while the other documents the answers. If not possible, record the interview.
  • Ask for examples of their issues and document screen shots
  • Interview two to three users for each user category you are targeting
  • Be sure to interview end-users, not just senior management who think they know how the process/system is used
  • Create thank-you email appreciating their time and how the information will help create quality requirements – (sent with interview invite)
  • Create a follow-up email telling the person how the information will be used and the next steps for the project – (sent after interview)
  • Allow time in the schedule to debrief and finish documentation after each interview Interview Questions?
  • Make questions open-ended
    • If they could answer the question with a yes or no, reword it
  • Avoid questions that may present judgement or a conclusion
  • Allow the questions to flow naturally so they can be put into conversation rather than a survey

Create Interview Document (That Generally Contains):

  • Name of interviewee
  • Role of person and their primary responsibilities
  • Open-ended questions
  • Space for answers
  • Space for interviewers’ insights
  • Action item box for flagging key pieces of information
  • Requirement, new requirement risk, assumption, or constraint

Sample Interviewing Question:

  • What are other ways you accomplish this goal?
  • Tell me about your frustrations with this process
  • What makes a good day? A bad day?
  • If you could wave your magic wand and make it different, what would the process look like?
  • What standards or regulations should we be aware of?
  • What purpose is accomplished by using the product or process?
  • What equipment, tools, templates, and inputs do people need to use it?
  • How long should tasks take?
  • What people do you share information with?
  • What failures cause the organization the most pain?
  • What didn’t I ask that I should have?
  • If we could only change one thing in the process, what should it be

Surveys: Requirement Elicitation Technique

What is Survey?

  • Questions to stakeholders to quantify their thoughts
  • Review of quantifiable data already available.

When acquiring information from a large number of people: too numerous to interview with limited time and resources: a questionnaire survey might be employed. The poll requires users to select one of two options: agree / disagree or rate something. Do not believe that you can create a survey on your own, but rather that you can contribute important insight to it. A well-designed survey must provide qualitative information to characterize the market. It should never be used to prioritize needs or features.

What are the different kinds of Survey?

  • Open Ended Questions:
    • Gives respondents an opportunity to answer in their own words
    • Useful, but very time consuming to interpret and catalogue.
  • Closed Ended Questions:
    • Finite set of answers for each question
    • Lends itself to statistical analysis
    • Tough to create questions that are not leading or need an “Other” answer
    • Questions can vary:
    • Ranking from “not very important” to “extremely important”
    • Ranking from “strongly disagree” to “strongly agree”
    • Rank order a list of items
    • Multiple choice question

    What are the advantage and disadvantage of Survey:

Advantage of Survey:

  • Require limited stakeholder’s time
  • Effective at reaching geographically dispersed stakeholders
  • Scalable for large audiences
  • Relatively fast and inexpensive to administer
  • Supplement more subjective information, such as opinions gained through interviews

Disadvantage of Survey:

  • Relatively low response rate
  • Poorly word questions may provide inaccurate information
  • Use of open-ended questions requirements more analysis by the business analyst
  • Require both instrument training and problem or business domain experience
  • Incentives for responding might be expensive

Survey Best Practices:

  • Focus your questions on high-priority risks that have been identified
  • Identify user satisfaction levels with existing systems to set a baseline
  • Questions should be direct and unambiguous
  • Save complex questions for later in the survey
  • Save demographic information for last
  • Create rewards for participating
  • Create the survey with inexpensive online tools
  • Notify the participants when the survey is available and continue to remind them to participate

Document Review: Requirement Elicitation Technique

What is Document Review?

  • Review existing documentation:
    • User guides
    • Prior system implementation documentation, including lessons learned
    • Technical documentation
    • Lessons learned after completion of latest project
  • Formulates context for understanding the scope of the project

What are the advantage and disadvantage of Document Review?

Advantage of Document Review:

  • Current process documentation provides a starting point

Disadvantage of Document Review:

  • Existing documents may be old and out-of-date
  • The reviewer needs domain and technical expertise to determine if existing
  • Can be time consuming, and may not provide the desired payback

Document Review Best Practices:

  • Know the purpose for reviewing
  • Set self-imposed time limits
  • Create a glossary of terms from former project documentation

Interface Analysis: Requirement Elicitation Technique

What is Interface Analysis?

  • Reviewing the system, people, and process linkages
  • Determine needs for input, output, and the medium
  • Describes manual and automated processes

Analyzing Interface Time:

  • Customer review meetings:
    • Identify formal requirements to link information, people, and processes
    • Drives a robust, complete, and accurate solution
  • Developer review meetings:
    • Happen early on
    • Review high-level requirements and system models
    • Identify interfaces, regulations, or technical standards What are some pros and cons: Advantage:
  • Discovers missed interfaces and their purposes
  • Determines regulations or interface standards
  • Provides missed requirements
  • Uncovers areas of project risk Disadvantage:
  • Not useful as standalone elicitation activity
  • Can begin to focus on many technical details
  • Can be redundant with modeling activities

Interface Analysis Best Practices:

  • Know the purpose for reviewing
  • Set self-imposed time limits
  • Create a glossary of terms from former project documentation

⬆ back to top

Enjoyed this post!

"Buy Me A Coffee" "Buy Me A Coffee"

Your support helps me create more valuable content. Thank you!

About Content Creator:

Hi, This is Rafayet Hossain

A Seasoned Business Systems Analyst, Project Manager, and SQA Engineer with experience in driving digital changes within organizations. I specialize in understanding business needs and developing software solutions to improve processes and drive growth. I am skilled in managing projects, analyzing data, and ensuring quality in the final product. I am passionate about using my expertise to help organizations reach their goals and succeed. Let’s work together to improve your business and drive success. Contact me for any inquiries or projects.

👉 Contact Information :

Linkedin Gmail

All Posts on Business Analysis:

Click on any of the desired links to directly access the information.

Enjoy !!! See Yaaa, Next.

Diary