Requirements engineering from stakeholder input

Most project failures start with requirements that are vague, contradictory, missing or never written down. LLMs can listen to workshops and interviews, read email threads and tickets, and draft well-formed requirements and user stories with source traceability, while flagging ambiguities and conflicts. Analysts spend their time on negotiation and validation rather than transcription and formatting.

Problem & value

• Today: business analysts and product owners attend meetings, take notes, rewrite them into user stories or "shall" statements, reconcile contradictions between departments and keep a backlog or requirements tool up to date. Context is lost between conversation and ticket; stakeholders discover gaps only during testing or acceptance.
• AI value: faster first drafts from raw material, consistent structure (templates such as EARS, user-story format, Gherkin), automatic detection of ambiguous words ("fast", "user-friendly"), duplicates and conflicts, and generation of clarifying questions. Traceability from each requirement back to the quote that produced it.
• Evidence: a systematic review of 74 studies (2023-2024) on LLMs in requirements engineering finds elicitation and verification/validation the most frequently addressed activities, with studies growing fast, but most evaluations are small-scale and few are industrial [1]. A review of prompting strategies for elicitation covers 58 studies [2]. Treat vendor productivity claims with caution; solid field data on quality gains is still thin.

Variants

• Meeting-to-backlog: transcript of a refinement or discovery workshop → draft stories in Jira / Azure DevOps.
• Document-to-requirements: tender, contract or regulation → requirement list (see DOC-015, CODE-025).
• Feedback mining: support tickets, reviews and survey responses clustered into feature requests and needs.
• Requirements quality assurance: checking existing specs against ISO/IEC/IEEE 29148 criteria (unambiguous, testable, consistent).
• Simulated stakeholders / personas: LLM agents role-play users to surface missed needs before real interviews (research stage, e.g. the Elicitron framework).
• Regulated domains: medical, automotive and public-sector specs with mandatory traceability (see CODE-020).
• Private / hobby use: structuring a personal app idea into a feature list before using CODE-007.

How it works

1. sources (recordings, mail, tickets, docs)
2. transcription + speaker separation (ASR, diarization)
3. cleaning + PII minimisation (names, health data)
4. extraction (needs, constraints, decisions, open questions)
5. structuring (requirement IDs, EARS / user story / Gherkin)
6. quality + consistency checks (ambiguity, duplicates, conflicts vs. repository via retrieval)
7. analyst review (accept / edit / reject, with source quote shown)
8. export to Jira / Azure DevOps / Confluence / requirements tool + traceability links
9. stakeholder validation round (generated summary and clarifying questions)

• Extraction and drafting: a general or reasoning LLM with a strict output schema and few-shot examples of the team's own requirement style.
• Consistency checking: embeddings plus reranking retrieve related existing requirements; the LLM compares pairs and labels duplicate / conflict / refinement.
• Human-in-the-loop: the analyst owns the requirement baseline. Every generated item carries a source quote and confidence; nothing enters the baseline without review, and stakeholders confirm the final wording.

Data preparation

Inputs are interview recordings and notes, workshop minutes, e-mails, existing specifications, tickets and process descriptions. In an SMB these are spread across mailboxes, shared drives, whiteboard photos, paper notes and meeting tools, often without a consistent naming scheme.

Typical gaps: unstructured audio without transcripts, scanned or photographed notes, duplicates and outdated versions of specifications, no glossary (the same term means different things), unclear sources of a requirement, and personal data of stakeholders inside the material.

Preparation steps: - Transcribe recordings locally with Whisper and agree on consent (PREP-007 for format conversion, PREP-006 for scanned notes). - Collect the current specification versions in one folder or repository and mark which is authoritative (PREP-009). - Build a project glossary and abbreviation list (PREP-015, PREP-012). - Provide two or three good example requirements and a template as gold standards (PREP-016). - Pseudonymise names where they are not needed (PREP-022) and check the legal basis (PREP-025).

