---
name: rd-requirement
description: >-
  Turn raw needs, meeting notes, stakeholder feedback, or business scenarios
  into a PRD, SRS, structured requirements, or traceability material. Use when
  scope, actors, rules, constraints, priorities, and acceptance must be made
  explicit and verifiable, including product, system, infrastructure, or AI-tool
  requirements. Route feasibility judgments, design, review, and implementation
  to their owning workflows.
---

# rd-requirement

Transform raw user needs into **structured, traceable, and verifiable requirements documents**.

## Deliverables

- PRD / SRS / structured requirements document
- User role and scenario model
- Stakeholder analysis matrix (for complex or multi-party projects)
- Requirements traceability matrix (optional)
- External-stakeholder confirmation questionnaire (only when an identifiable knowledge or decision owner holds a blocking answer)

## Execution Steps

### 1. Requirements Elicitation & Clarification

- Distinguish between the user's original phrasing and structured requirements; preserve original phrasing without altering intent
- Identify implicit assumptions and list them explicitly
- Resolve discoverable facts from supplied materials and the project before asking the user
- Ask only for decisions or decision-critical ambiguity; handle one high-impact decision branch at a time, and if risk is low, state assumptions and proceed
- When a decision-critical fact, decision, or approval is held by an identifiable external stakeholder and the current user lacks the knowledge or authority to answer, read [external-stakeholder-questionnaire.md](references/external-stakeholder-questionnaire.md); ask the current user only for the recipient and required return, not to answer on the recipient's behalf
- Identify overloaded or conflicting domain terms and propose a canonical term without inventing business meaning
- Use the 5W1H framework (Who / What / Why / When / Where / How) to ensure full dimensional coverage

**Completion criterion:** every decision-critical ambiguity is resolved or explicitly owned as an assumption, open decision, or verification action; discoverable facts are not left as user questions, and any external knowledge or authority gap has a recipient role and return criterion rather than an invented answer.

### 2. Requirements Classification & Structuring

Classify and organize along the following dimensions:

| Category | Content |
|----------|---------|
| Functional Requirements (FR) | What the system must do |
| Non-Functional Requirements (NFR) | Performance, availability, scalability, security, compatibility |
| Constraints | Tech stack, platform, regulations, budget, timeline |
| Assumptions | Unconfirmed premises that affect design |
| Exclusions | Items explicitly out of scope |
| Operating context | environment, topology, user capability, support, migration, and lifecycle constraints |

For document-centered projects, also classify:

| Category | Content |
|----------|---------|
| Stakeholders | users, owners, reviewers, maintainers, external agencies |
| Business rules | policy, process, approval, compliance, or operational rules |
| Data and interfaces | required data objects, external systems, exchange boundaries |
| Evidence sources | meeting notes, standards, existing documents, laws, product decisions |

**Completion criterion:** every in-scope scenario maps to identified actors, rules, data or interface boundaries, and at least one classified requirement or explicit exclusion.

### 3. Priority Labeling

Label each requirement with a priority:

- **P0 (Must Have)**: Project fails without it
- **P1 (Should Have)**: Important, but can be deferred to next iteration
- **P2 (Nice to Have)**: Beneficial if included
- **P3 (Won't Have)**: Identified but explicitly excluded

**Completion criterion:** every requirement has an explicit priority under the chosen scheme, and any priority conflict or missing decision authority is recorded instead of silently resolved.

### 4. Acceptance Criteria Definition

Attach verifiable acceptance criteria to each functional requirement:

- Use Given / When / Then when it fits the requirement
- Include normal path, exception path, boundary condition, and review/approval evidence
- For non-functional requirements, define measurable thresholds or explicit evaluation methods
- For policy or document requirements, define the review criterion and evidence needed for acceptance
- For installation, configuration, migration, or integration requirements, define the observable end state, verification method, failure behavior, and rollback expectation without prescribing an unapproved implementation

**Completion criterion:** every requirement has a checkable acceptance or evaluation method covering the material normal, exception, and boundary behavior, or is explicitly unresolved with a verification action.

### 5. Feasibility and Evidence Flags

Flag requirements that need evidence or a later feasibility decision without deciding viability here:

- Evidence status: verified, assumed, disputed, unknown, or decision-owned
- Risk routing: identify requirements that need `rd-feasibility`, stakeholder confirmation, or standards/legal verification
- Dependency flagging: identify upstream decisions, external systems, approvals, and standards references

**Completion criterion:** every requirement that could materially fail or block delivery has an evidence status, a named dependency or follow-up action, and an explicit downstream route where a feasibility verdict is needed; this artifact does not make that verdict.

### 6. Requirements Convergence Pass

Before delivery, perform a convergence check scoped to the requested change:

- Rewrite affected sections only where duplication, contradiction, temporary notes, or broken traceability require it; keep each fact, rule, or scenario in its owning section
- Perform document-wide consolidation for a new document, an explicitly requested full revision, or an identified cross-document consistency risk
- Preserve every requirement ID, source anchor, decision, constraint, priority, acceptance mapping, and existing artifact status; retain decisions before removing resolved questions or temporary notes
- Review affected dependencies and reopen any contradiction, missing acceptance method, or unresolved blocking decision

**Completion criterion:** the authorized changes and affected dependencies are internally consistent, identifiers and mappings remain intact, and no unresolved blocker is hidden in temporary notes; rewriting is required only where the check identifies a need.

## Context and Baseline Check

Pre-execution checks:
- Applicable project guidance, templates, and rules for requirements work
- Whether established product standards or quality attribute baselines exist
- Existing requirements document format and naming conventions
- Existing glossary, stakeholder map, review checklist, or standard terminology constraints

## Tool Selection

- Inspect user-provided and local project sources before external retrieval
- Use `rd-research` when laws, standards, policy, external interfaces, or other evidence materially affect a requirement
- Use only configured tools, prefer primary sources, and use library/API documentation retrieval only for current interface facts
- If retrieval is unavailable, mark the evidence gap instead of inventing a requirement

## Quality Gates

Pre-delivery checklist:

- [ ] Every identified in-scope core scenario is covered and traceable to a source or decision
- [ ] Every functional requirement has acceptance criteria
- [ ] Priorities use stated criteria, and every identified P0 need maps to a requirement or an explicit exclusion
- [ ] Assumptions and exclusions explicitly listed
- [ ] Every requirement has an acceptance method, or is explicitly marked as unresolved with a verification action
- [ ] Proposed products, models, vendors, tools, or configurations are separated from the underlying need unless approved as constraints
- [ ] Key terms, stakeholder roles, and business rules are consistent
- [ ] Decision-critical ambiguity is either resolved or explicitly listed
- [ ] Every blocking external knowledge or authority gap has a recipient role, questionnaire or equivalent action, and checkable return criterion; no answer is invented
- [ ] Requirements are traceable to original user statements or cited source material
- [ ] The scoped convergence check addressed relevant duplication or conflicts without losing IDs, source anchors, decisions, acceptance mappings, or artifact status

## Out of Scope

- Do not skip requirements clarification and jump directly into design
- Do not make technology selections during requirements analysis
- Do not approve requirements that cannot be verified
- Do not invent business rules, standards clauses, metrics, or stakeholder decisions without evidence