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:
Manage Requirements Change
Track and Evaluate Changes
SW Change Request/Problem Report