Wat is het verschil tussen een systems engineering plan en een V-model?

One Systems Engineering Plan and the V-model are two fundamentally different things: the Systems Engineering Plan (SEP) is a management document that describes how systems engineering within a project is carried out, while the V-model is a process chart that visualizes the logical order of development and verification. The SEP is the What and who, the V-model is the when and in what order. In this article, we answer the most frequently asked questions about both concepts and show how they complement each other in practice.

What does a systems engineering plan describe exactly?

A Systems Engineering Plan is a project-specific management document that defines how systems engineering will be applied within a particular project or program. It describes the approach, roles, responsibilities, methods, and tooling that the project team will use to manage requirements, structure the design, and perform verification.

Specifically, a SEP typically includes the following elements:

The scope and objectives of systems engineering activities
The methodology and frameworks used, such as INCOSE or the SE Guideline
Roles and responsibilities within the team
The method for requirements management and traceability
The approach for verification and validation
The tools and systems that are used
The link with project planning and milestones

The SEP is therefore not a theoretical model, but a living document that is kept up-to-date throughout the project. It is the link between the organizational strategy and the daily execution of systems engineering activities. Without an SEP, the shared basis on which a team can coordinate its work is missing, which in practice leads to inconsistent working methods and loss of traceability.

The V-model precisely describes

The V-model is a process model that depicts the development cycle of a system as a V-shape. The left side of the V describes the breakdown of system requirements into subsystems and components, while the right side describes the corresponding verification and validation steps performed in reverse order. Each level on the left side has a directly corresponding testing step on the right side.

The strength of the V-model lies in the explicit coupling between specification and verification. The moment you formulate a system-level requirement, you simultaneously define how you will later verify that requirement. This prevents the classic pitfall where verification criteria are only conceived at the end of a project, when changes are expensive and time-consuming.

The V-model is widely applicable and is frequently used in Dutch practice within civil engineering, the maritime sector, and the public sector. It offers a recognizable structure that project teams, clients, and auditors can understand collectively, regardless of the specific project content.

What is the fundamental difference between the two?

The fundamental difference is that the V-model is a Universal process model and is a systems engineering plan Project-specific management document. The V-model describes the logical order of activities that recur in virtually every systems engineering project. The SEP describes how your team, in your project, concretely performs those activities.

A useful analogy: the V-model is the roadmap of the process, the SEP is the team's travel plan. The roadmap is the same for everyone, but each team makes its own plan based on who is traveling, what resources are available, and what circumstances apply.

This also leads to a practical difference in use:

Use the V-model to structure the process and communicate with all stakeholders.
The SEP is used to record agreements, assign responsibilities, and secure working methods.
The V-model hardly changes per project; the SEP is always project-specific.
The V-model is a visual tool; the SEP is a formal document

Can an SEP and the V-model be used together?

Yes, and in practice, they should be used together. A good Systems Engineering Plan explicitly refers to the V-model as the process model used and then describes how the project organization concretely implements the steps from that model. The V-model provides the structure, the SEP provides the elaboration.

In practice, this works as follows: the SEP describes, for example, that verification takes place through inspections, analyses, and tests, and specifies who is responsible for this and at what point in the project. The V-model makes visible at which level in the system hierarchy that verification step belongs. Together, they form a coherent whole that covers both the method and the execution.

It's a common mistake to treat the V-model as a replacement for a SEP. Organizations that only use the V-model without an accompanying SEP have a process structure but lack the project-specific agreements needed to make that structure actually work.

When is the V-model sufficient and when do you need a SEP?

The V-model suffices as a communication tool in early project phases or for simple projects where the methodology is already widely known and shared. As soon as a project involves multiple parties, complex requirement structures, or formal handover obligations, a fully developed systems engineering plan is indispensable.

A few guidelines for practice:

V-model sufficient internal projects with a small, experienced team that shares the same workflow and for which no formal accountability to a client is required
SEP required: projects with multiple contracting parties, projects where a client requires demonstrable application of systems engineering, or projects where knowledge transfer is a formal obligation at the end
SEP highly recommended: Projects where the requirements structure frequently changes, where traceability from requirement to evidence is audited later, or where new team members need to be quickly onboarded

In the Dutch infrastructure and water sectors, a SEP is almost always a contractual obligation for larger projects. The maritime and public sectors are also increasingly requesting a demonstrable systems engineering approach, where the SEP is the central proof that this approach has actually been implemented.

What tools support a SEP and the V-model in practice?

The most commonly used tools for systems engineering are specialized platforms for requirements management, modeling, and traceability. In practice, however, teams often get stuck with expensive or complex tooling like IBM DOORS or Cameo Systems Modeler, which don't always align with the scale or budget of the project.

A SEP imposes requirements on the tooling a team chooses: the tools must support traceability, facilitate collaboration, and align with the verification structure prescribed by the V-model. In practice, this means you need an environment where you can define requirements, link them to design elements, and record verification evidence.

