This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C
188.8.131.52 The project manager shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 Applicability Across Classes
If Class D software is safety critical, this requirement applies to the safety-critical aspects of the software.
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.
Requirements are the basis for a project. They identify the need to be addressed, the behavior of the system, and the constraints under which the problem is to be solved. They also specify the product to be delivered by a provider of software. Software project plans describe how the project will create a software product that fulfills those requirements. Any inconsistencies among these three - requirements, project plans, and software products – will most likely result in a product that does not meet its requirements. Corrective actions address not only new or changed requirements, but also failures and defects in the work products (requirements, project plans, and software products). Corrective actions need to be analyzed to determine the impact that the change will have on the work product, related work products, budget and schedule. Corrective actions need to be tracked until closure to ensure decisions regarding the closure of those actions are followed through and to prevent the problems described in those corrective actions from propagating through the project or recurring.
Typically, the corrective action process is described in a plan, such as the software development or software management plan (SDP/SMP) or the software quality assurance plan (SQAP). Follow this documented process to capture and track to closure inconsistencies among requirements, plans, and software products.
A recommended practice for this requirement is that all corrective actions be formally submitted descriptions of the desired modifications to work products. If corrective actions are not documented consistently, they are difficult to analyze and track. A database provides a flexible environment for storing and tracking corrective actions.
Identify inconsistencies among requirements, project plans, and software products
Suggested activities to identify inconsistencies and "ensure that project plans and work products remain aligned with requirements" 157, include:
- "Review project plans, activities, and work products for consistency with requirements and changes made to them." 157
- "Identify the source of the inconsistency." 157
- "Identify any changes that should be made to plans and work products resulting from changes to the requirements baseline." 157
When looking for inconsistencies, consider these "warning signs" or potential causes:
- Unstable requirements.
- Unclear, incomplete, inconsistent, non-cohesive requirements.
- Incomplete project plans or plans developed before requirements stabilize.
- Budgetary issues that result in changes to staff and/or the requirements.
- Inadequate communications among development team, management, customers, contractors, other stakeholders.
- Inadequate change or configuration management procedures.
- Inexperienced staff.
- Personnel turnover.
Inconsistencies among plans, requirements and the resulting software products need to be identified throughout the project life cycle. One way to ensure this activity is not forgotten is to conduct periodic reviews of requirements against project plans and software products.
Initiate corrective actions and track until closure
Before corrective action can be taken, consider performing analysis to identify and weigh options when the corrective action is not readily apparent. This analysis could be similar to that used for change requests and problem reports (see Change Requests/Problem Reports).
Sample corrective actions include:
- Split development into multiple releases, addressing unstable requirements later.
- Use more experienced or senior personnel.
- Stabilize project personnel, i.e., reduce turnover.
- Audit project processes and act on the findings.
To initiate corrective actions and track them to closure, consider the following for implementation on the project:
- A system or process for entering and tracking corrective actions (e.g., Problem Report and Corrective Action (PRACA), change request/problem reporting system or tool).
- A corrective action review process, typically involving a review panel or board including engineers and assurance personnel (e.g., Configuration Control Board (CCB)).
- A corrective action implementation process.
- A time frame for resolution (i.e., number of days or weeks).
- An escalation procedure (e.g., report to Project Manager (PM)).
- A procedure to archive actions and conclusions for reference, input to future projects.
NASA users should consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to corrective actions and inconsistencies among project plans, requirements, and software products.
Additional guidance related to reporting and tracking corrective actions to closure may be found in the following related requirement in this handbook:
4. Small Projects
No additional guidance is available for small projects.
- CMMI Development Team (2010). "CMMI for Development, Version 1.3: Improving processes for developing better products and services,"CMMI Development Team (2010). CMU/SEI-2010-TR-033, Software Engineering Institute.
Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.
No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.
6. Lessons Learned
The NASA Lessons Learned database contains the following lessons learned related to ensuring plans and products remain aligned with requirements:
- Risk Assessment in Software Development Projects (Uncertainty caused by changing requirements.) Lesson Number 1321: "Even with expert and experienced programmers, each new software program presents new technical challenges. Changing methodology and requirements during the design phase of a software project adds uncertainty to the project." 549
- Deficiencies in Mission Critical Software Development for Mars Climate Orbiter (1999) (Inconsistency led to loss of mission.) Lesson Number 0740: "The root cause of the MCO mission loss was an error in the "Sm_forces" program output files, which were delivered to the navigation team in English units (pounds-force seconds) instead of the specified metric units (Newton-seconds). Comply with preferred software review practices, identify software that is mission critical (for which staff must participate in major design reviews, walk throughs and review of acceptance test results), train personnel in software walk throughs, and verify consistent engineering units on all parameters 521.