In the V-model, how does each specification stage pair with a verification level?
answer
- A folded sequence, not a straight line
- Partners face each other across the shape
- Each level checks its own document
- Design checks when the document exists
- The document is assumed correct
basics
~20 sThe V-model bends the sequence into a V. Each specification stage on the descending arm has a partner verification level at the same height on the ascending arm, and that stage's document is the source for the checks performed at its partner level.
solid answer
~50 sThe V-model draws the lifecycle as a descending arm of specification stages and an ascending arm of verification levels, with partners facing each other across the V. User needs pair with acceptance-level checking, the system specification pairs with system-level checking, the architecture or high-level design pairs with integration-level checking, and the detailed component design pairs with component-level checking. The pairing carries two claims. First, **each level's oracle comes from its partner document** — you check integration against the interfaces the architecture promised, not against the component design. Second, **the checks at a level can be designed as soon as its partner document exists**, long before there is code to run them on, which is the model's real contribution. The assumption underneath is that each document is complete and stable enough to design against; where that fails, so does the pairing.
go deeper
Be able to draw the shape and name the partner of each specification stage. Say plainly that the left arm produces the documents the right arm checks against, and do not stop at listing the four levels.
Explain the mechanics: each level's oracle is its partner artefact, and checks can be designed the moment that artefact exists rather than after code lands. Be ready to place a given defect at the correct height.
Demonstrate what you do when the assumption fails — documents that are ambiguous, incomplete or revised mid-flight — and how you keep the pairing useful when work arrives in increments rather than in stages.
Own the tradeoff between a model that gives every artefact a verifying level and one that gives fast feedback. Be able to argue where the pairing still earns its keep in your organisation and where it has become ceremony.
## The shape and what it asserts The V-model takes a sequence of lifecycle stages and folds it in the middle, so that the specification stages descend the left arm, implementation sits at the point of the V, and verification levels ascend the right arm. Two stages that face each other across the V are **partners**. The conventional pairing, from the top down: | Left arm (specification) | Right arm (verification level) | | --- | --- | | User needs / business requirements | Acceptance-level checking | | System specification (functional and quality attributes) | System-level checking | | Architecture / high-level design | Integration-level checking | | Component / detailed design | Component-level checking | Exact stage names vary between formulations, and some variants add or split a level. What does not vary is the assertion the diagram makes, which is the part interviewers are listening for. ## Assertion one: the partner document is the oracle Each verification level checks the system against **its own partner artefact**, not against whatever documentation is nearest to hand. Integration-level checking asks whether the parts interact the way the architecture promised — the interfaces, the sequencing, the ownership of data. System-level checking asks whether the assembled system does what the system specification stated, including quality attributes. Acceptance-level checking asks whether the delivered system satisfies the needs that started the whole thing. This matters in practice because it tells you where a defect belongs. If a component behaves exactly as its detailed design says but the composed flow is wrong, the defect is in the architecture or in a misunderstanding at that height — you do not fix it by adding more component-level checks. The pairing gives a defect a home. ## Assertion two: verification design starts with the document, not the code The more useful claim is temporal. Because the right arm's checks derive from the left arm's documents, the checks at a level can be **designed** as soon as its partner document exists. Acceptance-level checks can be drafted while the user needs are being written; integration-level checks can be drafted from the architecture, months before anything is assembled. Execution still needs code, but design does not, and the design work is where most of the value is: writing the checks against a fresh document is the fastest way to discover that the document is ambiguous, contradictory or untestable. This is why the V-model is not simply a picture of a sequential delivery. Even where work is delivered incrementally, the artefact-to-level pairing still tells you what verifies what and what evidence a given level can legitimately produce. ## The assumption underneath The V-model rests on an assumption it does not state: **each stage's document is complete, correct and stable enough to design checks against.** Three things follow when it is not. First, a defect in the document is invisible. The partner level compares the build to the document, so if the document is wrong the level cheerfully passes. Take a smart-meter reading feed whose system specification says the consumption-history endpoint serves "the requesting operator's assigned meters". System-level checking verified exactly that sentence and passed. Nobody had defined "assigned", the implementation resolved it through a role attribute that covered a whole region, and a field technician could read any household's history — a permission escalation that sat comfortably inside the specification the level was checking against. The V-model's pairing cannot catch a defect whose home is the artefact it treats as truth; only reviewing the document itself, or validating against a real user, can. Second, if the document keeps moving, checks designed against it decay. On a 3-week release train, an architecture that is revised twice per train leaves integration-level checks encoding interfaces that no longer exist, and the level starts producing failures that are about the checks rather than about the system. Third, the diagram implies that a level's evidence arrives after implementation, and teams read that as permission to leave all verification design until then. That is a misreading of the model, but it is the most common one, and it is worth naming in an interview because it shows you understand the model rather than the picture. ## Answering it well Name the pairs, state that the partner document is the oracle for its level, state that check design can begin when that document exists, and then name the assumption and one way it breaks. Reciting four pairs alone reads as memorised; the assumption is what distinguishes a middle answer from a junior one.
- Which V-model pairing owns a defect where every component matches its detailed design but the assembled flow is wrong?The architecture and its partner integration level. Component-level checking has done its job — each part matches its detailed design — so adding more of it finds nothing. The wrong behaviour lives in how the parts were composed, which means either the architecture described the wrong interaction or the implementation did not honour it. Locating the defect at the right height matters because it decides which document has to change and which level's checks need extending.
- Does the V-model require that all specification is finished before any implementation starts?The picture suggests it, but the useful content of the model does not. What the model actually asserts is a pairing between an artefact and the level that verifies it, plus the point that a level's checks can be designed from its partner document. That pairing holds just as well when a small slice of user need, specification, design and code moves through together. Teams that apply the model per increment keep the diagnostic value of the pairing without the assumption that everything is settled up front.
- What does the V-model say about validation?Very little, and that is a fair criticism of it. The right arm is dominated by verification against left-arm documents, with only the top pairing reaching towards real user needs. Because every level treats its partner artefact as the oracle, a need that was never captured correctly passes all the way up. Teams using the model in earnest add explicit validation activity — early examples with users, prototypes, observation of live use — rather than assuming the acceptance level covers it.
Think of the V as a set of mirrors: every promise you write on the way down has exactly one mirror on the way up that asks whether the promise was kept.
saying these in an interview costs you the question
- Recites the four pairs with no idea what the pairing asserts
- Says verification work can only start after coding finishes
- Checks a level against whichever document is handiest
- Claims the model guarantees complete requirements coverage
- Cannot name any assumption the model depends on
- Treats the diagram as a mandatory project schedule