I recently began teaching our training courses here at ArgonDigital and one of the topics we cover is validation and verification. In the training, we ask the students to brainstorm what validation and verification are and how they apply to software requirements.

Surprisingly, to me at least, there are many people who think these are the same thing. So, first let’s start with the definitions as they apply to software requirements. Validation is the process by which we determine if we have the right requirements. Do the requirements as written meet the business objectives and solve the business problem? This is done through review with stakeholders to ensure that the requirements meet their needs.

Verification is the process by which we determine if the code written meets the requirements. Was the system/product built correctly according to the requirements specifications? This is usually done through testing, both development and user acceptance testing.

In order to best explain these definitions and many other topics in our course, I like to go back to my engineering roots. When a building or bridge fails and they’re trying to determine the cause of failure, it’s usually one of two things: either the engineer didn’t design it correctly (validation) or the construction company didn’t build the structure to the engineering specifications (verification). To determine which one happened, forensic engineers can look at the design plans, any changes requested in the field and the “As-built” (a final design document stating what the structure was actually built as). Engineering also does this during the design and construction phases; the engineer makes sure that his design meets all the applicable codes, standards and ordinances and the field engineer at the construction site ensures that the construction team is following the engineering specification to the degree allowable (for example, that rebar in concrete is laid at the appropriate intervals or that the right size gussets are used).

In software requirements, we’re not usually looking at this from a forensic perspective, but I like to keep this example in mind when I’m writing requirements. As a business analyst, I’m usually more responsible for the validation of the requirements than the verification, but I always try to keep in mind: if this project fails, will it be my fault for writing the wrong requirements or someone else’s fault for not building the requirements correctly?

Now, I don’t really care what you call each thing- if you call validation verification and verification validation, after all “What’s in a name?”. The important thing thing to remember is that when it comes to making sure that the requirements are written and built correctly, there are two types of checks we need to do- I’m just trying to give some helpful reminders of how to make sure you’ve covered everything!

Stay tuned for Waterfall and Agile- An Engineer’s Perspective.