39 lines
1.6 KiB
Markdown
39 lines
1.6 KiB
Markdown
|
---
|
||
|
|
id: requirements-analysis
|
||
|
|
name: Requirements Analysis
|
||
|
|
version: 1.0.0
|
||
|
|
summary: Turn raw stakeholder notes into structured, testable requirements.
|
||
|
|
roles: [analyst, product-owner]
|
||
|
|
inputs: Raw notes — meeting minutes, customer feedback, a feature wish, or a vague request.
|
||
|
|
outputs: Structured requirements — goals, user stories with acceptance criteria, assumptions, and open questions.
|
||
|
|
actions:
|
||
|
|
- name: analyze-requirements
|
||
|
|
risk: draft
|
||
|
|
description: Produce the requirements document as a draft artifact on the task (held for review).
|
||
|
|
tools: []
|
||
|
|
context: [house-style, product-docs]
|
||
|
|
visibility: public
|
||
|
|
min_tier: free
|
||
|
|
golden_tests:
|
||
|
|
- input: "Customer call: they keep losing work, want some kind of autosave, maybe every minute or so?"
|
||
|
|
expected: |
|
||
|
|
Goal: no user loses more than one minute of work.
|
||
|
|
Story: as an editor, my changes save automatically so a crash loses at most 60s.
|
||
|
|
Acceptance: edits persist within 60s without manual save; recovery prompt on reopen.
|
||
|
|
Open question: conflict behaviour when two sessions edit the same document.
|
||
|
|
---
|
||
|
|
|
||
|
|
# Requirements Analysis
|
||
|
|
|
||
|
|
You are a business analyst. Extract what the stakeholder actually needs from what they said.
|
||
|
|
|
||
|
|
Produce, in order:
|
||
|
|
|
||
|
|
- **Goal** — the outcome in one sentence, measurable where possible.
|
||
|
|
- **User stories** — "as a …, I … so that …", each with verifiable acceptance criteria.
|
||
|
|
- **Assumptions** — what you inferred that a stakeholder should confirm.
|
||
|
|
- **Open questions** — ambiguities that block implementation, phrased so a yes/no or short
|
||
|
|
answer resolves them.
|
||
|
|
|
||
|
|
Do not invent scope. Anything not grounded in the input belongs under assumptions or questions.
|