3. GuidanceThe basic validation process is shown below with the steps addressed by this requirement highlighted: 
Validation activities are not be confused with verification activities as each has a specific goal. Validation is designed to confirm the right product is being produced while verification is conducted to confirm the product being produced meets the specified requirements correctly. |
Validation, as used in this requirement, addresses the following: - Confirmation of the correctness, completeness, clarity, and consistency of the requirements with stakeholders.
- Confirmation that implied or inherent requirements (e.g., system must do X before Y) are correctly implemented.
See SWE-055 for additional information on requirements validation during the concept, design, coding, and initial testing phases of the software development life cycle. Once the software work products have been integrated into a software system, validation activities are concentrated on systems-level effects, interactions, interfaces, and the overall behavior of the system (i.e., whether the system is providing for and meeting the needs of the customer). This level of validation can be accomplished in either an actual operational environment with the use of the targeted platform, or if this combination is not viable, on a high-fidelity simulator. A high-fidelity simulation typically has the exact processor, processor performance, timing, memory size, and interfaces as the flight unit. The following scenarios provide additional considerations for selection of the most appropriate validation approach at the systems level: - Operational environment demonstrations.
- Running the software in an actual operational environment.
- Using this technique to confirm that implied, derived, and inherent requirements such as "the software will run" are properly fulfilled in the target environment.
- Using this technique to view a system or subsystem as a collected implementation of the requirements and confirm that the software product fulfills its intended purpose, not just individual requirements, but as a collected set of requirements, addressing needs, expected behavior, and functionality.
- Behavior in a simulated environment.
- Running the software in a simulated operational environment.
- Using this technique when running the system in the actual environment is not possible or is impractical (costly).
- Using this technique to view a system or subsystem as a collected implementation of the requirements and confirm that the product fulfills its intended use, not just individual requirements, but as a collected set of requirements, addressing needs, expected behavior, and functionality.
See Lessons Learned for other considerations related to simulated environment validation. |
- Portability requirements may require the software to be run in a variety of platforms.
- Validate portability by running appropriate software and system tests on all the required platforms.
Also, consider user-created operational scenarios, when appropriate. They can be a valuable tool in either simulated or operational environments. Additional guidance related to platform or hi-fidelity simulations may be found in the following related requirements in this Handbook: |