https://hjohansen.dk/tags/specification/Recent content in Specification on HJohansen.dkHugoda-DKSun, 24 May 2026 09:00:00 +0200https://hjohansen.dk/knowledge/design/overview/Sun, 24 May 2026 09:00:00 +0200https://hjohansen.dk/knowledge/design/overview/<p>Design documents describe <em>how</em> requirements will be implemented. They bridge requirements → implementation → verification.</p> <h2 id="what-they-are-for">What They Are For</h2> <ul> <li>Translate requirements into system structure</li> <li>Align developers and engineers before implementation</li> <li>Define interfaces, data flows, and responsibilities</li> <li>Reduce ambiguity in complex systems</li> <li>Provide traceability back to requirements</li> </ul> <h2 id="typical-structure">Typical Structure</h2> <ol> <li><strong>Overview</strong> — purpose, scope, assumptions, constraints</li> <li><strong>Requirements reference</strong> — links to relevant requirements (traceability matrix optional)</li> <li><strong>High-level architecture</strong> — components, responsibilities, data flow</li> <li><strong>Detailed design</strong> — data structures, state machines, algorithms, interface definitions</li> <li><strong>Edge cases and failure handling</strong> — recovery strategies, validation rules</li> <li><strong>Non-functional considerations</strong> — performance, security, maintainability, scalability</li> <li><strong>Open questions / decisions</strong> — design trade-offs, alternatives considered</li> </ol> <h2 id="what-a-design-document-is-not">What a Design Document is NOT</h2> <ul> <li>Not a requirements document</li> <li>Not a step-by-step implementation script</li> <li>Not code (though diagrams and pseudocode are fine)</li> </ul> <hr> <p><strong>Se også:</strong> <a href="https://hjohansen.dk/knowledge/requirements/">Requirements Engineering</a>, <a href="https://hjohansen.dk/knowledge/pharma/">Pharma Automation Framework</a></p>https://hjohansen.dk/knowledge/requirements/overview/Sun, 24 May 2026 08:00:00 +0200https://hjohansen.dk/knowledge/requirements/overview/<p>Requirements describe what the system must achieve, not how. They sit at different levels of abstraction.</p> <h2 id="levels-of-requirements">Levels of Requirements</h2> <h3 id="1-business-requirements">1. Business Requirements</h3> <p>The highest-level intent. Expresses <em>why</em> something is needed. Usually stable over time.</p> <blockquote> <p>&ldquo;The system shall reduce manual batch configuration errors.&rdquo;</p> </blockquote> <h3 id="2-user--functional-requirements">2. User / Functional Requirements</h3> <p>Describes system behavior from a user or process point of view. Focuses on <em>what</em> the system does.</p> <blockquote> <p>&ldquo;The system shall validate all recipe parameters before execution.&rdquo;</p>