Systems engineering training and consulting
Portuguese Chinese


By Robert J. Halligan FIE Aust CPEng

Project Performance International Pty Ltd P.O Box 2385
Ringwood North Vic 3134 Australia
Ph: 61-3-9876-7345 email:

For a PDF version of this article, please click here


The Vee Model, first defined by Rook in 1986, has served well as a depiction of design of non-trivial systems through physical levels of solution description on the left-hand side of the Vee, and physical realization of system elements, together with their integration to create higher physical level system elements, on the right-hand side of the Vee. The Vee model has commonly shown verification of system elements on the right-hand side, against requirements for each element on the left. Whilst valuable, this depiction is a very limited representation of the reality of development of non-trivial systems. The Wedge ModelTM extends the basic Vee model to incorporate verification and validation of requirements, design, system elements and system, within a multiple-build development strategy.


The Wedge Model™ is a derivative of the well-known Vee Model (Rook, 1986). The Wedge Model™ shows the products of design on the left-hand side of the wedge, and system integration on the right-hand side, with verification (is the work product correct with respect to the inputs used to create it – usually “meets requirements”?) and validation (does the work product correspond to the need for the work product?) superimposed. Colloquially, verification is – have we done the job right, and validation is – have we done the right job?

The Wedge Model™ shows multiple builds in the third dimension – a second time axis with time coming out of the page towards the reader. Thus, the face of the Wedge represents the last build (version, release, etc.) in each case. All of the verification and validation concerns on the face are replicated back onto the earlier builds. Note that not all potential verifications and validations will be carried out on all of the products associated with all of the builds. It is an engineering management role to decide which of the products will be subject to verification and validation, and to what degree.


A description of the model follows. Verification is shown in red. Validation is shown in blue. The subjects of verification and validation are at the arrow tails. The references for verification and validation are at the arrow heads.
































































































































































The “Vee” model is sometimes misunderstood to be a development model, and a time-sequential Waterfall development model at that. This is not the case. The original “Vee” represents the end products on the design and build sides of the “Vee”, but says almost nothing about how the developer got there. The Wedge Model™ adds some of the story as to how the developer got there, but only insofar as intermediate design artifacts and corresponding intermediate builds. There are time trends, but no strict time axes, even for incremental and evolutionary builds. These could be sequential or partly concurrent on each side of the Wedge. The timing dependencies are finishing, not starting or doing (we have to have finished building the engine before we can finish building the propulsion system).

A “Project System” invariably appears at Level 2 in the Wedge Model™. The Project System has system elements, and lower physical level system elements, and lower again, and again, down to, for example, individual test procedures and emails. Each subject to the same principles verification and validation principles and relationships.


The Wedge Model™ provides a comprehensive representation of the end products and intermediate products within the development of larger, more complex systems, together with the superimposition of the subjects of verification and validation, the references for verification and validation, and representative methods of verification and validation, within both single build and multiple build development strategies for the system itself and for each developmental system element.


Forsberg, K., and Mooz, H. “The relationship of systems engineering to the project cycle”. Engineering Management Journal Vol. 4, No. 3, 1992, pp. 36-43.

Rook, Paul. “Controlling Software Projects” in Software Engineering Journal (Vol 1, No 1, pp. 7-10, January 1986, ISSN 0268-6961.