The US Vee-Model was first discussed at a joint conference sponsored by the National Council on Systems Engineering (NCOSE) and American Society for Engineering Management (ASEM) in Chattanooga, TN on October 21–23, 1991. A paper named “The Relationship of System Engineering to the Project Cycle” written by Dr. Kevin Forsberg and Harold Mooz, Co-Principals for the Center for Systems Management, formerly of Cupertino, California, now located in Vienna, Virginia. The paper was also presented at The 12th INTERNET World Congress on Project Management held in Oslo, Norway on June 9–11, 1994.

Both Forsberg and Mooz are involved in the aerospace industry. At the time of the document, Forsberg had 27 years of experience in Applied Research, System Engineering, Program, and Proposal Management, followed by seven years of successful consulting to both government and industry. He received the NASA Public Service Medal for his contributions to the Space Shuttle program. Mooz had 22 years of experience in System Engineering and Program Management, followed by ten years of successful consulting to government and industry. Mooz has won and successfully managed highly reliable, sophisticated satellite programs from inception to operations. It’s a fascinating coincidence that both the German and US V-Models were parented by the aerospace industry.

Forsberg and Mooz believe their Vee-Model addresses the system engineering deficiencies of Linear Waterfall, Modified Waterfall and DOD-STD-2167A, the immediate successor to DOD-STD-2167. They mention Boehm’s Spiral Model in their paper and say, “While Boehm’s spiral representation (Exhibit 4) achieves his objective, the system engineering role is still obscured.” The “(Exhibit 4)” in the quote refers to an image of Boehm’s model reproduced in their document.

As all the other models we’ve discussed thus far, the Vee-Model is Waterfall based with notable exceptions. They said, “In our approach, the technical aspect of the project cycle is envisioned as a “Vee,” starting with User needs on the upper left and ending with a User-validated system on the upper right.” Notice the deliberate use of the word “user” implying end users are involved in all aspects of the development cycle.

The model recognizes the changeability of requirements and provides for the establishment of six baselines: User Requirements Baseline, Concept Baseline, System Performance Baseline, “Design-To” Baseline, “Build-To” Baseline and “As-Built” Baseline. The process is iterative and allows for incremental development and concurrent engineering within any phase until that phase’s stage review. After a stage review successfully completes, a new phase is initiated and the old phase is not revisited as in the Waterfall design. Major emphasis is placed on Verification and Validation activities, risk identification and risk reduction modeling. Verification and validation mean that all requirements are testable and agreed to by the stakeholders. We’ll discuss verification and validation in detail in the requirements chapters.

The Forsberg and Mooz Vee-Model consists of nine phases:

• Understand user requirements, develop system concept and validation plan
• Develop system performance specification and system verification plan
• Expand system performance specification into CI “Design-to” specifications and CI verification plan
• Evolve “Design-to” specifications into “Build-to” documentation and inspection plan
• Fabricate, assemble and code to “Build-to” documentation
• Inspect to “Build-to” documentation
• Assemble CIs and perform CI verification to CI “Design-to” specifications
• Integrate system and perform system verification to performance specification
• Demonstrate and validate system to user validation plan

Much of the risk analysis and concurrent systems engineering occur in “off-core” activities. Forsberg and Mooz said, “While technical feasibility decisions are made in the off-core activities only decisions at the core-level are put under Configuration Management at the various Control Gates. Off-core activities, analyses, and models are performed to substantiate the core decisions and to ensure that risks have been mitigated or determined to be acceptable.”