Requirements elicitation can be a pain. Best practice tells us that Business Analysts should employ various tools and techniques to elicit requirements, including interviews, and (my favourite) job shadowing. But in fast paced environments, our stakeholders are not always available. Many times, they can only spare an hour or two and that time is reserved for a group workshop.
Assuming we are in control of timelines and have enough notice, we can do some prep work by finding existing documentation or procedures. Other than that, all we can do is find a time, book a workshop, Invite everyone who might know something useful and hope the right people attend.
Sometimes that works. More often, it creates a familiar set of problems: the most important stakeholder cannot attend, people arrive without enough context, quieter voices are missed, and the session ends with a list of questions that need another meeting. Back to square one.
Asynchronous requirements elicitation offers another way to begin.
It does not replace workshops or the work of a Business Analyst. It gives stakeholders time to contribute in their own time, lets teams gather information before a discussion, and makes it easier to see where people agree, disagree or need to make a decision.
What is asynchronous requirements elicitation?
Asynchronous requirements elicitation is the process of gathering and clarifying stakeholder input without requiring everyone to be in the same meeting at the same time.
Instead of relying only on a workshop, stakeholders respond to structured questions over a period of time. Their answers are reviewed, followed up and organised before the project team meets to make decisions.
The approach can use written interviews, guided questionnaires, recorded walkthroughs, collaborative documents or software designed to conduct structured stakeholder conversations.
The important part is not the channel. It is the discipline behind it: ask useful questions, preserve the context behind each answer, follow up on gaps, and make unresolved issues visible.
Why requirements workshops are not enough on their own
Workshops are valuable when a group needs to explore an issue together, resolve competing priorities or make a decision.
They are less effective when the first goal is simply to collect information.
In a typical workshop, participants are asked to remember processes, explain exceptions, describe pain points and react to ideas in real time. That puts pressure on people to produce complete answers immediately. Many times, they will need to check a document, speak to their team or think through the detail before they can give a complete answer..
The result is often incomplete requirements rather than bad requirements. Important context appears later, usually when development has already started.
This is one reason requirements workshops can fail before they begin. The team has not done enough pre-work to understand who needs to contribute, what they know, or where the difficult questions are likely to be.
Asynchronous elicitation moves that pre-work earlier.
When asynchronous requirements elicitation works best
It is particularly useful when one or more of the following are true:
- Stakeholders are in different locations, time zones or shifts.
- Calendars are difficult to coordinate.
- The project involves many subject-matter experts, each with a narrow area of knowledge.
- People need time to check policies, reports, systems or examples before answering.
- The topic is sensitive and stakeholders may give more candid input privately.
- The team needs a broad view of the current state before bringing people together to decide on the future state.
- A Business Analyst needs to identify conflicts and open questions before a workshop.
It is not the right replacement for every conversation. Complex trade-offs, emotionally charged issues and decisions that require shared negotiation are usually better handled live. The value of asynchronous work is that it makes those live sessions more focused.
The difference between a questionnaire and good elicitation
Questionnaires sent in advanced of workshops can help the group be prepared for discussions.
A static questionnaire can collect useful facts, but it cannot easily respond when someone gives an incomplete answer, describes an exception or raises an unexpected issue. It also tends to produce output as a collection of individual responses rather than a shared understanding.
The ideal version of this would be iterative. A stakeholder’s answer should lead to the next useful question.
For example, instead of asking only, “What information do you need to approve a request?”, a structured conversation can explore:
- What makes a request ready for approval?
- What information is mandatory, and what is helpful but optional?
- What happens when that information is missing?
- Are there exceptions for particular customers, products or risk levels?
- Who can override the normal process, and why?
- How would you know that the process is working well?
Those answers start to reveal business rules, decisions, edge cases, risks and success measures and not just a list of fields.
A practical process for asynchronous requirements elicitation
1. Start with the business problem
Before contacting stakeholders, be clear about the decision or problem the team is trying to address.
Describe the current situation, the desired outcome and what is in and out of scope. This gives participants enough context to provide relevant input without steering them toward a predetermined solution.
2. Identify the right contributors
Do not only invite the most senior people or the people who are easiest to book.
Include people who perform the process, manage exceptions, receive the outputs, support customers and deal with problems when the normal path breaks down. A project can have perfect input from sponsors and still miss the practical knowledge held by frontline teams.
3. Ask questions in a useful order
Start broad, then become more specific.
Ask stakeholders to describe the current process and the problem they experience. Then explore the decisions they make, the information they rely on, the rules they follow, the exceptions they handle and the outcomes they need.
This follows the same principle as writing strong project requirements: clarity comes from understanding the need before prescribing the behaviour.
4. Follow up on gaps and ambiguity
The first response is rarely the complete answer.
Look for vague language such as “normally”, “usually”, “it depends” and “we just know”. These phrases often point to an unstated rule or exception that needs to be understood.
Follow-up questions should make the missing context explicit. What does it depend on? Who decides? What happens if the normal process cannot be followed? What evidence would show that the outcome is correct?
5. Separate facts from decisions
As responses arrive, organise them into categories such as business needs, rules, assumptions, risks, open questions and possible requirements.
This prevents an early suggestion from becoming an assumed requirement simply because it was written down first. It also makes it easier to see where two stakeholders are describing the same issue differently.
6. Use live time for the issues that need it
Once the input is collected, bring the right people together to resolve conflicts, agree priorities and make decisions.
The workshop should not be the first time the team hears the problem. It should be the point where the team works through the most important unresolved issues.
What good outputs look like
The output of asynchronous elicitation should be more than a transcript or a summary.
At a minimum, the team should be able to see:
- The problem being addressed and the intended outcome
- Stakeholder needs and areas of agreement
- Business rules, constraints and assumptions
- Decisions that still need to be made
- Conflicts or differences in stakeholder views
- Questions that require follow-up
- Requirements ready for review and validation
For AI-enabled solutions, the same process can also help teams define the user intent, expected outcomes, guardrails and situations where a human needs to intervene. These are central to writing AI requirements, where traditional functional descriptions may not be enough on their own.
Where AI can help (but where it should not decide)
AI can make asynchronous elicitation more practical by helping teams structure conversations, identify themes across multiple responses and highlight gaps or possible conflicts.
It should not silently decide what the requirements are. This is where a lot of AI solutions are headed but they run the risk of missing out on tacit knowledge which is not written down. Some of which is only thought of when a human is reviewing the output and spots something as being a little ‘off’.
Requirements remain a shared understanding between the people affected by a change. A Business Analyst and the relevant stakeholders still need to review the output, test assumptions and make the decisions that shape the solution.
The best use of AI is to reduce the manual effort around gathering, organising and preparing information, so that people can spend more time on judgement and also complete the process as efficiently as possible.
A better starting point for project delivery
Asynchronous requirements elicitation does not mean fewer conversations. It means fewer conversations spent collecting information that could have been gathered earlier.
When stakeholders have time to contribute, when their answers are followed up properly, and when open questions are visible before a workshop, teams can start delivery with a clearer understanding of the work ahead.
That is the opportunity behind Jessica, WORKSHOP IT’s AI-powered requirements elicitation software. Jessica helps teams gather structured stakeholder input asynchronously, synthesise responses and highlight agreements, gaps and conflicts before they become delivery problems.