hf-specify

Structured requirement specifications are produced by defining items with IDs, Types, Statements, Acceptance criteria, Priorities, and Sources. This establishes traceability anchors linking each requirement to verifiable evidence like user requests or external constraints.

Oversized requirements are split by clarifying scope boundaries and breaking them down into independent FR and NFR items. Each item receives a minimum contract of ID, Type, and Acceptance criteria using EARS or BDD formats to ensure testability.

EARS and BDD formats are needed when drafting acceptance criteria for requirement specifications to ensure they are verifiable. These formats clarify conditions and behaviors, anchoring decisions to testable evidence rather than ambiguous statements.

Non-functional requirements are handled by defining them as Quality Attribute Scenarios (QAS) based on ISO 25010. This structures NFRs with clear acceptance criteria and priority, ensuring they are testable and traceable alongside functional requirements.

Requirement deferral is used during scope clarification to manage non-core capabilities. By establishing boundaries, teams can separate essential FR/NFR items from deferred backlog items, maintaining focus on current work while preserving traceability.

If a requirement specification is returned for revision, you must update the draft using the review findings. The specification process re-applies to refine the FR/NFR rows, ensuring all minimum contract fields and success metrics meet review standards.