Overview
In this activity, the software developer analyzes the allocated system and derived software requirements to determine which may be high-risk or needing corrective action. A high-risk requirement may be impossible or especially difficult to fulfill, may severely compromise the usability or performance of the software, or may impact the software development schedule and cost.
Roles and Responsibilities
The software developer reviews all software requirements as they are identified to determine which ones are high-risk or in need of corrective action.
Controls
The project-level Configuration Management (CM) Plan (CMP) that documents the change control process for system-level documentation.
Inputs
The allocated computer software configuration item (CSCI) requirements, as listed in the inspected system design, which may take the form of a MIL-STD 498 System/Subsystem Design Description (SSDD) or other equivalent system documentation (see activity 3.1.2 Define System Design).
The object-oriented software requirements derived from allocated CSCI requirements (see activity 3.2.1.1.2 Perform Object-Oriented Requirements Analysis).
The external interface requirements derived from CSCI requirements (see activity 3.2.1.1.3 Develop External Interface Requirements Specifications).
Procedures
This activity focuses on analyzing the system requirements allocated to the CSCI, as documented in the SSDD and those software requirements derived from the system requirements. The analysis concentrates on identifying requirements deficiencies that may put the software project at risk of not meeting those requirements.
A requirement is: 1) a condition or capability needed by a user to solve a problem or achieve an objective, or 2) a condition or capability that must be met or possessed by a system or system component (e.g., a CSCI) to satisfy a contract, standard, specification, or other formally-imposed document. Risk is defined as the likelihood of an undesirable event occurring, and the severity of the consequences of the occurrence [NHB 7120.5, 1993].
The following steps may be performed concurrently with those in activities 3.2.1.1.2 Perform Object-Oriented Requirements Analysis and 3.2.1.1.3 Develop External Interface Requirements Specifications. This activity should not be considered complete until these two activities are concluded and the resulting requirements are analyzed for risk.
1) The software developer examines the allocated system and software requirements to identify any deficiencies. A valid requirement is precise, free of unnecessary design, traceable, and testable. It is important to stress that a valid requirement does not make unnecessary assumptions about the system architecture, hardware, software, or any other design or implementation issue.
A valid requirement has the following 10 basic characteristics:
Unambiguous.
Technically consistent.
Consistent terminology and logic.
Free of undefined terms and acronyms.
Contains specific cross-references.
Free of unnecessary design and implementation (except in special cases).
Traceable to a high-level requirement.
Verifiable (by demonstration, test, analysis, or inspection).
Correct.
A requirement that is faulty in one or more of the characteristics listed above is an invalid requirement. The software developer analyzes the deficiency for potential risk or corrective action. If the software developer finds deficiencies as listed in the MIL-STD-498 System/Subsystem Specification (SSS) (see Appendix E) or SSDD or other equivalent system documentation, a Configuration Change Request (CCR) is completed and submitted to the project-level CM organization according to the project-level CM Plan (CMP). However, because the MIL-STD-498 Software Requirements Specification (SRS) (see Appendix E) is not baselined at this development stage, the software developer may correct/change invalid SRS requirements without management authorization (see activities 3.2.1.1.2 Perform Object-Oriented Requirements Analysis and 3.2.1.1.3 Develop External Interface Requirements Specifications).
The software developer must identify deficiencies in both the system and software requirements. Consequently, step 1 includes two substeps.
A) The software developer reviews the allocated CSCI requirements. During this review, the software developer identifies as high-risk any requirement failing to meet the characteristics of a valid requirement and any interface requirement (i.e., governing communication with external hardware components or other CSCIs) that are under development or classified as "TBD."
B) The software developer identifies deficiencies or high risks in the software requirements being derived. The software developer reviews the intermediate and final results of activities 3.2.1.1.2 Perform Object-Oriented Requirements Analysis and 3.2.1.1.3 Develop External Interface Requirements Specifications, and identifies as high-risk any requirement failing to meet the characteristics of a valid requirement or any requirement that can be described as follows:
Any requirement involving external interfaces that are poorly defined or inadequately understood (e.g., unfamiliar external devices).
Any requirement involving a state in which the output values, error conditions, or internal behaviors are unknown or poorly defined.
Any requirement that may cause scheduling problems (these problems are discovered during the analysis that determines whether system activities will occur on schedule).
Any requirements whose properties may be difficult to satisfy (e.g., extremely tight memory constraints).
2) From the list compiled in step 1, the software developer documents each high-risk requirement identified during this activity, clearly indicates why each is a high-risk requirement, and identifies any recommended solutions. The software developer submits these high-risk requirements to the project software manager for evaluation. The software developer also may suggest developing prototype versions of potentially high-risk software areas. Partially designing and coding these risky areas may yield information that leads to corrective actions. If appropriate, the software developer suggests corrective actions for each high-risk requirement identified, such as begin prototyping to verify the feasibility of the requirement.
Outputs
High-risk requirements submitted for management review.
CCRs submitted to the project-level CM organization.
Invalid requirements which must be rewritten.