The V Model — with a Third V for Values
The V model is the oldest answer to a question teams still get wrong: when should tests be designed? Its answer — at the same moment as the specification they check, not after the code exists — remains sound advice in any methodology. This page explains the classic model, then adds a stroke the original never had: a third V for Values, because ethical concerns deserve the same "design the check when you make the decision" treatment as everything else.
The Classic V
Fold the waterfall in half at the coding stage and you get a V [1]. Down the left-hand stroke the problem is decomposed; up the right-hand stroke the solution is recomposed — and each level on the right verifies the corresponding level on the left:
| Left stroke (decide) | Right stroke (check) | The pairing means |
|---|---|---|
| Requirements | Acceptance testing | Acceptance criteria are written with the requirements |
| System design | System testing | System test cases fall out of the design decisions |
| Architecture | Integration testing | Every interface you draw is an integration test you owe |
| Module design | Unit testing | Unit test plans are part of module design, not an afterthought |
How It Works in Practice
- Tests are designed early, run late. The V does not say "test at the end"; it says the thinking about testing happens on the way down. Finding a requirement you cannot write an acceptance test for is the cheapest bug you will ever fix.
- Verification and validation split cleanly. The lower pairings verify ("did we build it right?"); the top pairing validates ("did we build the right thing?").
- It scales down as well as up. The V is drawn for big systems engineering projects, but every agile increment is a miniature V — a story with acceptance criteria (top), a design sketch (middle), and TDD's red-green loop (the point at the bottom; see TDD & BDD).
- Its bad reputation is guilt by association. Applied as a rigid single-pass waterfall it inherits waterfall's problems. Applied as a pairing discipline — no decision without its check — it is compatible with any iteration length. The types of testing map onto its right-hand stroke directly.
The Third V: Values
Here is the addition this page argues for. The classic V pairs every engineering decision with a check — but software also makes ethical decisions at every level, and those usually get neither a decision point nor a check. So: draw a third stroke. At each level of the descent there is a values question to ask, and on the ascent a corresponding values check to run:
Whose interests? Whose risks?"] --> V2["Value requirements:
privacy, fairness, accessibility"] V2 --> V3["Design for values:
data minimisation, transparency"] V3 --> V4["Implementation ethics:
bias in logic, licences, provenance"] end V4 --> VC["Values checks (ascending):
bias & fairness tests → accessibility audit →
privacy/security review → societal impact review"] style VC fill:#C9BEDC
| Level | Engineering question | Engineering check | Values question | Values check |
|---|---|---|---|---|
| Requirements | What should it do? | Acceptance tests | Should it do this? Who benefits, who is exposed? | Societal impact & stakeholder review |
| System design | What are the parts? | System tests | What data do we refuse to collect? Who can be excluded? | Privacy & accessibility audits |
| Architecture | How do parts talk? | Integration tests | Where can decisions be explained, appealed, audited? | Transparency & logging review |
| Module design / code | How does it work? | Unit tests | Are rules biased? Are dependencies legitimate? | Fairness tests, licence checks |
The point of the third stroke is the same as the point of the first two: a concern raised without a paired check evaporates. "We care about fairness" is a poster; "the loan-approval module ships with a fairness test asserting approval-rate parity across protected groups, and the release gate runs it" is engineering. This is precisely the move IEEE 7000 standardises — eliciting stakeholder values early and translating them into traceable value requirements alongside functional ones [2], and it is what professional codes of conduct already oblige individual engineers to do [3].
Making Values Testable
- Phrase value requirements like acceptance criteria. "Given a screen reader user, when they reach checkout, then every control is reachable and labelled" is testable; "the UI should be accessible" is not. The BDD habit transfers directly (see the ethics-adjacent examples in AI Ethics).
- Use measurable proxies, honestly. Fairness metrics, WCAG conformance levels, data-retention maxima — proxies never capture the whole value, so record what each proxy misses and revisit it.
- Put values checks in the pipeline. Accessibility linting, licence scanning and fairness test suites belong in CI next to everything else (see CI/CD's security gates — the values gates sit beside them).
- Keep one question un-automatable. The top of the values stroke — "should this exist, and who says so?" — is answered by humans in a room, on the record. The model's job is to make sure the meeting happens at the top of the project, not after the launch post-mortem (see Professional Ethics).
References
- Forsberg, K. & Mooz, H. (1991). "The Relationship of System Engineering to the Project Cycle." INCOSE International Symposium, 1(1), 57–65. https://doi.org/10.1002/j.2334-5837.1991.tb01484.x
- IEEE (2021). IEEE 7000-2021 — Standard Model Process for Addressing Ethical Concerns during System Design. https://ieeexplore.ieee.org/document/9536679/
- BCS, The Chartered Institute for IT. Code of Conduct. https://www.bcs.org/membership-and-registrations/become-a-member/bcs-code-of-conduct/