An LLM can produce a well-formed requirement in seconds. That is useful, but it is not the same as discovering the right requirement.
Requirements are decisions about needs, constraints and expected outcomes. The text is only the representation. If the underlying stakeholder intent is inconsistent, the process is undefined or a policy exception has not been resolved, better prose will not solve the problem.
Separate elicitation, analysis and articulation
AI is strongest at articulation: turning known information into concise structures, comparing sources, rewriting language, generating examples and drafting acceptance criteria. It is also useful during analysis: detecting contradictions, missing actors, undefined terms and unhandled scenarios.
Elicitation remains more difficult because stakeholders often do not state the real need directly. They describe the current system, a preferred screen, a historical workaround or a symptom. An experienced analyst explores why the requirement exists, who is affected, what outcome matters and what constraint is non-negotiable.
AI can support that conversation. It should not create false certainty around it.
Requirements need provenance
When an LLM drafts a requirement from workshop notes, legislation, process maps and existing documentation, the useful output is not just the sentence. It is the linkage to evidence. Which source supports the rule? Which stakeholder raised the exception? Which policy defines the threshold? Which assumption remains open?
This is especially important in regulated or high-consequence systems. NIST research on machine-generated reports emphasises completeness, accuracy and verifiability. The same principle applies to requirements: a polished artefact is weaker than a traceable one.
Use AI to attack ambiguity
One of the best uses of an LLM is adversarial analysis of a draft requirement. Ask it to identify undefined terms, conflicting conditions, missing negative cases, timing ambiguity, data dependencies, security implications and edge cases. Then have the analyst validate those observations with domain experts.
For a requirement such as “eligible applications should be automatically routed to the correct queue”, useful questions include: What defines eligible? When is eligibility known? What happens if the geospatial check is uncertain? What if the application belongs to multiple programmes? Can a supervisor override routing? What evidence is retained? Which service level applies?
The first sentence looks complete. The questions reveal the system.
User stories are often too small for architectural truth
LLMs are very good at creating backlogs. That can be dangerous because decomposing a problem into many plausible stories creates an appearance of delivery readiness. Cross-cutting concerns—data model, security, integration, migration, performance and audit—can disappear into a backlog unless the team maintains higher-level models.
I would use AI to help maintain traceability between business outcomes, process models, capabilities, epics, stories, architecture decisions and tests. That is far more valuable than generating hundreds of independent stories.
A practical human-AI analysis workflow
- Capture source evidence: workshop notes, policies, process models, system behaviour and data.
- Use AI to summarise themes, candidate rules and contradictions.
- Have the analyst resolve material ambiguity with the right stakeholder.
- Use AI to draft requirements, scenarios and acceptance criteria linked to evidence.
- Run an AI-assisted challenge for edge cases and cross-cutting impacts.
- Validate with business, architecture and test perspectives.
- Maintain provenance as the requirement changes.
The quality test
A strong requirement is not one that sounds professional. It is one that enables a decision about design, build and acceptance. The team should know why it exists, how to test it and what would make it invalid.
So yes, LLMs can write requirements. The more valuable capability is helping analysts turn fragmented evidence into requirements that remain connected to business intent.
Requirements are agreements, not prose
A beautifully worded user story can still be a bad requirement. What matters is whether the parties agree on the behaviour, boundaries, assumptions and acceptance evidence. LLMs are exceptionally good at turning rough material into structured language; that can create a false sense that analysis is complete. The risk is greatest when the source material itself is incomplete or contradictory.
I therefore separate generation from validation. An LLM can extract candidate actors, rules, decisions, data elements and exceptions from workshop notes or policy. It can identify terms used inconsistently and draft questions. The analyst then resolves those questions with the accountable people and records the source of the decision. Only then should the polished requirement become part of the delivery baseline.
Traceability becomes more important when drafting gets cheaper
If AI can create fifty plausible stories in minutes, teams need stronger mechanisms for knowing why each story exists. I want a requirement to link back to an outcome, process step, policy obligation, defect, data rule or architecture decision. I also want acceptance criteria that can be verified. That traceability helps prevent a large AI-generated backlog from becoming a new form of requirements debt.
Use the model as a critic as well as an author
Some of the most valuable analysis prompts are adversarial: identify missing exceptions; show where two rules conflict; list terms without definitions; find requirements that cannot be tested; compare the proposed process with the current one; identify data that is used but never created. These tasks improve the evidence base without pretending the model owns the requirement.
The analyst’s judgement remains central because requirements sit at the boundary between intent and commitment. AI can accelerate the mechanics of articulation. Accountability for what the organisation is actually choosing to build stays with people.
