Overview
Formally inspecting the system design documentation is a means of finding and eliminating defects in the current version of the MIL-STD 498 System/Subsystem Design Description (SSDD) (see Appendix E) or equivalent system documentation. The formal inspection process is documented in the Instructional Handbook for Formal Inspections. In this activity, a formal inspection on the system design documentation is performed.
Roles and Responsibilities
The project manager assigns individuals to the inspection team, which should consist of members from each discipline (e.g., hardware, software, optics).
The inspection team conducts the formal inspection.
Controls
The Instructional Handbook for Formal Inspections documenting the formal inspection process.
Inputs
The SSDD or other equivalent system design documentation. This includes: the subsystem definitions and requirements (see activity 3.1.2.1 Identify Subsystems), subsystem interfaces (see activity 3.1.2.2 Define Interfaces Among Subsystems), operational scenarios (see activity 3.1.2.3 Generate Subsystem Operational Scenarios), data dictionary, and the trace matrix mapping the scenarios to the system/subsystem requirements.
Procedures
The SSDD should meet all inspection entrance criteria. A spell check should be done on the documentation, and level checking should be done if a computer-aided software engineering (CASE) tool was used. This material may vary depending on the project, but should include all subsystem descriptions and allocated requirements, documentation describing the information flows between subsystems, subsystem operational scenarios, the trace matrix mapping scenarios to system and subsystem requirements, and the trace matrix mapping system requirements to subsystems.
1) The project manager should select the individuals who will take part in formally inspecting the system design. Selecting the inspection team is discussed in the Planning Stage section of the Instructional Handbook for Formal Inspections (also see Appendix E of the handbook for a list of expected participants for each inspection type).
2) The formal inspection is conducted as documented in the Instructional Handbook for Formal Inspections. In addition to the items on the "Functional Design Checklist" in the Instructional Handbook for Formal Inspections, the following items must be verified:
Are all subsystems decomposed to a level where their functionality is well defined?
Are all requirements allocated to the subsystems verifiable?
Have all subsystems or components necessary to operate, develop, process post mission data, and test the system been defined?
Have all inputs and their sources been identified for each subsystem?
Have all outputs and their destinations been identified for each subsystem?
Have all input and outputs for each subsystem been documented in the data dictionary?
Have the bus, amount of data to be sent, and required rate of throughput for all subsystem interfaces been identified and documented?
Have scenarios been developed covering all possible commands for each subsystem?
Do any scenarios end in situations where no other scenario can be started?
Does any scenario begin with an input from another subsystem that is not produced in another scenario?
Is the terminology consistent throughout the design documentation?
Do scenarios cover all normal and error situations that can occur?
3) All errors found during the formal inspection should be documented on a defect list and tracked until closure. The system design documentation is then corrected and, if necessary, re-inspected. Once all errors are corrected, the system design documentation is said to be "inspection certified", and is submitted to the project-level software configuration management (CM) organization for control.
Outputs
The inspected system design may take the form of an SSDD or equivalent system design documentation, and be submitted to the project-level CM organization.
The defect list documenting the defects found during the formal inspection.