A Software Specification Review (SSR) is conducted for each Computer Software Configuration Item (CSCI) after the System Functional Review (SFR), but prior to the initiation of preliminary design for the individual CSCI. The SSR is part of the overall systems engineering process of allocating and formally defining requirements and must occur after the system/subsystem level hardware/software allocation decisions have been made and the related designs have been completed. The SSR is normally held early in the Technology Development (TD) Phase. Emphasis is on demonstrating the adequacy of the internal development baselines. The SRR establishes the allocated developmental baseline for the CSCI. [1]

Tasks accomplished during the SSR include: [1]

• Ensuring the SRS performance requirements are feasible, complete, and consistent with the higher-level specification requirements (establish traceability).
• Ensuring all derived requirements have been identified and documented.
• Ensuring the requirements as stated are testable and measurable.
• Ensuring there are complete verifiable requirements for all performance requirements
• Evaluating reserve capacity requirements and scenarios / procedures for measurement.
• Evaluating agreements on interfaces and boundaries.
• Evaluating results of functional analyses.
• Evaluating requirements allocation decisions.
• Evaluating identified software risks and proposed mitigation methods.
• Evaluating proposed top level software architecture.
• Evaluating trade studies and feasibility analyses.
• Evaluating applicable design constraints.
• Evaluating applicable human factors considerations.
• Examining the proposed software development processes.
• Examining baseline control and configuration management processes.

The main exit criteria of the review are: [1]

• Subsystem and functional issues have been resolved.
• Computer software subsystem requirements are traceable to higher-level requirements.
• A requirements traceability matrix has been developed identifying how the requirements will be tested
• The internal development baselines are established.
• The software and interface requirements are allocated to CSCIs and CSCs.
• CS&S risks (including those related to cost, schedule, and performance) have been identified and mitigation plans have been developed.
• Risks are acceptable and the software development risk management process is defined and integrated with the system risk management process.
• Software development schedules, down to and including the software work package schedules, reflect and accommodate contractor selected processes and defined Integrated Master Plan (IMP) events.
• Required software integration and test tools and facilities are defined.
• Methods are defined to manage and control the growth of the software during the development phase. ·         Metrics to be used by the developer are defined and implemented where applicable.
• The S/SEE requirements are defined.

AcqLinks and References:

• [1] USAF Weapon Systems Software Management Guidebook – Appendix F
• Mil-STD-498 “Software Development and Documentation” – 5 Dec 1994
• MIL-STD-498 “Application and Reference Guidebook” – 3 Jan 1996
• Software Development Plan Information Outline
• Template: Software Development Plan – SPAWAR
• Website: MIL-STD-498 Software Documentation

Update: 7/28/2021

Rank: G1