Role-by-role guide to adopting AI across the full requirements lifecycle — from discovery through backlog, specs, and stakeholder reporting.
AI output quality is bounded by input structure. Attaching EventStorming board artifacts to an LLM prompt produced 3× more domain concepts than unstructured prose. EARS "shall" statements produce requirements that AI coding agents can parse as executable contracts. The shared failure mode across every task type is treating AI as a shortcut that works on messy inputs.
A prototype using EventStorming board photos as LLM context produced 9 schemas vs 3 from unstructured prose — same model, same prompt structure, better input. Codecentric case study
The implication: EventStorming, Domain Storytelling, and EARS aren't "extra process." They're the precision instruments that determine the ceiling of every downstream AI output.
Launched internationally May 2026. Kiro operates at the specification layer first — before writing a single line of code, it forces formalisation of intent into a structured spec using EARS notation with formal logic to catch contradictions. Represents the "spec-as-source" maturity level where humans edit only specs, never code directly.
Comparable tools at different maturity levels: Jira Rovo (spec-anchored, integrated with existing workflow), Copilot4DevOps (generates FRDs natively in Azure DevOps).
Role: Senior Business Analyst preparing for a stakeholder discovery session. Context: [Project name] — a [domain] system being built for [user group]. The primary stakeholder is [role, e.g. Head of Operations]. Task: Generate a structured interview guide with: • 5 opening questions to surface the business problem (not the solution) • 4 questions to uncover tacit knowledge and undocumented workarounds • 3 questions to identify constraints (regulatory, technical, organisational) • 2 closing questions to confirm understanding and agree next steps Constraints: No leading questions. Avoid solution-first framing. Each question should be open-ended and invite narrative. Output format: Numbered list grouped by section, with a one-line "why this question" note per item.
Role: Functional Analyst writing machine-parseable requirements. Context: Feature: [feature description in plain language] System: [system name and brief description] Actors: [list the actors involved] Task: Convert the above into EARS-formatted requirements using the correct template for each type: • Ubiquitous: The [system] shall [action] • Event-driven: When [trigger], the [system] shall [response] • State-driven: While [state], the [system] shall [action] • Optional: Where [feature] is included, the [system] shall [action] Constraints: Each statement covers exactly one behaviour. No compound "and/or" in a single requirement. Quantify non-functionals (e.g. "within 500 ms", "≥ 99.5% uptime"). Output format: Table with columns: ID | EARS Type | Requirement | Rationale
Role: Product Owner prioritising the next sprint's candidates. Context: Product: [product name]. Current sprint goal: [goal]. Stories for scoring: [paste story titles and one-line descriptions] Task: 1. Score each story on WSJF components (1–10 scale): • User/Business Value, Time Criticality, Risk Reduction, Job Size WSJF = (Value + Time + Risk) / Size 2. Classify each story by Kano category: • Must-Have / Performance / Excitement / Indifferent 3. Flag any story where Job Size > 5 as a split candidate. Important: Use WSJF scores for relative ranking ONLY. Job size estimates from AI run 10–20× too high for absolute planning. Output format: Ranked table: Story | Value | Time | Risk | Size | WSJF | Kano | Split?
Role: BA / PO producing a Sprint Review summary. Context: Sprint: [sprint number/name]. Goal: [sprint goal] Completed: [list stories done] Incomplete: [list stories carried over, with reason] Impediments: [list blockers encountered] Metrics: Velocity [N] pts. Burn-up: [status] Task: Produce THREE versions of the status report: A. Executive (≤ 5 bullet points) — business impact language, no jargon B. Steering / Sponsor (1 page) — decisions needed, risks, timeline impact C. Team retrospective input — honest, blameless, focused on process Output format: Three labelled sections. Version A must lead with the sprint goal outcome (achieved / partial / missed) in the first sentence.