Deliver·Production & Documentation·Automation·Developing·DEL-089
Requirements Refinement
Value hypothesis
Creates documentation that is more internally consistent, and hardened against misreading, to give development a stable base, limit rework, and increase fidelity between what is designed and what ships.
Quality · Risk Reduction
A draft requirements document is reviewed by an LLM before development teams begin implementation. The document (comprising user stories, acceptance criteria, functional specifications, and design notes) is checked for ambiguities, conflicting constraints, and language that could be interpreted differently by engineering and design teams. Issues are flagged for improvement, which the designer resolves against product intent, accepting what sharpens the spec, correcting drift, and rejecting language that should stay deliberately open. This revision creates a document optimised for internal coherence and intelligibility, which then goes into development.
Risks in application
Shallow Solutions
The LLM generates confident resolutions for ambiguities it cannot distinguish from deliberate openness: a requirement written as "the system handles unsupported file types gracefully" gets rewritten into three specific behaviours the model considers plausible, and the resulting crispness reads as improvement. Engineering builds against the refined version, and the flexibility the original wording preserved for a decision the team hadn't yet made is quietly closed off.
Black Box Rationale
Requirements refinements arrive as edits without traceable reasoning: an ambiguous clause becomes specific, but the basis for the chosen specification is not shown, and the team cannot tell whether the change reflects user research, technical constraint, or the LLM filling the gap unrequested.
Expertise that differentiates
Business Framing
A requirements document contains more than explicit constraints: it can contain open clauses that preserve flexibility for later trade-offs, negotiated truces between competing priorities, and context every original reader understood from being in the conversation. An LLM reads only the document and reframes strategic ambiguities as errors to correct. The practitioner judges which ambiguity is sloppy drafting and which is deliberate.
AI Fluency that assures
Process Description
Tuning refinement instructions to tolerate or flag some ambiguities as deliberate, while pushing to resolve others.
Process Discernment
Integrating traceability to upstream documents and other artefacts that contributed to the spec.
Related
Depends on
↓
↓
Enables
Possible Indicators
Error / defect rate
Number of defects in the requirements documents caught and corrected before implementation begins, versus baseline rate of equivalent defects reaching engineering as questions or rework.
Sources
Ford, P. (2026). New work, new words: A glossary for AI [conference talk]. Designing with AI 2026, Rosenfeld.