3.4.3 The project shall ensure that the implementation of each software requirement is verified to the requirement. NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement. Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement. Class A_SC A_NSC B_SC B_NSC C_SC C_NSC D_SC D_NSC E_SC E_NSC F G H Applicable? P(C) Key: A_SC = Class A Software, Safety-Critical | A_NSC = Class A Software, Not 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 contracted provider of software. To ensure that the resulting product was "built right" (addresses the need, provides the specified behavior, and performs within the stated constraints), the implementation (code) of those requirements needs to be verified against the requirements. Verification activities are not to be confused with validation activities as each has a specific goal. Verification is designed to confirm the product is being produced correctly while validation is designed to confirm the right system is being produced. Specific to a software project's implementation, verification involves confirming that the implementation (code) correctly, completely, consistently, and accurately includes each software requirement. Verification methods can include testing, analysis, demonstration, and inspection. Confirmation of software requirements implementation needs to occur at various times in the project life cycle to ensure that any issues are found and corrected as early as possible: Verification of requirements implementation includes the following objectives: While the primary means of implementation verification is testing, the following analysis techniques are also useful (Software Development Process Description Document 001, Revision R). Note that these techniques are useful for detecting coding problems/issues and may not necessarily be required for verifying that the software properly implements the requirements unless the requirements include statements related to the complexity, memory usage, coding standards, etc. Requirements implementation verification activities need to be planned and documented (SWE-104) and verification techniques can be included in the bidirectional requirements traceability matrix (SWE-072) to ensure that all requirements are verified in the implementation. Results of this activity are to be documented (SWE-069), evaluated (SWE-068), and defects corrected. Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to implementation verification. Additional guidance related to software testing, including specifics of plan, procedure, and report contents may be found in the following related requirements in this handbook: Small projects with few personnel could use a single document to describe the verification procedure as well as the test results rather than have the overhead of using separate documents. Small projects with few requirements may combine verification planning, the traceability matrix, and verification results into one product, rather than separate documents. This document may look like a verification matrix that identifies the requirements, type of verification for each requirement, any required tools, personnel, and/or environment needed for the verification, and the final results. The key for this requirement is to ensure the final product meets the content of the stated software requirements. 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. No Lessons Learned have currently been identified for this requirement.
View this section on the website
See edit history of this section
Post feedback on this section
1. Requirements
1.1 Implementation Notes from Appendix D
1.2 Applicability Across Classes
- Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures2. Rationale
3. Guidance
4. Small Projects
5. Resources
5.1 Tools
6. Lessons Learned
SWE-067 - Verify Implementation
Web Resources
Unknown macro: {page-info}
The NASA Independent Verification and Validation Technical Framework (IVV 09-1) document 003 states that "It is important to recognize that requirements cannot be evaluated in isolation. Requirements must be evaluated as a set in order to determine that a particular goal or behavior is being met."
