The latest articles on DEV Community by Business Analysis DNA (badna). https://dev.to/badna https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Forganization%2Fprofile_image%2F14650%2Fe030263a-166b-47b8-8283-6d08a0ad7825.png https://dev.to/badna en Pinnacle Tech Solutions Ltd Sun, 06 Sep 2026 10:37:42 +0000 https://dev.to/badna/requirements-that-outlive-the-sign-off-meeting-that-wrote-it-kgf https://dev.to/badna/requirements-that-outlive-the-sign-off-meeting-that-wrote-it-kgf <p><em>Originally published at <a href="https://badna.pinnacletechsolutions.co.uk/blog/requirements-that-survive-delivery/" rel="noopener noreferrer">badna.pinnacletechsolutions.co.uk</a>. This is a shortened version.</em></p> <p>Every business analyst has watched the same thing happen. A requirement gets agreed in a workshop, written up, signed off by a stakeholder who nods at the summary slide, and handed to a delivery team as a line in a backlog. Three sprints later a developer asks what "the system shall support bulk upload" actually means, and nobody in the room was at the workshop.</p> <h2> Why sign-off prose decays </h2> <p>A requirement written for sign-off is optimised for one reader at one moment: the stakeholder deciding whether to approve it. It compresses a lot of context into a short sentence because everyone in that room shares the context. Delivery teams read the sentence months later, out of the room, without the shared assumptions that made it clear.</p> <h2> The shape that survives </h2> <p>What survives is a requirement written as a testable condition rather than an intent statement. The rewrite is mechanical once you know to look for it: replace a verb that describes a wish ("shall support", "shall enable", "shall allow") with a verb that describes an observable outcome, and attach the specific inputs and outputs that make the outcome checkable.</p> <p>Take "the system shall support bulk upload." Rewritten as acceptance criteria:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Given a CSV file of up to 5,000 rows in the agreed column format When a user uploads the file through the import screen Then every valid row is created as a new record within two minutes And every invalid row is reported by row number and reason, without stopping the valid rows </code></pre> </div> <p>A developer reading this eight months later can build against it without a single follow-up question, because "bulk" and "support" are gone, replaced by a row count, a time bound and an explicit statement of what happens to the rows that fail.</p> <p>The rewrite happens once, and it happens before sign-off, not after. A stakeholder who signs off on the acceptance-criteria version has actually agreed to the two-minute bound and the row-by-row error reporting, not to a vague promise a developer will later have to interpret alone.</p> <p>The full article also covers where the rewrite sits in the process, and the stakeholder-management half that keeps it honest rather than merely more precise.</p> <p><strong>Read the full article at <a href="https://badna.pinnacletechsolutions.co.uk/blog/requirements-that-survive-delivery/" rel="noopener noreferrer">badna.pinnacletechsolutions.co.uk/blog/requirements-that-survive-delivery/</a>.</strong></p> requirements businessanalysis agile productmanagement