This is an example of a product which can be verified and validated.
Intended Use
We validate to confirm the product or system meets the user’s needs and intended use.
To verify something, we must have requirements.
It’s fairly common to have dimensional requirements, functional requirements, safety requirements, etc.
Functional Requirements
The red arrow in the diagram shows that the user need “drives” the functional requirements.
We don’t for example, have a user need / intended use statement that the device has any kind of propulsion system so there is no functional requirement to have a motor or to equip it with paddles.
To verify the requirements, we can measure the dimensions to confirm the dimensional requirements, we can visually inspect (among other methods) that the components (the rope) are provided, and we can throw it in some water to confirm it floats.
User Needs and Intended Use
Validation, though, needs to consider the user needs and intended use.
The red arrow down from the user need to the validation statement indicates that the user needs are what we have to validate, and our validation statement does address the user need / intended use statement.
Obviously, our requirements are severely lacking.
- For whom is the life preserver intended?
- Will it hold an obese person afloat?
- For how long?
- In salt water and fresh water?
- Will the material eventually absorb water and sink?
- Will the rope become untied and fall loose over time or when wet?
- Will the ‘floaty’ material disintegrate over time in hot, humid, salty environmental conditions?
So, as you can see, we clearly have significant requirements gaps in just our single user need statement and our three functional requirements listed.
Once we get our requirements in order, we can both ensure it meets our requirements AND will meet our users’ needs.