| status | {draft | proposed | deferred | planned | in-progress | blocked | passed | failed | waived} | |
|---|---|---|
| date |
|
➥ Write a single, testable requirement statement that specifies observable behavior or conditions. Use clear and active language focused on "what" the system must do, not "how" it will be implemented.
The system shall...
💡 Tips:
- Use normative language (e.g., "shall") for mandatory requirements and avoid vague qualifiers like "reasonable" or "suitable."
💬 Why the requirement exists — its value, intent, and the problem it addresses.
➥ Tie the requirement to business objectives, user needs, compliance obligations, or risk mitigation. Indicate key stakeholders and consequences of not meeting the requirement.
💡 Tips:
- Keep the rationale concise (one to three sentences) and avoid repeating the statement.
- Mention any assumptions/dependencies that affect the requirement’s necessity.
➥ List verifiable criteria that constitute success for the requirement. Specify observable outputs, numeric thresholds, timing constraints, and pass/fail conditions. Use bullet points or a short table for clarity, and reference specific test cases or data when available.
💡 Tips:
- Make each criterion independently verifiable and unambiguous; prefer criteria that can checked with a yes/no result.
- Use precise units, tolerances, and sample sizes for non-functional attributes (e.g., latency, throughput, accuracy).
Test | Analysis | Inspection | Demonstration | Other
➥ Briefly describe the verification approach. For Tests, reference test procedure IDs or suites; for Analysis, state models and assumptions; for Inspection or Demonstration, describe artifacts or scenarios to be examined.
💡 Tips:
- If multiple methods apply, indicate primary and secondary methods and their triggers.
➥ Provide supporting context, links, and references that help implementers and verifiers understand the requirement.
💡 Tips:
- Note any open issues, assumptions, or pending decisions that could affect the requirement.