Design Checklist¶

General¶

SD-1 Do individual elements of the design (e.g., a diagram) conform to appropriate checklists?
SD-2 Does the design support both product and project goals?
SD-3 Is the design feasible from a technology, cost, and schedule standpoint?
SD-4 Have known design risks been identified, analyzed, and planned for or mitigated?
SD-5 Are the methodologies, notations, etc. used to create and capture the design appropriate?
SD-6 Does the level of formality match the project size, project goals, and engineer expertise?
SD-7 Has the design been refined based on prototyping or implementation feedback?
SD-8 If possible, were proven past designs reused?
SD-9 Does the design support proceeding to the next development step?

SD-10 Does the design have conceptual integrity? (i.e., does the whole thing hang together?)
SD-11 Can the design be implemented within technology and environmental constraints?
SD-12 Does the design use standard techniques and avoid exotic, hard-to-understand elements?
SD-13 Does the design emphasizes simplicity over cleverness?
SD-14 Is the design “as simple as possible, but no simpler”?
SD-15 Is the design lean? (i.e., are all of its parts strictly necessary?)
SD-16 If part of an evolutionary lifecycle or if change is expected in maintenance, do expected volatile areas of the design support expected changes or refactoring of the design? (e.g., have design for change principles been followed?)
SD-17 Does the design create reusable components if appropriate?
SD-18 Will the design be easy to port to another environment if appropriate?
SD-19 Does the design have low complexity?
SD-20 Is the design intellectually manageable?
SD-21 Is the design robust?

SD-22 Does the design address all issues from the requirements?
SD-23 Does the design add features or functionality, which was not specified by the requirements? (i.e., are all parts of the design traceable back to requirements?)
SD-24 If appropriate has requirements coverage been documented with a completed requirements traceability matrix?

SD-25 Is the level of detail appropriate for this design artifact?
SD-26 Has sufficient detail been included to allow the downstream consumer of the design to produce their artifacts (design, databases, code, test plan, etc.)?

SD-27 Are all of the assumptions, constraints, design decisions, and dependencies documented?
SD-28 Has a risk plan been made for the parts of the design that may not be feasible?
SD-29 Are assumptions made due to missing information been documented?
SD-30 Have all reasonable alternative designs been considered, including not automating some processes in software?
SD-31 Have all goals, tradeoffs, and decisions been described?

SD-32 Is the design consistent with its upstream and downstream artifacts?
SD-33 Does the design adequately address issues that were identified and deferred at previous upstream levels?
SD-34 Have the impacts of all ‘To-Be-Determined’ (TBD) issues in the upstream artifacts been assessed and addressed?
SD-35 Does the design make sense both from the top down and the bottom up? SD-36 Is the design consistent with related artifacts? (i.e. other modules, designs, etc.) SD-37 Is the design consistent with the development and operating environments?

SD-38 Are all performance attributes, assumptions, and constraints clearly defined?
SD-39 If appropriate are there justifications for design performance? (e.g., prototyping critical areas or reusing an existing design proven in the same context)

SD-40 Does the design allow for ease of maintenance?
SD-41 If reusable parts of other designs are being used, has their effect on design and integration been stated?
SD-42 Does the design account for future extensions to the program?
SD-43 Does the design resists erosion in the correctness of its content over time?

SD-44 Does the design follow all standards necessary for the system? (e.g., date standards)