Acceptance Criteria

Sun, 24 May 2026 08:30:00 +0200

Acceptance criteria define how you prove a requirement is satisfied. They are concrete, verifiable, written in behavior terms, and often expressed as scenarios or rules.

Common Formats

Rule-based

Given X, system shall do Y.

Scenario-based (Given / When / Then)

Given a valid batch recipe, When the user starts execution, Then the system shall validate parameters before proceeding.

Key Properties

Binary outcome — pass or fail, no ambiguity
Focus on observable behavior — not implementation details
Directly usable for testing — a tester can derive test cases

Relationship to Requirements

Requirements	Acceptance Criteria
What is needed	How we know it works
The goal	The proof
Can be abstract	Must be concrete

Think of acceptance criteria as the test contract for a requirement. Every requirement should link to one or more criteria.

Requirements Engineering

Sun, 24 May 2026 08:00:00 +0200

Requirements describe what the system must achieve, not how. They sit at different levels of abstraction.

Levels of Requirements

1. Business Requirements

The highest-level intent. Expresses why something is needed. Usually stable over time.

“The system shall reduce manual batch configuration errors.”

2. User / Functional Requirements

Describes system behavior from a user or process point of view. Focuses on what the system does.

“The system shall validate all recipe parameters before execution.”

Requirements Engineering on HJohansen.dk