The V-model is a visual shorthand for disciplined, top-down system development followed by bottom-up proof. On the left-hand leg you start with fuzzy stakeholder pains, sharpen them into measurable system requirements, and then decompose those requirements through progressively finer architectural layers until you reach code or hardware drawings.
The bottom point (unit implementation) is where abstraction is lowest and component isolation is highest. The right-hand leg then climbs back upward, but in reverse order: unit tests prove each block, component integration proves every interface, and finally system‐level validation proves that the finished artefact solves the original pain.
Two principles make the diagram more than just a pretty shape:
Because of those principles, teams can localise defects, predict schedules, and justify design trade-offs with cold data instead of hope.
Part 1 captures the left-hand descent of the V-model. It frames the stakeholder pains, distils them into SMART requirements, and surveys the trade space, always with a kitchen-table verification plan in view. If you are new to SE, think of Part 1 as the theory section: why clarity of need, aggressive measurability, and early test hooks save months of rework down the line.
Part 2 pivots to design: a tri-view architecture (functional, physical, software) that shows, line-by-line, how each requirement is realised and how every design choice earns its keep. You will see control loops mapped to tasks, latency budgets split across hops, and even a "budget" analogue FPV link added when risk analysis exposed Wi-Fi's soft underbelly. In short, Part 2 is the climb up the right-hand side of the V, still on paper but already instrumented for proof.
Will there be a Part 3 with hardware photos and skid-marks on the parking lot? Not soon, I make no promise. Another project already competes for bench time. For now, treat this series as a reference walk-through.
© 2025 Victor Retamal - Project Notes.