1. Requirements

3.1.2.2 The project shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products.

1.1 Notes

NPR 7150.2 [NASA Software Engineering Requirements] does not include any notes for this requirement.

1.2 Applicability Across Classes

2. Rationale

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. 

3. Guidance

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" ¹⁵⁷, include:

• "Review project plans, activities, and work products for consistency with requirements and changes made to them." ¹⁵⁷
• "Identify the source of the inconsistency." ¹⁵⁷
• "Identify any changes that should be made to plans and work products resulting from changes to the requirements baseline." ¹⁵⁷

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 SWE-113).

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.

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. The community of practice is encouraged to submit guidance candidates for this paragraph.

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

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." ⁵⁴⁹
• 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 Mars Climate Orbiter (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 ⁵²¹.