Effort share: medium, around 30 %, dominated by consolidating material and the glossary. See GUIDE-003 for the readiness check.

Implementation paths

Which path for whom

• SMB: Path B, because requirements work is specific to the firm's tools and templates, and a lightweight API-based pipeline (transcribe, structure, link to tickets) fits better than a product.
• Enterprise: Path C, because stakeholder interviews and requirements are often confidential and contain personal data, and a shared internal platform with Whisper and an open-weight model avoids per-seat costs.
• Developer: Path C, because local transcription and a local model keep interview material private at low cost.
• Public sector: Path C on a sovereign EU or German cloud, because of procurement rules, sovereignty and the personal data of citizens and staff.

Path A — Buy (off-the-shelf)

• Backlog tools with built-in AI: Atlassian Rovo (Jira / Confluence, with a product-requirements agent and story drafting) [3]; Azure DevOps with GitHub Copilot; Productboard, Linear, ClickUp, Notion AI, Miro AI.
• Requirements-specific: Jama Connect (Advisor, requirements quality), IBM DOORS Next with watsonx, Visure (Brussels/Spain-based, EU), codeBeamer (PTC), Modern Requirements4DevOps.
• Meeting capture: Microsoft Teams Copilot, Zoom AI Companion, Fireflies, Otter, Granola; EU options such as Fathom-alternatives hosted in the EU, tl;dv, Sembly. Check EU data residency and consent features.
• Choose A when: the team already works in Jira or Azure DevOps and wants drafts inside the tool.

Path B — Build on cloud APIs

• Models: Claude, GPT, Gemini or Mistral (EU provider) with structured outputs; reasoning models for conflict analysis. Use EU regions (Azure OpenAI EU Data Zones, Vertex AI EU, AWS Bedrock Frankfurt, Mistral La Plateforme).
• Speech: Whisper-class or provider ASR with diarization (e.g. Azure Speech EU, Deepgram EU, Speechmatics - UK/EU).
• Integration: Jira / Azure DevOps REST APIs or MCP servers, n8n or Power Automate for orchestration, a vector store (pgvector, Qdrant - EU) for the requirements repository.
• Choose B when: you need your own requirement template, repository integration and review workflow.

Path C — Self-host (open source)

• ASR / diarization: Whisper large-v3 variants (faster-whisper), pyannote.audio, WhisperX.
• LLMs: open-weight models such as Qwen3, Llama, Mistral / Mixtral families, gpt-oss, served with vLLM or Ollama; embeddings with bge-m3 or Qwen embedding models.
• Stack: Qdrant or pgvector, n8n, Langfuse for tracing.
• Hardware: HW3 for a 70B-class model for good drafting quality; HW2 works with ~30B models if outputs are reviewed closely. Worth it when interviews contain confidential or personal data.

Path D — Custom training

Rarely justified. Fine-tuning on an organisation's approved requirements (several hundred to a few thousand items with source texts) can enforce house style and domain vocabulary, but prompting plus retrieval of examples usually achieves most of it.

State of the art (2026)

• LLMs write fluent, well-structured stories and acceptance criteria from clear inputs; quality drops with noisy transcripts, implicit domain knowledge and multi-party conflicts [1].
• Typical failure modes: hallucinated requirements nobody asked for, silently resolving conflicts instead of surfacing them, over-generic stories, missing non-functional requirements, and bias towards the loudest speaker in the transcript.
• Techniques that help: schema-constrained outputs, mandatory source quotes, separate "extract" and "critique" passes, retrieval of existing requirements, EARS templates, and generating clarifying questions rather than guessing.
• Agent setups link requirements to code and tests: spec-driven development tools (e.g. GitHub Spec Kit, Kiro) have specs drive coding agents (CODE-002), so requirement quality now directly determines code quality.
• Multi-agent persona simulation for elicitation remains research-stage [2].

Shared resources & combinations

