When you are actively eliciting business requirements on a live project, the worst place to start is a blank workshop agenda and a room full of stakeholders who have not been primed. I have made that mistake early in my career and I have watched other BAs make it too. You get a stream of opinions, tangents, and competing priorities, and you leave with pages of notes that are almost impossible to distil into coherent requirements. The fix is a two-step approach: mine your documented sources first, then go to your stakeholders with something to test rather than something to build from scratch.
These two methods, used in sequence, consistently produce better coverage than either one does alone. The first keeps you from missing things that are written down but rarely discussed. The second ensures the written record reflects what actually happens on the ground. Together they give you a defensible foundation for your business requirements document.
Method One: Desktop Analysis of Documented Sources
Before you speak to a single stakeholder, pull every piece of relevant documentation you can find. I am talking about strategic plans, policies, legislation, funding agreements, contracts, mission statements, and governance frameworks. Any document that defines the overarching principles or obligations of the organisation is a legitimate source of business requirements.
The process is straightforward. Read through each document and flag any statement, mandate, or policy that will place a demand on the project. Those flagged statements are candidate business requirements. You then take them back to stakeholders to validate whether they are current, applicable, and correctly interpreted. This is a much more productive conversation than asking stakeholders to generate requirements from memory.
This step is easy to skip, particularly under time pressure, and skipping it is consistently where projects get into trouble. I worked on Project X, a government program delivering a new grants management system. The project had been running for several months before I joined. During desktop analysis I reviewed the funding deed, a document that had been filed and largely forgotten. Buried in page 14 of a 22-page agreement was a single sentence requiring the organisation to maintain a longitudinal database of recipient outcomes for a minimum of seven years post-program, for the purpose of future evaluation. Not one person in the stakeholder group had raised this in discovery sessions. The technical team had designed a system with no long-term data retention capability at all.
When I raised it, the project sponsor initially pushed back. Her position was that this was an evaluation requirement, not a system requirement, and that it could be handled separately at program close. That took two weeks of structured conversations, a review of the funding deed with the legal team, and a formal change request to resolve. The data retention architecture had to be redesigned, which added cost and time. Had that clause been caught in desktop analysis at the start, the design would have accommodated it from day one. The friction was real, but it was far cheaper than discovering the gap after go-live.
This is why desktop analysis is not optional preparation work. It is a formal elicitation technique in its own right, and it should be planned and documented as such.
What to Look For in Documented Sources
- Mandates and obligations: Any clause in a funding deed, contract, or legislative instrument that places a specific requirement on the organisation or the system being built.
- Strategic priorities: Statements in strategic plans or board papers that define what the organisation is trying to achieve and within what timeframe.
- Policy constraints: Internal policies that govern how data must be handled, how services must be delivered, or how decisions must be documented.
- Metrics and reporting expectations: Any reference to how success will be measured, including KPIs, reporting cycles, or audit requirements.
- Predecessor project outputs: Previous business cases, lessons learned reports, or review findings that set the context for why this project was initiated.
Method Two: Structured Stakeholder Workshops and Interviews
Once you have completed your desktop analysis, you are ready to engage stakeholders. You now have a set of candidate requirements drawn from documents, and you have a much clearer picture of the business context. Your workshops and interviews can be targeted rather than exploratory, which saves time and produces sharper output.
The questions you ask in these sessions drive everything. I use a consistent set of prompts across most projects, adapted to the domain. They are designed to surface not just what the business does, but where it struggles and what it needs to do differently. Below is a comparison of the types of questions and the quality of output each one tends to produce.
| Question Type | Example Question | What It Uncovers |
|---|---|---|
| Function | What is the main purpose of this business area? | The strategic reason for the team’s existence and its primary accountability |
| Activity | What does the team actually do day to day? | Operational processes, manual steps, and workflow dependencies |
| Stakeholder mapping | Who is involved, internally and externally? | Full set of actors, including those not yet engaged in the project |
| Information flows | What information is required and what is produced? | Data inputs, outputs, formats, and approval chains |
| Systems and dependencies | What systems currently support the business activities? | Integration points, legacy constraints, and data ownership |
| Issues and risks | What are the main problems affecting your ability to deliver? | Pain points that requirements must address, and risks the solution must mitigate |
Continuing with the HR system example from the original project: when I ran workshops with the HR and payroll teams, I asked what was actually happening with employee form processing. The answer was striking. Every form, whether for leave, a change of personnel details, or an employment contract variation, was being processed on a Word template, printed, signed, physically transported to HR, verified manually, and then keyed into the HR management system by a payroll officer. Electronic copies were saved to a document management system and a hard copy went into the personnel file. The same information was being handled four times by four different people before it reached the system of record.
The issues and risks question produced three clear pain points: processing times were excessive, error rates in manual data entry were high and creating audit risk, and HR staff were spending the majority of their time chasing paper rather than delivering services. From those answers, the business requirements almost wrote themselves.
The business required the ability to:
- Manage HR knowledge and information strategically: Ensuring that employee data was managed in line with the organisation’s strategic directions and governance obligations, not scattered across Word documents and filing cabinets.
- Automate HR business processes: Delivering efficient service to employees by replacing manual paper-based workflows with a digital end-to-end process that reduced processing time and eliminated unnecessary handling steps.
- Provide accurate and timely reporting: Producing data that could support operational decisions and meet audit and compliance requirements without requiring manual reconciliation across multiple systems.
Notice that none of those requirements specifies a solution. They describe what the business needs to achieve, not how. That distinction matters. If you want to understand how business requirements differ from the functional specifications that follow from them, the article on business requirements documents versus functional requirements documents is worth reading before you write yours up.
Running the Workshop Effectively
A few things I do consistently to get better output from elicitation sessions. I share the candidate requirements from desktop analysis in advance and ask stakeholders to come prepared to confirm, challenge, or add to them. This prevents the session from starting at zero. I also ask the issues and risks question last, not first. When stakeholders lead with problems they tend to jump straight to solutions. When you ask about function, activity, and information first, they stay in descriptive mode longer, which gives you richer raw material. For a full guide on structuring these conversations, the requirements elicitation questions resource covers the full question set in more depth.
It is also worth noting that facilitation skills play a significant role in how much you get out of these sessions. A technically sound question set delivered by someone who cannot manage a dominant stakeholder or draw out a quiet subject matter expert will still produce incomplete requirements.
Comparing the Two Methods
| Dimension | Desktop Analysis | Stakeholder Workshops and Interviews |
|---|---|---|
| Primary source | Written documents: policies, contracts, strategies, legislation | People: subject matter experts, operational staff, sponsors |
| Best for uncovering | Obligations, mandates, and strategic context that stakeholders may not know or recall | Operational reality, pain points, and tacit knowledge not in any document |
| Risk if skipped | Mandatory requirements missed; compliance or contractual breaches later in the project | Requirements that look complete on paper but do not reflect how the business actually works |
| Output | Candidate requirements for stakeholder validation | Confirmed, refined, and prioritised business requirements |
| Sequence | Always first | Always after desktop analysis is complete |
What the table makes clear is that these methods are complementary, not interchangeable. I have never worked on a project where one alone was sufficient. Desktop analysis without stakeholder engagement produces requirements that are theoretically correct but operationally disconnected. Stakeholder engagement without desktop analysis produces requirements that reflect current thinking but miss what the organisation is actually obligated to do. Used together, in the right order, they give you a requirements set you can stand behind.
The discipline of doing both, thoroughly, before you write a single formal requirement is what separates requirements work that holds up through design and delivery from requirements work that generates endless change requests six months later. Get the foundation right at the start and the rest of the project has a much better chance of going where it is supposed to go.
Frequently asked questions
What does eliciting business requirements mean?
Eliciting business requirements means actively uncovering what an organisation needs a project or system to achieve, before any solution is designed. It involves reviewing documented sources and engaging stakeholders through interviews and workshops. The goal is to surface both stated and unstated needs that define why a project is being undertaken.
What are the best methods for eliciting business requirements?
The two most reliable methods are desktop analysis of existing documents such as strategies, policies, and contracts, followed by structured stakeholder workshops and interviews. Desktop analysis uncovers mandatory obligations that stakeholders may not recall, while workshops surface the operational reality behind the written record. Using both in sequence gives you far better coverage than either method alone.
What questions should I ask when eliciting business requirements?
Focus on six areas: the function of the business area, what the team actually does, who is involved internally and externally, what information is required and produced, what systems support current activities, and what issues and risks are affecting outcomes. These prompts keep stakeholders in descriptive mode rather than jumping straight to solutions. The answers map directly to business requirements.
What is the difference between business requirements and functional requirements?
Business requirements describe what the organisation needs to achieve and why, without specifying how. Functional requirements describe how a system or process must behave to meet those business needs. Business requirements come first and drive everything that follows in the requirements hierarchy.
What happens if you skip desktop analysis when gathering business requirements?
You risk missing mandatory requirements that are embedded in contracts, funding agreements, legislation, or policy documents. These are often single sentences in lengthy documents that no stakeholder will spontaneously raise in a workshop. Missing them can lead to systems being built without the capability to meet contractual or compliance obligations, which is expensive to fix after go-live.
Try Ash, Your Virtual BA
If you are working through elicitation right now and need help turning what you have heard in workshops into properly structured business requirements, Ash is built exactly for this. Ash guides you through a structured questioning process that mirrors the methods in this article, helping you move from raw stakeholder input to clear, well-formed requirements without the usual back-and-forth. Give it a go on your current project and see how quickly the requirements take shape. Try Ash Virtual BA.
Further reading
- Eliciting Requirements With Use Case | IIBA
- How Business Analysts Use AI to Improve Requirements, Elicitation, and Stakeholder Alignment | IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.