The following guidelines should be heeded when using this inspection checklist during formal or informal inspections of software design documents:
The questions in this section of the checklist help the inspectors to check the software design document for defects in the following areas:
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Single Interpretation: Does every design decision documented in SDD have only a single interpretation that is the same for both those who produce it and those who read it? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Package Designs: Does the SDD document all significant package design decisions? | ||
| Unit Designs: Does the SDD document all significant unit design decisions? | ||
| Thoroughly Documented: Are design decisions for the current release documented as completely and as thoroughly as is known at the present time? Note that information relevant to future releases need not be completely documented. | ||
| Current TBDs: Is the acronym “TBD” used to signify that the associated design decisions have not yet been determined and documented? | ||
| No TBDs at Release: Does the final SDD for a release not contain any “TBDs” for that release? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Upward Consistency: Is the SDD consistent with higher-level documents (e.g., System Requirements Specification, Project Glossary, Domain Object Model, Software Architecture Document)? | ||
| Lateral Consistency: Is the SDD consistent with documents and models at the same level (e.g., Database Design Document, Human Interface Design Document)? | ||
| Internal Consistency: Is the SDD internally consistent in that all design decisions that it contains are compatible? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Organization: Does the SDD have a coherent, easy-to-use organization? | ||
| Redundancy: Are the design decisions neither redundantly stated nor intermingled? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Standards Conformance: Is the SDD verifiable in the sense that its content and format conform to this standard? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Header: Does every page of the SDD contain
a header with the following information?
- Application Name - Document Title (i.e., “Software Design Document”) - Document Identifier - Document Version Number - Document Version Date |
||
| Footer: Does every page of the SDD contain
a footer with the following information?
- Distribution type (e.g., “Public”, “Confidential”, or “Secret”) - Copyright Notice - Document Page Number |
The questions in this section of the checklist help the inspectors to check for defects in the following areas:
Please answer the questions when inspecting the front matter of the software design document:
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does the title page exist? | ||
| Application Name: Does the title page correctly state the application name? | ||
| Document Type: Does the title page correctly identify the document as a software design document? | ||
| Version Number: Does the title page correctly document the correct version number? | ||
| Customer Organization: Does the title page correctly document the customer organization’s name and address? | ||
| Development Organization: Does the title page correctly document the development organization’s name and address? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does the executive summary exist? | ||
| Correct Level Of Abstraction: Is the executive summary written at the correct level of abstraction? | ||
| Well-Written: Is the executive summary well-written and easy to read? | ||
| Complete: Is the executive summary complete? | ||
| Consistent: Is the executive summary consistent with the rest of the document? | ||
| Up-To-Date: Is the executive summary up-to-date? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does the revision history exist? | ||
| Complete: Is the revision history complete with not any revision entries missing? | ||
| Revision Date: Does every revision entry contain the correct revision date? | ||
| Version Number: Does every revision entry contain the correct version number? | ||
| Adequate Description: Does every revision entry contain an adequate description? | ||
| Author(s): Does every revision entry list the primary revision authors? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does the table of contents exist? | ||
| Correct Level: Does the table of contents go down to the correct level? | ||
| Complete: Are all section or paragraph entries listed? | ||
| Identifier: Does every entry contain the correct section or paragraph identifier? | ||
| Title: Does every entry contain the correct title? | ||
| Page Number: Does every entry contain the correct page number? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does the table of figures exist? | ||
| Complete: Are all figure entries listed | ||
| Identifier: Does every entry contain the correct figure identifier? | ||
| Caption: Does every entry contain the correct figure caption? | ||
| Page Number: Does every entry contain the correct figure page number? |
Please answer the questions when inspecting the introduction section of the software design document:
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does paragraph 1.1 (Definition) of the introduction section exist? | ||
| Identification: Is it properly identified as paragraph 1.1 and titled (Definition)? | ||
| Correct: Is the definition of the document correct? | ||
| Reuse: Does paragraph 1.1 reuse the standard boilerplate definition of a software design document? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does paragraph 1.2 (Objectives) of the introduction section exist? | ||
| Identification: Is it properly identified as paragraph 1.2 and titled (0bjectives)? | ||
| Objectives: Does it provide a list of the software design document’s objectives? | ||
| Complete: Is this list of objectives complete? | ||
| Correct: Are each of the objectives correct? | ||
| Reuse: Does paragraph 1.2 reuse the standard boilerplate objectives? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does paragraph 1.3 (Intended Audiences) of the introduction section exist? | ||
| Identification: Is it properly identified as paragraph 1.3 and titled (Intended Audiences)? | ||
| Intended Audiences: Does it provide a list of the specification’s intended audiences? | ||
| Roles: Is this list of intended audiences complete in terms of roles? | ||
| Teams: Is this list of intended audiences complete in terms of teams? | ||
| Organizations: Is this list of intended audiences complete in terms of organizations? | ||
| Correct: Are each of the intended audiences correct? | ||
| Reuse: Does paragraph 1.3 reuse the standard boilerplate list of intended audiences? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does paragraph 1.4 (References) of the introduction section exist? | ||
| Identification: Is it properly identified as paragraph 1.4 and titled (References)? | ||
| References: Does it provide a list of the software design document’s references? | ||
| Customer Documentation: Is this list of references complete in terms of customer organization doumentation? | ||
| Third-Party Documentation: Is this list of references complete in terms of third-party doumentation? | ||
| Development Organization Documentation: Is this list of references complete in terms of development organization doumentation? | ||
| Correct: Is this list of references correct? | ||
| Reuse: Does paragraph 1.4 reuse the standard boilerplate list of development organization references? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does paragraph 1.5 (Document Overview) of the introduction section exist? | ||
| Identification: Is it properly identified as paragraph 1.5 and titled (Document Overview)? | ||
| Complete: Does it describe each major section of the software design document? | ||
| Correct: Are these descriptions correct summaries of the associated sections? | ||
| Reuse: Does paragraph 1.5 reuse the standard boilerplate section descriptions? | ||
| Well-Written: Is the document overview well-written and easy to read? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does section 2 (Package Design) exist? | ||
| Name: Is it properly identified as section 2 and titled (Package Design)? | ||
| Purpose: Does it summarize the purpose of the package design section? | ||
| Completeness: Is it complete in that it lists all packages? | ||
| Coupling: Is the overall decomposition of the software component into packages one that minimizes package to package coupling? Are the dependencies between the packages consistent with the dependencies between their component units and packages? | ||
| Size: Is the total number of packages proportional to the size and complexity of the associated application or component? Is the total number of packages proportional to the total number of units they contain? | ||
| Disjointness: Are the packages disjoint in that they do not redundantly have the same purpose and responsibilities and do not implement the same services? | ||
| Well-Written: Is the package design section well-written and easy to read? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Package Existence: Does paragraph 2.X (Package Name X) exist for each package? | ||
| Package Name: Is paragraph 2.X properly identified and titled (Package Name X)? Is the name of the package clearly descriptive in that it captures the package’s purpose, abstraction, and the role that it plays within the software architecture? Does the name of the package follow standard package naming conventions? Is the name of the package unique within the scope of the software design document? | ||
| Package Purpose: Is the purpose and abstraction of the package properly documented? Is the purpose of the package consistent with and implied by its name? Is the package cohesive in terms of having a single abstraction? | ||
| Package Responsibilities: Are the responsibilities of the package properly documented? Is the package cohesive in terms of having a cohesive set of responsibilities? Is the set of package responsibilities consistent with the responsibilities of its component units and packages? Is each responsibility consistent with the name of the package? Is each responsibility consistent with the purpose (abstraction) of the package? Are all package responsibilities at the same design level of abstraction? | ||
| Requirements: Are the collaborating contents of the package able to fulfill all requirements allocated to it? Does this include functional, data, quality, and API requirements? Does the package comply with all design constraints? | ||
| Package-Level Interfaces: Does the package have well-defined interface(s)? If the package has multiple interfaces, is each one cohesive in that it provides a cohesive set of services? Is the package loosly coupled with other packages? Are the internal contents of the package more tightly coupled to each other than they are to the contents of other external packages? Are the visibilities of these contents properly identified? Is information hiding (encapsulation) maximized? | ||
| Package Contents: Are all contents of the package (e.g., classes, packages, procedures) properly listed? Is the package cohesive in terms of its contents? Are all of the components of the package needed to fulfill its responsibilities? | ||
| Package Size: Does the package contain a reasonable number of components? Note that too many or too few components may imply that the package should be decomposed or merged with another package. | ||
| Package Feasibility: Is the package feasible to implement given current resources including staffing, schedule, and technology? | ||
| Package Diagrams: Do adequate static and dynamic diagrams (e.g., class diagrams, collaboration diagrams, sequence diagrams, state transition diagrams) exist that properly document the structure and behavior of the package? Are these diagrams syntactically correct? Are these diagrams up-to-date? | ||
| State Machine: If the package has a state machine, is the state machine consistent with the package responsibilities, interfaces, and contents? Is the state machine as simple as practical with no extraneous states or transitions? Are all state and transition names understandable and unique within the state machine? Are all referenced objects visible to the class? Have composite states been used where appropriate to simplify the state machine? | ||
| Well-Written: Is the package X paragraph well-written and easy to read? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Unit Existence: Does paragraph 2.X.Y (Unit Name Y) exist inside paragraph 2.X for each unit contained within the corresponding package? | ||
| Unit Name: Is paragraph 2.X.Y properly identified and titled (Unit Name Y)? Does the name of the unit clearly descriptive in that it captures the unit’s purpose, abstraction, and the role that it plays within the package? Does the name of the unit follow standard naming conventions by using the correct part of speech (e.g., singular noun or noun phrase for a class, active verb or verb phrase for a procedure)? Is the name of the unit unique within the scope of its name space (e.g., enclosing package or software component)? | ||
| Unit Purpose: Is the purpose and abstraction of the unit properly documented? Is the purpose of the unit consistent with and implied by its name? Is the unit cohesive in terms of having a single abstraction? Does the unit have the correct kinds of abstraction (e.g., object abstaction for a class, functional abstraction for a procedure)? | ||
| Unit Responsibilities: Are the responsibilities of the unit properly documented? Is the unit cohesive in terms of having a cohesive set of responsibilities? Is each responsibility consistent with the name of the unit? Is each responsibility consistent with the purpose (abstraction) of the unit? Are all unit responsibilities at the same design level of abstraction? | ||
| Requirements: Are the collaborating contents of the unit able to fulfill all requirements allocated to it? Does this include functional, data, quality, and API requirements? Does the unit comply with all design constraints? | ||
| Unit-Level Interfaces: Does the unit have well-defined interface(s)? If the unit has multiple interfaces, is each one cohesive in that it provides a cohesive set of services? Is the package loosly coupled with other packages? Are the internal contents of the unit more tightly coupled to each other than they are to the contents of other external units? Are the visibilities of these contents properly identified? Is information hiding (encapsulation) maximized? | ||
| Inheritance: Are inheritance relationships properly documented? Is inheritance only used to capture generalization/specialization relationships and design abstractions rather than implementation details? Are subclasses and subtypes clearly distinct from their superclasses and supertypes? Are inheritance hierarchies balanced, being neither too flat or too deep? | ||
| Association: Are all association relationships properly documented including multiplicity? Are different types of relationships (e.g., simple association aggregation, collection, membership) clearly differentiated? | ||
| Disjointness: Are the units disjoint in that they do not redundantly have the same purpose and responsibilities and do not implement the same services? | ||
| Unit Contents: Are all contents of the unit (e.g., for classes: attributes, methods, and exceptions) properly documented? Are all of the elements of the unit needed to fulfill its responsibilities? | ||
| - Class Attributes: Is every attribute documented with name, type, and visibility? | ||
| - Class Invariants: Are all invariants (if any) properly documented? | ||
| - Class Methods: Are all methods properly documented including name, purpose, signature, preconditions and postconditions, and structure (if appropriate)? Are method signature parameters properly documented including names, types, range restrictions (if any), and data flow (in, out, in/out)? Are method signature exceptions properly documented? Are method signatures consistent with the syntax of the target programming languages? Is the method structure (e.g., PDL) properly documented for all large and complex methods? Are the methods cohesive, modular, and of correct size? Is the behavior of the class completely described by it methods descriptions (e.g., purpose and assertions)? | ||
| - Class Exceptions: Are all exceptions properly documented including name, abstraction, type, direction (raised or handled)? Are all exception handlers properly documented? | ||
| Unit Size: Does the unit contain a reasonable number of components? Note that too many or too few components may imply that the unit should be decomposed or merged with another unit. | ||
| Unit Feasibility: Is the unit feasible to implement given current resources including staffing, schedule, and technology? | ||
| Unit Diagrams: Do adequate static and dynamic diagrams (e.g., class diagrams, collaboration diagrams, sequence diagrams, state transition diagrams) exist that properly document the unit’s structure and behavior? Are these diagrams syntactically correct? Are these diagrams up-to-date? | ||
| State Machine: If the unit has a state machine, is the state machine consistent with the unit responsibilities, interfaces, and contents (e.g., attributes and methods)? Is the state machine as simple as practical with no extraneous states or transitions? Are all state and transition names understandable and unique within the state machine? Are all referenced objects visible to the class? Have composite states been used where appropriate to simplify the state machine? | ||
| Well-Written: Is the unit X Y paragraph well-written and easy to read? |
The software design document shall contain a section labeled “ Appendices” that provides the following ancillary information:
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does appendix A (Open Issues) exist? | ||
| Identification: Is it properly identified as Appendix A and titled (Open Issues)? | ||
| Complete: Does it list all major open issues to be resolved? Is each open issue adequately documented to be understood and dealt with? If no open issues exist, does it clearly say so? | ||
| Relevant: Is each open issue significant and relevant? | ||
| Well-Written: Is the open issues appendix well-written and easy to read? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does appendix B (Major Things To Be Done) exist? | ||
| Identification: Is it properly identified as Appendix B and titled (Major Things To Be Done)? | ||
| Complete: Does it list all significant TBDs concerning drive package and unit design? | ||
| Relevant: Does each TBD list the packages and units it impacts? | ||
| Well-Written: Is the TBD appendix well-written and easy to read? |
| Inspection Questions | Yes
(Pass) |
No
(Fail) |
|---|---|---|
| Existence: Does appendix C (Assumptions) exist? | ||
| Identification: Is it properly identified as Appendix C and titled (Assumptions)? | ||
| Complete: Does it list all significant assumptions that drive package and unit design? | ||
| Relevant: Does each assumption list the packages and units it impacts? | ||
| Well-Written: Is the assumptions appendix well-written and easy to read? |