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. 

Identifying and correcting inconsistencies early and continuously means that a project is more likely to produce a result that satisfies the need for which it was established. Identifying and correcting inconsistencies early rather than later also reduces overall project cost since inconsistencies do not propagate forward in the project life cycle requiring rework.


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. 

At a minimum, project teams need to note which requirements change and where those requirements flow into plans and products so those plans and products can be reconciled with the changed requirements. This needs to be a standard part of the change control process when a change is being evaluated.

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.

Per NASA/SP-2007-6105, NASA Systems Engineering Handbook, "Care should be exercised to ensure that the corrective actions identified to remove validation deficiencies do not conflict with the baselined stakeholder expectations without first coordinating such changes with the appropriate stakeholders."

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.

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:

SWE-053
Manage Requirements Change
SWE-080
Track and Evaluate Changes
SWE-113
SW Change Request/Problem Report



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


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.