Design Inspection Checklist

design inspection checklist design inspection checklist
  • General Requirements and Design

  • Has review of the design identified problems with the requirements, such as missing requirements, ambiguous requirements, extraneous requirements, untestable requirements, or implied requirements?

  • Is the design consistent with the requirements? For example, are there:  missing functions, extraneous functions,  imprecise, ambiguous, or incorrect functions

  • Are deviations from the requirements documented and approved? 

  • Are all assumptions documented? 

  • Have major design decisions been documented?

  • Is the design consistent with these decisions? 

  • Does the design adequately address the following:  real-time requirements, performance issues (memory and timing), spare capacity (CPU and memory), maintainability,   understandability, database requirements,   loading and initialization, error handling and recovery, user interface issues, software upgrades

  • Functional and Interface Specifications

  • Is the P-spec for each process accurate and complete?

  • Is it specified in precise, unambiguous terms? Does it clearly describe the required transformations? 

  • Are dependencies on other functions, Operating system kernel, hardware, etc., identified and documented? 

  • Are human factors considerations properly addressed in those functions that provide the user interface? 

  • Are design constraints, such as memory and timing budgets, specified where appropriate? 

  • Are requirements for error checking, error handling and recovery specified where needed? 

  • Are interfaces consistent with module usage? Missing interfaces? Extra interfaces? 

  • Are the interfaces specified to a sufficient level of detail that allows them to be verified? 

  • Conventions 

  • Does the design follow the established notation conventions? 

  • Requirements Traceability 

  • Does the detailed design of this module or interface fulfill its part of the requirements?

  • Has the inspection of this module or interface identified problems in the SRS? For example, missing requirements, ambiguous requirements, conflicting requirements, untestable requirements, implied requirements?  

  • Does the detailed design of this module or interface meet its high level design requirements? 

  • Has the inspection of the detailed design identified problems in the high level design? 

  • Are all functions completely and accurately described in sufficient detail? 

  • Are all interfaces completely and accurately described, including keyword or positional parameters, field descriptors, attributes, ranges, and limits? 

  • Are the detailed design documents complete and consistent within themselves; data with logic; all internal data defined; no extraneous data? 

  • Structure and Interfaces 

  • At a system and subsystem level, have all components or modules been identified on a System Architecture Model? 

  • Is the level of decomposition sufficient to identify all modules? 

  • Will further decomposition result in identifying more modules? 

  • Have all interfaces between system/subsystem elements and modules been clearly and precisely identified? 

  • Do successive levels of decomposition result in successive levels of detail? 

  • Are modules performing more than one specific function? 

  • Logic 

  • Are there logic errors?

  • Are... all unique values tested?,  all positional values tested?,  increment and loop counters properly initialized?, variables and data areas initialized before use?

  • Has the module been inspected for... correct begin and end of table processing?, correct processing of queues across interrupts?,   correct decision table logic?,  correct precision/accuracy of calculations?

  • Are message priorities allocated properly to ensure the correct execution of code? 

  • Is the message processing sequence correct? 

  • Are there errors in handling data, data buffers, or tables, incorrect field updated, conflicting use of data areas, incomplete initialization or update, inconsistent or invalid data attributes?

  • Are procedure call and return interfaces correctly defined; Call and return parameters defined correctly; Correct syntax?

  • Performance

  • Are memory and timing budgets reasonable and achievable? 

  • Error Handling and Recovery

  • Is there adequate error condition testing? 

  • Are error conditions tested where the probability of an error is high or results of an error would be fatal to the system? 

  • Are return codes documented?

  • Are return messages understandable? 

  • Does the program allow for successful error recovery...  across module or process failures?, across operating system failure?,  across interrupts?,  across hardware failures?

  • Testability, Extensibility

  • Is the design...   understandable (i.e., easy to read, follow logic)?,   maintainable (i.e., no obscure logic...)?,  testable

  • Coupling and Cohesion 

  • Evaluate the design using the standard coupling and cohesion criteria, if appropriate.

copy saved

copies saved