Requirements Quality
Purpose
Translate product intent into requirements and acceptance criteria that architecture, implementation, and QA can verify without relying on unstated assumptions.
Inputs
- Collect the product scope, domain constraints, competitor implications, and user journeys.
- Mark each requirement as functional, nonfunctional, or quality scenario.
- Tie requirements to user value or system risk.
- Identify what must be measurable before implementation begins.
Decision process
- Write functional requirements as system behaviors with actors, triggers, and expected outcomes.
- Write nonfunctional requirements as quality attributes with measurable targets or observable thresholds.
- Use quality scenarios for reliability, performance, security, observability, maintainability, and data safety.
- Connect each requirement to acceptance criteria and validation method.
- Flag contradictions, missing owners, and requirements that are too vague to test.
Decision boundaries
- Use Context7 MCP for current library, framework, platform, API, CLI, and configuration documentation whenever the task depends on external technology behavior.
Decision record
- Functional requirements
- Nonfunctional requirements
- Quality scenarios
- Acceptance criteria
- Traceability notes
Ready when
- Every important requirement should be testable.
- Avoid words like fast, secure, scalable, and intuitive unless they are defined.
- Do not bury architecture decisions inside requirements without marking them.
- Keep requirements small enough to assign and validate.
Handoff
Hand off requirements with IDs or stable names so architecture, tasks, QA, and docs can link back to them.
References
references/quality-scenario-format.md: Use this format for measurable quality scenarios.
1---2name: requirements-quality3description: Convert product scope into functional requirements, nonfunctional requirements, measurable quality scenarios, acceptance criteria, and traceable requirement links. Use before architecture or implementation when FR/NFR lists, reliability, security, observability, performance, maintainability, compatibility, accessibility, data-safety, or artifacts `11-functional-requirements.md` through `13-quality-scenarios.md` are needed.4---56# Requirements Quality78## Purpose910Translate product intent into requirements and acceptance criteria that architecture, implementation, and QA can verify without relying on unstated assumptions.1112## Inputs1314- Collect the product scope, domain constraints, competitor implications, and user journeys.15- Mark each requirement as functional, nonfunctional, or quality scenario.16- Tie requirements to user value or system risk.17- Identify what must be measurable before implementation begins.1819## Decision process20211. Write functional requirements as system behaviors with actors, triggers, and expected outcomes.222. Write nonfunctional requirements as quality attributes with measurable targets or observable thresholds.233. Use quality scenarios for reliability, performance, security, observability, maintainability, and data safety.244. Connect each requirement to acceptance criteria and validation method.255. Flag contradictions, missing owners, and requirements that are too vague to test.2627## Decision boundaries2829- Use Context7 MCP for current library, framework, platform, API, CLI, and configuration documentation whenever the task depends on external technology behavior.3031## Decision record3233- Functional requirements34- Nonfunctional requirements35- Quality scenarios36- Acceptance criteria37- Traceability notes3839## Ready when4041- Every important requirement should be testable.42- Avoid words like fast, secure, scalable, and intuitive unless they are defined.43- Do not bury architecture decisions inside requirements without marking them.44- Keep requirements small enough to assign and validate.4546## Handoff4748Hand off requirements with IDs or stable names so architecture, tasks, QA, and docs can link back to them.4950## References5152- `references/quality-scenario-format.md`: Use this format for measurable quality scenarios.
ashermahonin