Lifecycle Models

## Two questions, not two phases Verification and validation are often taught as two boxes late in a lifecycle diagram, which is the wrong picture. They are two *questions*, and both can be asked at almost any point. The difference is what each one compares the system against. **Verification compares an artefact to a stated intent.** The stated intent is a document, a model, a set of acceptance criteria, an interface agreement, a coding standard — something written down and agreed. Because the reference is written, verification can be delegated, automated and repeated. A review of a requirements document against a template is verification. A static analyser checking a rule set is verification. An automated check asserting that an endpoint returns the documented shape is verification. All of them share one property: **the specification is the oracle** — the thing that decides whether observed behaviour is wrong. **Validation compares a system to a real need.** The reference is not a document but a person, a job to be done, an operating context. Because the reference is not written down, validation cannot be fully automated. It looks like acceptance work with the people who asked for the system, usability observation, piloting with a subset of real traffic, or simply watching how the thing is used once it is live. Validation can discover that a perfectly implemented, perfectly documented behaviour is useless or harmful. ## Why the distinction has teeth The expensive failure mode is a system that passes everything and is still wrong, and it happens whenever the specification itself is the defect. Consider a smart-meter reading feed that ingests half-hourly consumption from roughly 218,400 meters and exposes a history endpoint. The specification says the endpoint returns thirteen months of readings for "the requesting operator's assigned meters". Every verification activity passes: the interface agreement matches the document, the parameter validation matches the document, the retention window is exactly thirteen months, the reviewers signed off because the code does what the page says. Then a field technician is put in front of it during acceptance work and the assumption collapses. Technicians are not assigned meters; they are assigned regions, and a region is resolved at request time from a role attribute that nobody pinned down. The implemented rule is broader than anyone intended, and a technician can pull any household's consumption history — a permission escalation that no verification activity could ever have caught, because the specification never said what "assigned" meant and verification only ever compares the build to the specification. Validation caught it in one session because its reference was a real person doing a real job. The inverse failure is just as real: a team that only validates. If the only evidence is a stakeholder saying "looks right", nothing is repeatable, nothing regresses safely, and the same judgement has to be re-made by hand on every release. ## Where each one shows up in practice - **Static verification** — reviews, walkthroughs, inspections, analysis of specifications, designs and code. No execution needed, and it can start before code exists because it only needs the artefact and its reference. - **Dynamic verification** — executing the system and comparing behaviour to a documented expectation at any level, from a single component up to the assembled system. - **Validation** — user acceptance work, usability observation, piloting, business-facing exploration where the tester's own judgement about fitness is the oracle, and post-release observation of how the system is actually used. A useful test when you cannot tell which one you are doing: **ask what would have to change for the check to become wrong.** If the answer is "the document", it is verification. If the answer is "the users' needs or their context", it is validation. ## Common confusions to avoid Validation is not a synonym for acceptance activity by role; a business analyst reviewing a requirements document against a checklist is verifying. Validation is not necessarily late; showing a rough prototype to a user before any real implementation exists is validation performed early. Verification is not a synonym for automated, and validation is not a synonym for manual — the split is about the reference, not the technique. Finally, both are needed and neither substitutes for the other. Verification without validation ships a faithful implementation of a misunderstanding. Validation without verification ships an opinion that cannot be reproduced next release.