https://hjohansen.dk/en/tags/verification/Recent content in Verification on HJohansen.dkHugoen-USSun, 24 May 2026 09:30:00 +0200https://hjohansen.dk/en/knowledge/traceability/overview/Sun, 24 May 2026 09:30:00 +0200https://hjohansen.dk/en/knowledge/traceability/overview/<p>A useful mental model for how engineering documentation fits together:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>Business Need </span></span><span style="display:flex;"><span> ↓ </span></span><span style="display:flex;"><span>Requirements (what) </span></span><span style="display:flex;"><span> ↓ </span></span><span style="display:flex;"><span>Acceptance Criteria (how to verify what) </span></span><span style="display:flex;"><span> ↓ </span></span><span style="display:flex;"><span>Design (how to build it) </span></span><span style="display:flex;"><span> ↓ </span></span><span style="display:flex;"><span>Implementation </span></span><span style="display:flex;"><span> ↓ </span></span><span style="display:flex;"><span>Tests (based on acceptance criteria) </span></span></code></pre></div><h2 id="key-principles">Key Principles</h2> <h3 id="1-traceability-is-key">1. Traceability is Key</h3> <p>Every requirement should link to:</p> <ul> <li>a design element</li> <li>one or more acceptance criteria</li> <li>one or more tests</li> </ul> <h3 id="2-avoid-mixing-levels">2. Avoid Mixing Levels</h3> <p>Common mistakes:</p>https://hjohansen.dk/en/knowledge/requirements/acceptance-criteria/Sun, 24 May 2026 08:30:00 +0200https://hjohansen.dk/en/knowledge/requirements/acceptance-criteria/<p>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.</p> <h2 id="common-formats">Common Formats</h2> <h3 id="rule-based">Rule-based</h3> <blockquote> <p>Given X, system shall do Y.</p> </blockquote> <h3 id="scenario-based-given--when--then">Scenario-based (Given / When / Then)</h3> <blockquote> <p>Given a valid batch recipe, When the user starts execution, Then the system shall validate parameters before proceeding.</p> </blockquote> <h2 id="key-properties">Key Properties</h2> <ul> <li><strong>Binary outcome</strong> — pass or fail, no ambiguity</li> <li><strong>Focus on observable behavior</strong> — not implementation details</li> <li><strong>Directly usable for testing</strong> — a tester can derive test cases</li> </ul> <h2 id="relationship-to-requirements">Relationship to Requirements</h2> <table> <thead> <tr> <th>Requirements</th> <th>Acceptance Criteria</th> </tr> </thead> <tbody> <tr> <td>What is needed</td> <td>How we know it works</td> </tr> <tr> <td>The goal</td> <td>The proof</td> </tr> <tr> <td>Can be abstract</td> <td>Must be concrete</td> </tr> </tbody> </table> <p>Think of acceptance criteria as the <strong>test contract</strong> for a requirement. Every requirement should link to one or more criteria.</p>