What are the key components of the V-model in systems engineering?

I don’t think that System Requirements should be described as “the first component of the V model” Following ISO/IEC/IEEE 15288, there are two other technical processes (Mission/Business Analysys; Stakeholder Needs & Requirements Definition) that are more prevalent in the begining of system’s life cycle and give importants inputs to the System Requirements Definition Process. That said, it is important to keep in mind that all the life cycle process are more or less active thoughout the whole system’s life cycle.

In order to achieve succeed on this first component, the responsible for gathering customer/stakeholder needs, elicitation, analyze and state the requirements should have carved in his mind the position of voice of customer. Through the requirements statement and prioritizing, this person will dictate the strategy and the pace of the upcoming phases. That said, it is easy to see that flaws in system requirement components can put in jeopardy all the upcoming phases. So, understanding internal processes, the customer business combined with communication and negotiation skills can make the difference not only to system requirements but all components of vee structures.

Using the V for more than 3 decades the in my opinion main misunderstanding is: The V is interpreted as a sequence of tasks. No it is not. The V organizes work products, relates the work products. If you take a look at the V-Modell XT v1.0 specification: it defines a component based and an agile approach beside some others. Both approaches differ in the order the tasks are performed. I personally do not separate the tasks to write requirements and to create a system architecture. I personally view textual requirements and architecture as complementary. Adding a new system element to the architecture implies new requirements to be stated. New requirements imply new mappings to the architecture and may require the definition of new elements.

Verification is always represented on the right “arm” of the vee, having an important horizontal connection with the system requirements against which the system should be verified. It is a must that the system is verified before being put into operation. It is important to keep in mind that, as it happens with all the other technical life cycle processes (ISO/IEC/IEEE 15288), the verification process is active during the whole system’s life cycle, having peaks of activity during certains periods.

As mentioned before as well here after the V-Modell does not define a sequence of tasks. The test procedures shall be written as soon as the according requirement is defined. I view writing test procedures as an implicit review of the requirements. If a sane test procedure can be written the requirement is testable. Another benefit is, the above approach enables TDD (test driven development).

Whenever possible, agile frameworks tools and techniques can be used to help keeping under control risks of the system life cycle. Using them, it is possible to keep people involved and informed, hold a periodic and scientific fashion of requirements and strategy reviews to make sure decisions made in the past remain accurate, ensuring the system to be put in operation meets customer and other stakeholders expectation.

The vee model is a nice representation of the progression of technical processes through the system’s life cycle. There are many variants of the vee model out there, but a distinctive and important aspect that is always present is the relationship between the “arms” of the vee. Here is the basic idea: 1- You need to consider what is going to happen on the right arm while doing the activities of the left arm; and 2 - You need to look back to what was done on the left arm while doing the activities of the right arm.

Using the V for more than 3 decades the in my opinion main misunderstanding is: The V is interpreted as a sequence of tasks. No it is not. The V organizes work products, relates the work products. If you take a look at the V-Modell XT v1.0 specification: it defines a component based and an agile approach beside some others. Both approaches differ in the order the tasks are performed. Yes, the V model described the agile approach back in 2002 ??