Checklist for Requirements Specification Reviews
Organization and Completeness
o
o
o
o
o
o
o
o
Are all internal cross-references to other requirements correct?
Are all requirements written at a consistent and appropriate level of detail?
Do the requirements provide an adequate basis for design?
Is the implementation priority of each requirement included?
Are all external hardware, software, and communication interfaces defined?
Have algorithms intrinsic to the functional requirements been defined?
Does the specification include all of the known customer or system needs?
Is the expected behavior documented for all anticipated error conditions?
Correctness
o
o
o
o
o
o
o
o
Do any requirements conflict with or duplicate other requirements?
Is each requirement written in clear, concise, unambiguous language?
Is each requirement verifiable by testing, demonstration, review, or analysis?
Is each requirement in scope for the project?
Is each requirement free from content and grammatical errors?
Is any necessary information missing from a requirement? If so, is it identified as TBD?
Can all of the requirements be implemented within known constraints?
Are any specified error messages unique and meaningful?
Quality Attributes
o Are all performance objectives properly specified?
o Are all security and safety considerations properly specified?
o Are other pertinent quality attribute goals explicitly documented and quantified, with the acceptable
tradeoffs specified?
Traceability
o Is each requirement uniquely and correctly identified?
o Is each software functional requirement traceable to a higher-level requirement (e.g., system
requirement, use case)?
Special Issues
o Are all requirements actually requirements, not design or implementation solutions?
o Are all time-critical functions identified, and timing criteria specified for them?
o Have internationalization issues been adequately addressed?
Copyright © 2001 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Checklist for Architecture Reviews
Structure
o
o
o
o
o
o
o
Does the architecture allow for implementation of all of the requirements?
Has the architecture been adequately decomposed?
Have the system functions been appropriately allocated to components?
Does the architecture provide an adequate base for subsequent design work?
Is the architecture feasible for implementation?
Have maintainability issues been adequately addressed?
Can the program set be integrated and tested in an incremental fashion?
Correctness
o
o
o
o
o
o
Does the architecture avoid unnecessary redundancy?
Have all reliability and performance requirements been addressed?
Have all security considerations been addressed?
Does the architecture consider all existing constraints?
Are all necessary, and only the necessary, data structures defined?
Will the proposed architecture satisfy all specified quality attributes and performance goals?
Standards and Traceability
o Have all architecture standards been followed?
o Can all parts of the architecture be traced back to requirements?
o Are standard, not proprietary, components being used wherever possible?
Logic
o Is there any missing or incomplete logic?
o Are all possible states or cases considered?
Interfaces
o Are all interfaces clear and well-defined?
o Is the minimum data passed at each interface?
o Is minimum global system data added or impacted?
Clarity
o Is the architecture, including the data flow, control flow, and interfaces, clearly represented?
o Are multiple representations of the design consistent with each other?
o Are all of the decisions, dependencies, and assumptions for this design documented?
Copyright © 2001 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Checklist for High-Level Design Reviews
Structure
o Has the design been decomposed to the point at which the next phase of design can begin?
o Has each component been completely and testably specified?
o Is the modular decomposition consistent with local standards for modular strength and coupling?
Data
o Are global constants and passed data parameterized?
o Has all the data been properly defined?
o Are data structures and element names meaningful and compliant with naming conventions?
Correctness and Completeness
o
o
o
o
o
o
o
o
o
o
o
o
Does the high-level design implement all of the requirements?
Has all of the infrastructure (backup, recovery, checkpoints, etc.) been addressed?
Have all quality attributes and performance requirements been designed?
Have internationalization issues been properly and adequately addressed?
Have processing priorities been addressed?
Have feasibility and economical analyses been done to determine that required performance and
technical goals will be achievable by this design?
Is there a memory budget to allocate estimated storage requirements for each module, table, and file?
Have all security considerations been designed?
Does the high-level design consider all existing constraints?
Does the high-level design contain unnecessary redundancy?
Have maintainability issues been adequately addressed?
Is the high-level design complete, correct, and unambiguous?
Standards and Traceability
o Have all design standards been followed?
o Does the human interface follow project standards?
o Can all parts of the high-level design be traced back to requirements?
Interfaces
o Are all interfaces clear and well-defined?
o Is minimum data passed at each interface?
o Is minimum global system data added or impacted by the design?
Robustness
o Have self-test, fail-safe, and degraded mode requirements been accounted for?
o Has an error handling mechanism been identified?
o Are unusual situations handled reasonably and nondestructively?
Copyright © 2001 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Checklist for Detailed Design Reviews
Structure
o Is the pseudocode or other representation format consistent in its level of detail?
Data
o
o
o
o
Has all the data been properly defined and initialized?
Is all defined data used?
Do the data element names and types conform to the project data dictionary?
Are defaults used, and are they correct?
Correctness and Completeness
o
o
o
o
o
o
o
o
o
o
o
o
o
o
Is the detailed design a complete and accurate implementation of the high-level design?
Are the external specifications of each module complete and testable?
Have all numerical techniques been analyzed for accuracy?
Has critical timing been analyzed?
Has the high-level design memory budget been expanded into further detail and updated?
Are all functions clearly specified and logically independent?
Have maintainability issues been adequately addressed?
Does each module have high internal cohesion?
Does each module have low external coupling?
Is the detailed design verifiable?
Is the logic correct, clear, and complete?
Have all user interfaces been completely designed?
Can the termination conditions for loops be realized?
Can all logic be tested?
Standards and Traceability
o Have all detailed design standards been followed?
o Does the calling protocol follow project standards?
o Can all parts of the detailed design be traced back to the high-level design and to requirements?
Robustness
o Are error conditions handled in a nondestructive manner?
o Can corrective action be taken by the module that traps an error?
o Are unusual conditions handled reasonably and nondestructively?
Copyright © 2001 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Generic Checklist for Code Reviews
Structure
o
o
o
o
o
o
o
o
o
o
Does the code completely and correctly implement the design?
Does the code conform to any pertinent coding standards?
Is the code well-structured, consistent in style, and consistently formatted?
Are there any uncalled or unneeded procedures or any unreachable code?
Are there any leftover stubs or test routines in the code?
Can any code be replaced by calls to external reusable components or library functions?
Are there any blocks of repeated code that could be condensed into a single procedure?
Is storage use efficient?
Are symbolics used rather than “magic number” constants or string constants?
Are any modules excessively complex and should be restructured or split into multiple routines?
Documentation
o Is the code clearly and adequately documented with an easy-to-maintain commenting style?
o Are all comments consistent with the code?
Variables
o Are all variables properly defined with meaningful, consistent, and clear names?
o Do all assigned variables have proper type consistency or casting?
o Are there any redundant or unused variables?
Arithmetic Operations
o
o
o
o
Does the code avoid comparing floating-point numbers for equality?
Does the code systematically prevent rounding errors?
Does the code avoid additions and subtractions on numbers with greatly different magnitudes?
Are divisors tested for zero or noise?
Loops and Branches
o
o
o
o
o
o
o
o
Are all loops, branches, and logic constructs complete, correct, and properly nested?
Are the most common cases tested first in IF- -ELSEIF chains?
Are all cases covered in an IF- -ELSEIF or CASE block, including ELSE or DEFAULT clauses?
Does every case statement have a default?
Are loop termination conditions obvious and invariably achievable?
Are indexes or subscripts properly initialized, just prior to the loop?
Can any statements that are enclosed within loops be placed outside the loops?
Does the code in the loop avoid manipulating the index variable or using it upon exit from the loop?
Defensive Programming
o
o
o
o
o
o
o
o
Are indexes, pointers, and subscripts tested against array, record, or file bounds?
Are imported data and input arguments tested for validity and completeness?
Are all output variables assigned?
Are the correct data operated on in each statement?
Is every memory allocation deallocated?
Are timeouts or error traps used for external device accesses?
Are files checked for existence before attempting to access them?
Are all files and devices are left in the correct state upon program termination?
Copyright © 2001 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Copyright © 2001 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.