• Same stack as meeting summarisation and DOC-015 (tender analysis): ASR + LLM + retrieval; one self-hosted LLM server serves all.
• Downstream: CODE-004 (tests from acceptance criteria), CODE-002 (coding agents consuming specs), CODE-006 (documentation), CODE-007 (prototype from description), CODE-014 (bug triage feedback loop).
• Regulatory rules as requirements: CODE-025 turns legislation into executable logic.

Effort, cost & KPIs

• Path A: days to weeks, per-seat pricing of the tools.
• Path B: 1-3 months for pipeline, templates and Jira integration; costs mainly transcription and LLM tokens (small versus analyst time).
• Path C: 2-4 months; GPU server plus operations.
• KPIs: analyst edit rate per generated item, share of requirements accepted unchanged, rework/change requests after sprint start, defects traced to requirement errors, time from workshop to refined backlog, stakeholder-validation turnaround.

People & change

Involve: management as sponsor, the department lead as owner of the requirements process, end users (business analysts, product owners, developers), the stakeholders whose statements are processed, IT, the data protection officer and legal/compliance. Customers and external stakeholders should be told when their statements are recorded and transcribed.

Works council: depends, usually yes if interviews with employees are recorded or analysed, because transcription and tagging of statements are technically suited to monitor behaviour (§87(1) no. 6 BetrVG, BAG: suitability suffices). Inform under §90(1) no. 3 and agree that outputs are not used for performance evaluation. Public sector: Personalrat.

Data protection: interviews contain personal data, so an AVV (Art. 28 GDPR), a documented legal basis, information or consent of participants and DPO involvement are needed; a DPIA is likely only for large-scale or sensitive interviews (GUIDE-005).

AI literacy: support analysts with training on checking AI-generated requirements for gaps and hallucinated needs (GUIDE-006).

Pilot and communication: try one project, with analysts reviewing every generated requirement. Concerns: "the AI misses nuance" and surveillance. Address both by keeping the analyst as author and by transparent consent (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: typically minimal risk; AI literacy duty (Art. 4). Not high-risk unless embedded in a product that is itself regulated. Recording participants with emotion or sentiment inference at work is an Art. 5 prohibited practice, so do not add emotion analysis to meeting analytics.
• GDPR: recordings and transcripts contain personal data of employees, customers and users; legal basis, notification of participants, retention limits, DPA with vendors, EU hosting. Works-council co-determination in Germany (BetrVG) for recording tools. Minimise personal data in generated requirements.
• Confidentiality: transcripts may include trade secrets; prefer enterprise tiers without training on inputs, or Path C.
• Quality and liability: for safety-critical or regulated products, requirements remain human-approved (ISO 26262, IEC 62304 traceability). Log AI suggestions versus accepted text.
• Mitigations: consent notice, redaction step, source quotes, mandatory review, periodic sampling audits.

Getting started

1. Pick one recurring meeting type (refinement or discovery) and record it with consent.
2. Define the target format (user story + Gherkin, or EARS) and give 10 good examples.
3. Build or enable a draft pipeline; require source quotes and a list of open questions.
4. Run in shadow mode for 3-4 sprints; measure edit rate and gaps found later.
5. Add consistency checks against the existing backlog, then export to the backlog tool.

Sources

1. Zadenoori et al. — Large Language Models (LLMs) for Requirements Engineering: A Systematic Literature Review — https://arxiv.org/abs/2509.11446
2. Prompting Strategies for Large Language Models in Requirements Elicitation: A Systematic Literature Review — https://trepo.tuni.fi/handle/10024/232320
3. Atlassian — Rovo product requirements agent — https://www.atlassian.com/software/rovo/use-cases/agent-product-requirements-expert
4. GitHub Docs — Integrating Copilot cloud agent with Azure Boards — https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/integrate-cloud-agent-with-azure-boards
5. pyannote.audio — https://github.com/pyannote/pyannote-audio
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj