Requirements elicitation
skills for analysts

Business analysts help organisations understand what they need and how to get there. Requirements elicitation — drawing out needs from people, documents and systems — is the heart of the role. The core techniques are interviews, workshops and focus groups, observation (job shadowing), document and data analysis, surveys, prototyping and process modelling. Analysts then analyse and prioritise requirements, resolve conflicts, document them clearly (often as user stories with acceptance criteria) and confirm understanding.

The IIBA's BABOK Guide defines business analysis as enabling change by defining needs and recommending solutions that deliver value, with elicitation and collaboration as a core knowledge area.¹ Getting requirements right avoids waste: Pendo found that 80% of software features are rarely or never used.² Testable requirements, often written in given–when–then form, make outcomes verifiable.³ It's one of India's largest analytical professions. AmbitionBox lists business analysts at a typical ₹9.6–10.7 lakh from over 1.5 lakh salary reports.⁴ In the US, the BLS groups business analysts with management analysts, who earned a $101,860 median in May 2025, with 10% growth projected to 2035.⁵

Business analyst salaries reported in India (AmbitionBox)

1.5 lakh+

Typical business analyst pay in India (AmbitionBox)

₹9.6–10.7 lakh

US median, management analysts (BLS, May 2025)

$101,860

US growth, management analysts, 2025–35 (BLS)

10%

Table: How business analysts are assessed (editorial summary)

Table: An elicitation plan for a claims project (illustrative)

Table: How business analysis developed (editorial summary)

• An elicitation plan with chosen techniques
• Interview notes with insights
• A workshop you facilitated
• Requirements written clearly with criteria
• A conflict you resolved
• A verified requirements elicitation certificate

Show impact: "Elicited requirements across 4 departments for claims redesign; observation revealed document-chasing as the main delay; checklist solution cut processing time and complaints."

"How do you elicit requirements from busy stakeholders?"

Short, focused interviews, observation, existing documents and data, and prototypes they can react to.

"How do you separate needs from solutions?"

Ask why repeatedly until you reach the underlying goal or problem.

"What do you do when stakeholders disagree?"

Clarify needs, link them to business goals, present trade-offs and help the decision-maker decide.

"How do you confirm requirements are right?"

Walkthroughs, prototypes, acceptance criteria and sign-off with stakeholders.

"What's traceability?"

Linking requirements to business goals, designs and tests so changes can be managed.

• "Which domains and systems would I work on?" — context.
• "Is the team agile or traditional?" — documentation style.
• "How do BAs work with product owners?" — role boundaries.
• "What tools are used for requirements?" — workflow.

Table: Business analysis roles and typical pay in India (AmbitionBox, October 2026; indicative)

Table: Common business analysis tools (editorial guidance)

• Junior BA / analyst — supports elicitation.
• Business analyst — owns requirements for projects.
• Senior BA — complex, cross-functional change.
• Lead BA / product owner — leads analysis or products.
• Consultant / head of BA — practice leadership.

1. Week 1: Plan — Choose a real process; plan elicitation.
2. Week 2: Elicit — Interview and observe.
3. Week 3: Analyse and write — Requirements with criteria.
4. Week 4: Prove it — Validate with stakeholders; take the Requirements Elicitation Certification.

Related: Business Process Modeling, User Stories and Stakeholder Management. Guides: process modelling, user stories and stakeholder management.

• Interviews and workshops — eliciting needs.
• Observation — understanding real work.
• Writing — requirements and stories.
• Modelling — processes and data.
• Clarifying — questions from developers.
• Validating — with stakeholders and testers.

"Which elicitation technique do you use most?"

It depends — interviews for depth, workshops for alignment, observation for reality.

"How do you handle a stakeholder who can't articulate needs?"

Observe their work, show prototypes and ask about recent examples.

Table: A first-90-days plan (editorial guidance)

Learn the domain and meet stakeholders first. Then run a focused elicitation on one problem using several techniques, and write requirements with clear acceptance criteria. Stay close to the team during build and testing so requirements turn into the right outcome.

AI tools now transcribe and summarise interviews, extract requirements from documents, draft user stories and generate process maps from descriptions. Analysts can cover more ground faster, and spend more time on the parts AI can't do: building trust with stakeholders, observing real work, spotting what people don't say and resolving conflicts.

Analysts also need to check AI output carefully — generated requirements can be incomplete, contradictory or invented. Many BAs now work on AI projects themselves, eliciting requirements for data, model quality, fairness and human review. In interviews, show how you'd use AI to speed up elicitation while validating everything with stakeholders.

Prepare by reading background material and writing open questions about goals, current process, pain points and success. Start the interview with context and permission to take notes. Ask about recent, specific examples: "Walk me through the last claim you processed." Probe with "why" and "what happens next". Avoid suggesting solutions. Close by summarising what you heard and asking what you missed. Write up notes within a day and share a short summary for confirmation. This habit catches misunderstandings early and builds stakeholder trust.

Workshops align groups quickly when they're well prepared. Define the purpose and the decisions you need, invite the right mix of people and share pre-reading such as current process maps or data. Start with the goal and ground rules, then use structured activities: walking through real examples, mapping the current process, listing pain points and prioritising needs with dot voting or ranking. Separate problems from solutions, and park out-of-scope topics visibly. Close by summarising decisions and open questions with owners. Send a written summary within a day for confirmation. A good workshop replaces weeks of back-and-forth emails with shared understanding.

"Stakeholders know what they want." They know their problems; good elicitation helps them discover what they need.

"One meeting is enough." Requirements emerge over time through several techniques and validation rounds.

"Agile teams don't need analysts." Agile teams still need clear, testable requirements — often written as stories with acceptance criteria.

"Documentation is the deliverable." Shared understanding and a working solution are the real deliverables; documents support them.

• Recording requests without asking why.
• Relying on one technique.
• Never observing real work.
• Untestable requirements.
• Skipping validation.

Business analysis definitions come from IIBA's BABOK Guide; India pay from AmbitionBox (read October 2026); US pay and outlook from the Bureau of Labor Statistics (May 2025); feature usage from Pendo; and acceptance criteria guidance from Agile Alliance. The elicitation plan, interview guide and history are editorial. Science of Apps publishes the free test linked here. Last reviewed October 2026.

• Requirements elicitation — drawing out needs from people and sources.
• BABOK — the Business Analysis Body of Knowledge.
• Workshop — a facilitated group session to elicit or agree requirements.
• Traceability — linking requirements to goals and tests.
• As-is process — how work happens today.