Part III — The Practitioner's Toolkit

LLM-Powered Requirements Elicitation

Requirements elicitation is one of the highest-leverage activities in any software project — and one of the most time-consuming. BAs spend hours in interviews, days synthesizing notes, and weeks iterating on requirements documents that still miss edge cases. LLMs accelerate the synthesis, analysis, and documentation phases of elicitation without replacing the human judgment that distinguishes good requirements from technically complete but wrong ones.

What You Will Learn

• Where LLMs genuinely accelerate requirements elicitation and where they add risk
• The synthesis workflow for turning interview notes and stakeholder inputs into structured requirements
• How to use LLMs for edge case identification and gap analysis
• The validation step that keeps LLMs from introducing plausible-sounding but incorrect requirements

25.1 Where LLMs Help and Where They Hurt

LLMs help with: synthesis (turning raw stakeholder input into structured requirements), completeness checking (identifying gaps in a requirements set relative to a standard template or prior similar projects), scenario generation (producing edge cases and alternative flows for a described business process), and documentation (converting structured requirements into different format styles — BRD, user story, acceptance criteria).

LLMs hurt when: they are asked to generate requirements from scratch without grounding in actual stakeholder input (they produce requirements that sound reasonable but do not reflect actual business needs), when their outputs are accepted without validation against stakeholder expectations, or when they are used to replace rather than accelerate the stakeholder engagement that produces requirements fidelity.

The fundamental principle: LLMs accelerate the synthesis and documentation phases of elicitation. They do not replace the listening and understanding phases.

25.2 The Synthesis Workflow

Input: Raw materials from elicitation — interview transcripts, workshop notes, email threads, existing documentation, whiteboard photos, Miro board exports.

Step 1: Prepare the input. Convert all raw materials to text. Clean up transcripts to remove filler words and off-topic discussion. Label each input with its source and the stakeholder's role.

Step 2: Extract themes. Prompt the LLM to identify recurring themes, stated needs, implied needs, and pain points from the raw materials. Review the extracted themes for accuracy — the LLM may miss nuanced stakeholder concerns that appeared only once or were stated obliquely.

Step 3: Draft requirements. For each identified need, prompt the LLM to draft requirements in the target format (user story, functional requirement, acceptance criteria). Specify the format precisely — user stories should follow the "As a [role], I want [action] so that [outcome]" template.

Step 4: Gap analysis. Prompt the LLM to compare the drafted requirements against a requirements completeness checklist (standard functionality areas for the system type, non-functional requirements categories, integration requirements) and identify gaps.

Step 5: Validate with stakeholders. The LLM-drafted requirements are a starting point, not a deliverable. Present them to stakeholders for validation, correction, and prioritization. Treat stakeholder corrections as the authoritative signal and the LLM draft as a conversation starter.

25.3 Edge Case Identification

LLMs are particularly useful for generating edge cases and alternative flows — the "what if" scenarios that elicitation interviews rarely surface because stakeholders are describing the happy path.

Given a described business process, prompt the LLM:

• "What are the most common failure modes in this type of process?"
• "What exceptions or special cases does this process not account for?"
• "What happens to this process when [specific constraint] applies?"
• "What regulatory requirements typically apply to this type of process in [industry]?"

The edge cases generated by the LLM are hypotheses, not requirements. Each must be validated with stakeholders — "Is this a scenario you actually encounter? How do you currently handle it?" — before being included in requirements.

25.4 Requirements Quality Checking

LLMs can check requirements for common quality problems:

Ambiguity: "Identify any requirements in this set that contain ambiguous terms — words that different stakeholders might interpret differently."

Incompleteness: "For each requirement in this set, identify any preconditions, dependencies, or acceptance criteria that are not specified."

Testability: "Which of these requirements cannot be directly tested? For each, suggest a reformulation that is testable."

Conflicts: "Identify any requirements in this set that appear to conflict with each other. For each conflict, describe the specific tension."

These checks should be run before requirements review sessions, not as a substitute for them. Requirements that pass LLM quality checks may still have problems that only stakeholders can identify — the LLM does not know the business well enough to catch semantic incorrectness, only syntactic and structural problems.