Acceptance criteria are the specific, measurable conditions that a system, subsystem, or component must satisfy for a customer, stakeholder, or testing authority to formally accept it as meeting requirements. They translate qualitative requirements into binary pass/fail statements: either the device holds 450g or it doesn't; either the latency is under 50ms or it isn't. Well-defined acceptance criteria eliminate ambiguity at the end of a development cycle and prevent 'close enough' arguments during acceptance testing.
For hardware projects, acceptance criteria are typically defined in a Test Plan or Acceptance Test Procedure (ATP) that maps directly to the system requirements specification. Each requirement should have at least one acceptance criterion specifying: what is measured, how it is measured (test method and equipment), under what conditions (load, temperature, input voltage), and what the pass threshold is. Without this rigor, acceptance testing becomes subjective and disputes arise between development teams and customers.
Acceptance criteria should be defined before design begins, not after. Writing acceptance criteria early forces requirement authors to think through what 'done' actually means and surfaces ambiguous requirements before engineering resources are committed. This practice, common in agile software teams, is equally valuable in hardware — a requirement that cannot be expressed as a measurable acceptance criterion is not ready for design.
Practical Example
For Requirement FR-07 ('The device shall achieve a wireless range of at least 100m in open field'): Acceptance Criterion AC-07: 'Device maintains packet loss below 1% at 100m distance, line-of-sight, at 2.4 GHz, measured using the standard RF test protocol at 23°C ambient.'
How SpecZero handles this
In SpecZero, the Target field on each requirement is the acceptance criterion anchor — it captures the measurable threshold that defines success. Combined with the linked verification status, it closes the loop between requirement and test result.
Related terms
Functional Requirements
Statements of what a system must do — behaviors, inputs, outputs, and capabilities.
Non-Functional Requirements(NFR)
Requirements that define quality attributes — how well a system performs, rather than what it does.
Verification and Validation(V&V)
Verification confirms a design meets its specifications; validation confirms the product meets user needs.
System Requirements Specification(SRS)
A formal document defining all requirements a system must satisfy, derived from stakeholder needs.