LLMs draft syntactically excellent requirements whose semantic quality — clarity, consistency, testability — is exactly where they fail. This module builds the draft-then-gate workflow: stories behind INVEST gates, acceptance criteria behind the testability question, BRDs assembled from evidence, and the AI turned on your own documents as an ambiguity linter and contradiction hunter.
Divya is a Senior BA at a Bengaluru fintech, seven years in, working on a merchant-onboarding revamp. Her squad adopted AI story drafting in Q1 and velocity looked great: from her discovery notes she generated a forty-two-story backlog in two days, each story with Given/When/Then acceptance criteria, each formatted exactly to the team's Jira template. The product owner skimmed and approved. Two sprints in, the cracks opened in one week.
First, QA rejected a story mid-sprint: the criterion "Then the merchant receives a timely verification decision" could not be automated — what is "timely"? Two testers had already disagreed about whether 4 hours passed. Second, a developer discovered that story MO-17 ("merchant can edit bank details after approval") flatly contradicted a compliance constraint captured in discovery — bank-detail changes after approval require re-verification, a rule sitting in Divya's own findings pack, uncited and forgotten. Third, the retro surfaced that three stories were really one compound story wearing three costumes, and nobody could say who the beneficiary of MO-31 even was.
None of these defects were exotic. Every one is on the standard checklist Divya would have applied to a junior analyst's hand-written stories. She had skipped the checklist because the drafts looked senior. That is the precise trap this module exists to close: the research consistently finds LLM-drafted requirements score high on syntax and structure and unreliably on semantics — clarity, internal consistency, non-redundancy, testability. The fluency is real; the quality is unverified. Draft-then-refine, with the refinement behind explicit gates, is the evidenced pattern — not draft-then-approve.
AI moves the requirements bottleneck, it doesn't remove it. Drafting used to be the slow step and review was cursory; now drafting is instant, which makes review the entire job. A team that keeps its old cursory review with its new drafting speed has simply automated the production of defects.
The INVEST gate. Every AI-drafted story passes a written check before it enters the backlog: Independent, Negotiable, Valuable, Estimable, Small, Testable — plus this track's addition, "who benefits, and why?" answered in one sentence by a human. The model reliably produces the form of a story; the gate tests the content. Compound stories fail Small and Independent; stories with no identifiable beneficiary fail Valuable; and the "so that" clause — the value statement — gets rewritten by hand, always, because it is the one line where the model most often produces plausible boilerplate ("so that the experience is improved") instead of the actual reason the work is worth funding.
The testability gate. Every acceptance criterion faces two questions, and one failure fails the criterion:
Generation itself is the easy part, and it is genuinely good: models enumerate edge cases — empty states, boundary values, permission variants, failure paths — more exhaustively than tired humans. Use that. The gates exist so exhaustive and untestable don't ship together.
For document-shaped deliverables, the workflow is assembly from an evidence pack, not generation from a prompt. Input: your cited findings (Module 2), the validated process maps, the decision log, and the org's template. The AI fills structure — background, process references, requirements tables, glossary — with every filled section linked back to evidence.
Three sections you hand-write, every time: the problem statement, the scope boundary (especially what is out), and the assumptions register. These are the document's judgment core, the sections a steering committee actually reads, and the places where AI boilerplate is most confidently generic.
The named anti-pattern is template-filling theater: a BRD where every heading has fluent paragraphs under it and no section traces to evidence — the document equivalent of Divya's story pack. It passes review because it is complete-looking; it fails in build because it is sourced from the model's priors about what companies like yours usually want. The test is brutal and simple: pick any requirement in the document and ask "which finding, which stakeholder, which document supports this?" If the answer chain breaks, you are reading theater.
Every template section filled. Requirements fluent and numbered. No evidence links. Problem statement could describe any company in the industry. Assumptions section says "standard assumptions apply." Passes a skim; collapses at the first "where did this come from?"
Sections filled from the findings pack, each requirement citing its source. Problem statement hand-written with measured baseline numbers. Scope-out list explicit. Assumptions named, owned and dated. Survives the steering committee's hardest question, because every answer is one click away.
The highest-leverage use in this module inverts the relationship: instead of AI writing requirements you review, AI reviews requirements — and you adjudicate. Two passes, run before every baseline.
Pass one: the ambiguity lint. The model sweeps the document for the defect classes below and proposes a rewrite for each hit into atomic, testable form — using EARS patterns (Easy Approach to Requirements Syntax: "When ⟨trigger⟩, the ⟨system⟩ shall ⟨response⟩") as the target shape. Ambiguity detection is one of the best-documented LLM strengths in the requirements-engineering literature; EARS gives it a deterministic target.
| Defect class | Smells like | EARS-style rewrite direction |
|---|---|---|
| Vague quantifier | "fast", "user-friendly", "minimal", "etc." | Named number, named list, or delete |
| Passive-voice actor gap | "the file shall be validated" | Which system or role validates — "When a file is received, the intake service shall validate…" |
| Compound requirement | "and… and… or…" chains | One requirement per shall; split and renumber |
| Unbounded quantifier | "all", "always", "any" | Bounded scope with the boundary named |
| Escape hatch | "as appropriate", "if necessary", "where applicable" | The condition made explicit, or the clause deleted |
| Implicit temporal | "immediately", "periodically" | A number with a unit and a measurement point |
You accept or reject per flag — some "vague" terms are deliberate placeholders pending a decision, and the lint output is a worklist, not an auto-fix. Run it before every review cycle, not just before baseline: defects are cheapest at the draft stage, and a lint pass costs minutes against the hours a review meeting spends relitigating "what does timely mean."
Pass two: the contradiction sweep. Long context is the enabling capability: feed the BRD, FRD, story pack and process-map narrative into one window and ask for contradictions, terminology drift, and orphan requirements — every finding cited by document and line, every finding adjudicated by you. This is the pass that catches MO-17-class defects (a story contradicting a constraint), "customer" meaning three different entities across four documents, and the FRD requirement no BRD objective owns. At 200-page program scale, no human review reliably catches cross-document drift; this is genuinely new capability, not just faster capability.
Run the lint and the sweep on documents you wrote before AI existed. The linter has no idea who authored the text, and most analysts find their hand-written baselines fail the same gates they've been applying to AI output. The gates are quality gates, not AI gates — that reframing is what makes the team adopt them.
Nonfunctional requirements are the classically under-elicited class — nobody in a workshop volunteers audit-trail retention periods. The fix is checklist-driven elicitation with the checklist generated per solution type: a customer portal prompts performance, accessibility (with the standard named), session security, PII retention; a batch integration prompts throughput windows, recovery, reconciliation, alerting; an AI feature prompts the Module 8 catalog. Feed ISO 25010 and Volere as context, generate the tuned question list, curate against org standards, and take it to the SMEs who own each answer. The model generates the questions; the business supplies the numbers; and every NFR then faces the same testability gate as everything else.
Objective-to-requirement-to-test matrices are tedious, deterministic-checkable and audit-critical — ideal AI work. Generate the matrix from your artifacts (structured outputs against Jira or ADO exports if your tooling allows), then verify by sampling links, not by re-deriving the whole matrix: ten random links checked tells you whether to trust the run. The matrix's products are its orphan lists: requirements with no test, tests tracing to nothing, objectives with no requirement — each one a defect you found before an auditor or a UAT cycle did.
On change requests, the same corpus machinery does impact analysis: feed the CR and get affected requirements, processes, tests and interfaces with reasoning attached, validated by you before the change board sees it. One line stays permanently human: the estimate. The model has no idea what your team's velocity, your vendor's change process, or your test environment's queue look like. Impact surface from the machine; cost and date from a human who owns the number.
A generated traceability matrix that nobody sampled is worse than no matrix — it converts "we don't know our coverage" (a visible gap) into "we believe we have coverage" (an invisible one). The sample is not optional ceremony; it is what changes the matrix from decoration into evidence.
AI writes requirements that look finished, and "looks finished" is not a quality attribute. Gate every story with INVEST, every criterion with "could QA automate it, could two people disagree," assemble documents from evidence and hand-write the judgment sections — then turn the model on your own corpus as linter and contradiction hunter. The gates are cheap; ungated fluency is not.