Met Datastorms bieden wij een no-code informatieplatform waarmee systems engineers precies dit kunnen doen: eisen definiëren, traceability vastleggen, verificatiematrices genereren en de samenhang tussen systemen en deelsystemen bewaken gedurende de hele projectlevenscyclus. Het platform is gebouwd vanuit jarenlange praktijkervaring in de Nederlandse infra-, water- en maakindustrie, sluit aan op bestaande werkwijzen en integreert via een uitgebreide API met tools die al in gebruik zijn. Zo ondersteunt het zowel de uitvoering van het SEP als de verificatiestructuur van het V-model, zonder de complexiteit of de kosten van traditionele MBSE-tooling. Wil je zelf ervaren hoe het platform werkt? Vraag een proeflicentie aan en ontdek wat Datastorms voor jouw project kan betekenen.

Frequently Asked Questions

How do I start creating a systems engineering plan if I have no prior experience?

A good starting point is to consult existing frameworks such as the INCOSE Systems Engineering Handbook or the Dutch Guideline SE, both of which provide templates and guidelines for setting up an SEP. Start with the core components: scope, roles and responsibilities, and the approach to requirements management and verification. Gradually complete the document as the project progresses—an SEP does not need to be complete all at once, but it must be kept up-to-date from the beginning.

What are the most common mistakes when applying the V-model in practice?

The most common mistake is treating the V-model as a strict waterfall: teams go through the left side completely before thinking about the right side, while verification criteria should be defined concurrently with the requirements. Another common mistake is applying the V-model to only one system level, whereas the model is intended to structure the entire hierarchy from system to component. Therefore, ensure that each requirements level has a corresponding verification step, even before design begins.

How detailed should a SEP be for a medium-sized project?

Een SEP voor een middelgroot project hoeft niet omvangrijk te zijn, maar moet wel volledig zijn op de punten die voor dat project kritiek zijn: duidelijke rollen, een beschreven aanpak voor traceability en een vastgelegde verificatiestrategie. Een document van tien tot twintig pagina’s is voor de meeste middelgrote projecten voldoende, mits het concreet en projectspecifiek is in plaats van generiek en theoretisch. Vermijd de valkuil van een te uitgebreid SEP dat vervolgens niet wordt onderhouden — een beknopt maar levend document heeft meer waarde dan een uitgebreid document dat na de kick-off in de la verdwijnt.

Can I combine the V-model with agile or iterative methodologies?

Ja, het V-model en agile werkwijzen sluiten elkaar niet uit, mits je het V-model toepast op het juiste abstractieniveau. Op systeemniveau biedt het V-model de overkoepelende verificatiestructuur, terwijl op component- of softwareniveau iteratieve sprints kunnen worden toegepast. In de praktijk wordt dit vaak aangeduid als ‘V-model in het groot, agile in het klein’, waarbij het SEP beschrijft hoe beide werkwijzen binnen het project op elkaar worden afgestemd en waar de formele verificatiemomenten liggen.

Who is responsible for managing and keeping the SEP up-to-date during a project?

The responsibility for the SEP typically lies with the project's systems engineer or lead systems engineer, but the document is a shared responsibility of the entire project team. In practice, it is wise to specify within the SEP itself who manages the document, at what points it will be reviewed—for example, at milestones or significant scope changes—and how changes will be communicated to all stakeholders. Without a designated owner and a clear revision process, an SEP quickly becomes outdated and loses its value as a guiding document.

How do I ensure good traceability between requirements, design, and verification without drowning in administration?

The key is to set up traceability as a structured process from the beginning, not as an add-on activity. Use a tool or platform that automatically tracks traceability based on the links you establish between requirements, design elements, and verification evidence, so you don't have to maintain a separate log. Additionally, ensure the SEP describes the required level of traceability—not every requirement needs the same depth—and adopt a consistent format for requirement identification to keep links unambiguous and traceable throughout the entire project lifecycle.

What is the difference between verification and validation within the V-model, and why is that distinction important?

Verificatie beantwoordt de vraag ‘hebben we het systeem goed gebouwd?’ — met andere woorden: voldoet het systeem aan de gespecificeerde eisen? Validatie beantwoordt de vraag ‘hebben we het goede systeem gebouwd?’ — voldoet het systeem aan de werkelijke behoefte van de gebruiker of opdrachtgever? In het V-model vindt verificatie plaats op elk niveau van de hiërarchie, terwijl validatie plaatsvindt op het hoogste niveau, aan het einde van de rechterzijde van de V. Het onderscheid is cruciaal omdat een systeem technisch correct kan voldoen aan alle eisen, maar toch niet aansluiten bij wat de opdrachtgever daadwerkelijk nodig heeft — een risico dat alleen door expliciete validatie wordt ondervangen.

What is the difference between a systems engineering plan and a V-model?