3. GuidanceThe basic verification process is shown below with the steps addressed by this requirement highlighted: 
The following list provides examples of information typically captured in the verification results, analysis results, or in the post-analysis documentation of those results. Center procedures may call for additional items, or additional information may be needed to document fully the result or identified issue. Note that problem tracking or corrective action tools may capture some of this information automatically. - A full identification of the system and the software, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s)
- An assessment of the manner in which the verification environment may be different from the operational environment and the effect of this difference on the results.
- The results of the verification activity, including all verified requirements. The summary includes information on the requirements evaluated, (if tested, the success of the test), and references to any problems or deviations.
- An overall assessment of the software performance and quality as demonstrated by the results in this report.
- A list of any deficiencies, limitations, or constraints that were detected; problem or change reports may be used to provide deficiency information. (e.g., a description of the impact on software and system performance, the impact a correction would have on software, system design, and associated documentation, and recommendations for correcting the deficiency, limitation, or constraint).
The results, and the verification activities and verified products that generated them, can be recorded in the following ways, as appropriate for the method used: - Verification reports.
- Review meeting minutes/reports.
- Review Item Dispositions (RIDs).
- As-run test logs.
- Demonstration results.
- Analysis reports.
- User group reports.
- Conduct peer reviews.
- Analyze peer review results.
- Issue tracking system.
- Change requests/change request system.
The Tools section lists several examples of templates for this type of document. See SWE-028 and the Note in SDP-SMP for information on what verification includes. See Software Test Report for information on software test reporting. See SWE-031 for related information on reporting validation results that may be helpful here. When analyzing verification results to determine whether those results support a conclusion that the software satisfies the specified requirements, consider the following steps: - Compare actual to expected results.
- Identify discrepancies or mismatches in specification or behavior.
- Document discrepancies individually for ease of tracking through the resolution process.
- Determine cause of the issue, including problems with the verification methods, criteria, or environment.
- Identify the changes required to address discrepancies.
- Evaluate and record the impact of changes needed to correct issues/discrepancies.
- Plan for any repeat of verification effort (See SWE-028)
- Obtain and record approval for changes to be made to the current project versus those to be addressed at a different time as part of a general process improvement activity.
- Measure and predict quality of the software based on the verification results (typically, a software assurance activity).
When tracking discrepancies to closure, consider the following activities: - Capture the changes to be made (change requests, corrective actions, review item dispositions (RID), etc.).
- Carry out the approved changes to be made.
- Follow chosen solution to completion, including any verification activities necessary to confirm the issue has been resolved.
- Obtain and record approval for issue close-out.
Center or project procedures may require additional documentation not described above. |