The V Model
The V-Model has proven very popular over recent years and has probably replaced the Waterfall Model as the established model of software development. It is interesting to consider that the V-Model could not have existed without the prior experiences gained from usage of the Waterfall Model. If the Waterfall Model is the stern father then the V-Model is the popular son. Delve deeper into its usage and application, however, and one sees that it is not a panacea for all software development ills. Consider the representation of the V-Model below:

The V-Model
You can take the V-Model as a Waterfall Model snapped in the middle and bent upwards. You then have two 'stalks'; in broad terms, the left stalk represents design activities and the right stalk represents test activities. The flow is from the top left point of the 'vee' where the Statement Of the User Propblem (SOUP) is defined, down to the vertex where code is created and unit tested, up to the top right point of the 'vee' where the end-user validates the software against the original needs as defined by the SOUP. Whereas the Waterfall Model represents a series of sequential steps, the V-Model recognises the increasing importance of testing in the lifecycle. Testing, in the form of planning and review of requirement specifications and design specifications, starts right at the beginning of the lifecycle, unlike the older model where test activities are started further down the line .
SOUP & User Acceptance Test Phases
The SOUP differs from the Requirements Specification in that it reflects as true a representation as possible of the 'voice of the customer' It will reflect the language and jargon of the customer. As such, the SOUP does not reflect matured engineering requirements. That work starts in the subsequent phase. Documenting the SOUP is a crucial step not only from a development