Verification asks whether a realised product conforms to its specified requirements; validation asks whether the right product fulfils stakeholder expectations and works for its intended use in its intended environment. That is the distinction in NASA’s product-verification and product-validation guidance. ECSS-E-ST-10-02C Rev.1 treats space-product validation differently: it is achieved through verification when requirements adequately capture suitability for intended use. A programme must follow its applicable framework and tailoring.
How does NASA distinguish verification from validation?
NASA Product Verification describes verification as showing that an implemented, integrated, bought or reused end product conforms to its requirements or specifications. The approved requirements baseline and its acceptance criteria are central inputs.
NASA Product Validation compares the verified product with stakeholder expectations, measures of effectiveness and the concept of operations. It focuses on intended use and operational environment and calls for anticipated operators or users to participate whenever possible.
| Dimension | Verification | Validation |
|---|---|---|
| Primary question | Does the product conform to specified requirements? | Does the product satisfy stakeholder expectations and intended use? |
| Comparison basis | Approved requirements and specifications | Stakeholder expectations, concept of operations and measures of effectiveness |
| Context | Controlled conditions appropriate to proving conformity | Intended operational environment or a credible representation of it |
| Participants | Qualified engineering and test personnel under the programme plan | Anticipated users or operators whenever practical, with relevant stakeholders |
| Failure may indicate | Product, requirement allocation, procedure, equipment or configuration problem | Product, intended-use, stakeholder-expectation, ConOps or environment problem |
The familiar “built right” and “right product” shorthand is helpful, but it is not enough to plan evidence. The team must identify the exact product configuration, comparison basis, environment, method, procedure, result and approval authority.
How is requirements validation different from product validation?
NASA also uses the word validation during requirements definition. Its Technical Requirements Definition guidance validates requirements against stakeholder expectations, mission objectives and constraints, the concept of operations and mission success criteria. The review asks whether statements are written and technically correct, satisfy stakeholders, are feasible and verifiable, and avoid unnecessary duplication or over-specification.
Requirements validation therefore challenges whether the team has expressed the right problem before committing to a solution. Product validation later examines a realised product against intended use and stakeholder expectations. A team can validate a requirement, verify the implemented product against that requirement and still perform product validation against the wider operational purpose. Name the object being validated whenever the word appears in a plan or status report.
How does the ECSS treatment differ?
ECSS-E-ST-10-02C Rev.1 establishes requirements for verifying space-system products across product levels. Its published scope explicitly says that it does not address validation as a separate space-product process, because product verification is performed against requirements that also address suitability for intended use. On that basis, ECSS says validation is achieved through verification when adequate requirements have been placed on the product.
This is a genuine framework difference, not a reason to relabel NASA records. Under an ECSS-governed programme, follow the applicable verification standard, business agreement and tailoring. Under a NASA-governed programme, preserve the distinct product-verification and product-validation objectives. Where customer and supplier frameworks meet, define the crosswalk in the V&V plan instead of assuming the same word has the same process meaning.
Which methods can provide verification or validation evidence?
NASA’s verification guidance identifies test, analysis, inspection and demonstration as verification methods. Its validation guidance describes the same broad method families for assessing stakeholder expectations. Method labels alone do not determine whether an activity is verification or validation; the objective and comparison basis do.
| Method | Verification use | Validation use | Evidence context to retain |
|---|---|---|---|
| Test | Measure conformity to a specified acceptance criterion | Exercise behaviour against an operational expectation | Article, configuration, environment, procedure, instrumentation, raw result and disposition |
| Analysis | Calculate compliance where direct testing is unsuitable or incomplete | Predict suitability against stakeholder expectations | Model version, inputs, assumptions, validity domain, uncertainty and reviewer |
| Inspection | Examine a physical or documented characteristic | Confirm a feature needed by a user or intended operation | Object inspected, revision, criterion, observer, date and finding |
| Demonstration | Show required functional behaviour without detailed measurement | Show that an operator can achieve an intended outcome | Scenario, user, environment, steps, expected outcome and observed outcome |
A combined activity can support both objectives if it was designed to do so. Record two conclusions: which requirements were verified, and which intended-use expectations were validated. One pass status should not silently stand for both.
How can a spacecraft pass verification but fail validation?
The approved requirement says the safe-mode beacon shall transmit at the specified frequency and minimum power once every minute. A configured flight-like unit passes chamber testing: frequency, transmitted power and interval all meet their acceptance criteria. The requirement is verified.
During a mission-like recovery exercise, the spacecraft enters safe mode at an attitude that places the beacon antenna in a poor ground-station geometry. The recovery team cannot acquire a usable signal within the operational time expected by mission stakeholders. The product meets the written beacon requirement but does not fulfil the intended recovery outcome.
The result does not retroactively turn the verification test into a failure. It exposes a gap between specified requirements and stakeholder intent. The team must assess the ConOps, antenna coverage, link assumptions, recovery expectations and design, then control any requirement or product changes and repeat the affected evidence.
What must a defensible V&V record preserve?
NASA’s verification guidance identifies the product, verification plan, specified requirements baseline and enabling products as key inputs. Its validation reporting guidance calls for the versions of the stakeholder expectations and product, the tools and equipment used, results, outcomes and discrepancies. These details prevent a valid result from being applied to the wrong article or baseline.
- Stable identifiers and versions for the requirement or stakeholder expectation.
- The product, software, model, variant and physical unit configuration assessed.
- The method, level, stage, procedure revision, environment and enabling equipment.
- Acceptance logic, measured or observed results, uncertainty and raw evidence references.
- Anomalies, deviations, assumptions, limitations, reviewer, authority and final disposition.
- Any change that makes earlier evidence suspect, plus the decision to retain, supplement or repeat it.
“Passed” without its object, basis and configuration is not a complete engineering conclusion.
Where can Arc support verification and validation?
Arc’s documented verification and test-management capability connects plans, cases, procedures, configurations, executions, results and evidence to requirements. Its variant and configuration capability can filter applicability and coverage for the selected product or mission configuration.
Arc’s public capability reference does not document test-equipment calibration or physical-test execution. Its verification boundary assigns acceptance criteria, test authority and evidence sufficiency to the customer’s programme; requirements sufficiency and validation participants likewise remain programme decisions. Where NASA and ECSS language differs, Arc should represent the customer’s approved data model rather than collapsing the processes.
What should you read next?
Improve the comparison basis with the guide to writing verifiable spacecraft requirements, keep evidence current with continuous verification for agile hardware, and preserve product applicability with the as-designed, as-built and as-tested guide.
What are the frequently asked questions?
What is the difference between verification and validation in NASA systems engineering?
NASA product verification determines whether an implemented or integrated product conforms to its specified requirements. Product validation determines whether that product fulfils stakeholder expectations and its intended use in the intended operational environment.
Can a space system pass verification but fail validation?
Yes. A system can meet every written requirement yet fail to satisfy an operational need that the requirements did not capture adequately. That outcome can reveal a requirements, concept-of-operations or design deficiency rather than a failed verification activity.
Does ECSS treat validation as a separate product process?
ECSS-E-ST-10-02C Rev.1 does not address space-product validation as a separate process. It states that validation is achieved through verification when adequate requirements address suitability for intended use. Programme tailoring and other applicable documents still control.
Can the same test support verification and validation?
Yes, when its configuration, environment, users, measurements and acceptance logic provide the evidence needed for both objectives. The record should still state separately which specified requirements and stakeholder expectations were assessed.
Who approves verification and validation evidence?
The governing programme defines the responsible technical and customer authorities. Software can organise records and route reviews, but evidence sufficiency, acceptance and closure remain accountable engineering decisions.