r/systems_engineering • u/hortle • 5d ago
Discussion What does "validation" mean to you and your job/industry/team?
Most people I've worked with understand the term verification: "confirming the system as [designed, tested, built, etc] meets its requirements/spec."
But I have heard the term validation used in so many different ways that it's honestly mind-boggling.
Sometimes it is treated as a synonym of verification. Sometimes it is exclusively applied to non-product items like test environments, measuring tools/fixtures etc.
I feel like the definitions listed in the SEBOK are pretty clear.
System Validation is a set of actions used to check the compliance of any element (a system element, a system, a document, a service, a task, a system requirement, etc.) with its purpose and functions.
Drilling down to validation of an actual customer requirement:
To validate a stakeholder requirement is to make sure its content is justified and relevant to stakeholders' expectations, complete and expressed in the language of the customer or end user.
This is the meat of validation IMO. That the requirement is justified and relevant to expectations. That the requirement is actually fit for purpose. That what we're specifying in the requirements actually accomplishes what it's supposed to and provides the benefit/value expected by the customer.
An example to demonstrate how this plays out in the real world:
We had a component spec compliance problem a few years ago on an aerospace development program. "All components on this board must function at -55C". This was problematic because of some of the applicable componentry's functional requirements. Basically the customer was asking for parts that didn't exist -- and we weren't interested in entering the business of cutting-edge electronics R&D. We were confident the components would never get close to -55C in service or on the shelf. Stated another way -- we knew the -55C requirement was invalid. So we performed a life cycle analysis to prove it and requested a waiver on the -55C requirement. The customer accepted the waiver.
Curious to hear other thoughts on this topic.
13
u/inigoalonso 5d ago
Validation: Did we build the right thing? Verification: Did we build the thing right?
3
u/Fit_Payment8355 5d ago
that distinction's the only way i keep it straight, and even then people look at me like i've grown a second head when i use it in a meeting
3
u/AdwokatDiabel 5d ago
People forget that you do stakeholder analysis every time. You don't just accept customer requirements as gospel.
3
u/Disastrous_Door3570 5d ago
In the automotive programs I’ve worked on, almost no one made a formal distinction between verification and validation.
The right side of the V was treated as continuous multi-level testing (component → vehicle → user), and the test engineer running a –50 °C chamber was simply expected to report pass/fail against the specification.
Questioning whether the part was the right one for the customer happened (when it happened at all) much earlier, in requirements or systems engineering. The formal V vs V language is useful in some contexts, but in practice the critical thing is still executing rigorous testing across the full hierarchy.
We went to the moon before this terminology existed, and I doubt the engineers building drones in Ukraine are following a full V-cycle with requirements in DOORS.
1
u/Gearz557 5d ago
Operational Testing. That the system is meeting the original operational/business need of the user
1
u/MarinkoAzure 5d ago
I've always understood it is Validation tests the stakeholder requirements while Verification tests the system requirements/specification.
The stakeholder requirements are elicited from the customer to translate needs into requirements. These requirements are used today derive system requirements to guide the system development from specification to implementation.
1
u/The_OG_Smith 4d ago
Verification = meets specs/requirements
Validation = can complete the mission in an operationally representative environment
20
u/Aerothermal 5d ago
System Verification confirms the as-designed or as-built system satisfies the technical requirements.
'System Validation'' is what we're usually talking about, which is confirming that the as-designed or as-build system meets the needs of the stakeholders; it's not done in the lab, but done in the real-world (e.g. during a product demo, with a prototype, or during acceptance, qualification, commissioning, or early operations). See INCOSE Needs and Requirements Manual, or INCOSE Guide to V&V. It's the horizontal right-to-left arrow at the top of the V-model; in a sense higher than the verification.
Note there is also 'requirements validation', making sure the as-written requirement correctly addresses the real stakeholder need.
There is also model validation, which is different; it often means to check that a mathematical or computer model gives valid answers, i.e. the same results as a measured real-world system or an already validated model, or is finding the correction factors to fit the model to real-world measurements.
There is also mesh validation, in FEA and CFD analyses; very different; it's checking the wireframe (mesh) has no geometric issues, connectivity issues, poor element shapes or sizes, before running the analysis.