You link verification to your systems engineering plan by explicitly recording for each requirement which verification method is applied, who is responsible for it, and when the proof is delivered. You do this via a verification matrix that you create as soon as the requirements are defined and that you keep up-to-date throughout the entire project. The sections below go into more detail on the building blocks of that approach.
What is the difference between verification and validation in systems engineering?
Verification answers the question “Are we building the system right?” — it tests whether the system meets the specified requirements. Validation answers the question “Are we building the right system?” — it tests whether the system does what the client actually needs in the operational context. Both are indispensable in a systems engineering plan, but they occur at different times and with different methods.
In practice, confusion between these two concepts regularly leads to problems. A system can technically meet all requirements and still not deliver the desired result, simply because the requirements were incomplete or incorrectly formulated. Verification therefore always works against the stated requirements; validation works against the needs of the user or client.
Within a systems engineering plan, verification and validation are planned separately. Verification is typically more objective and can be performed earlier in the process because it can be directly tested against measurable specifications. Validation often requires a more complete version of the system and end-user involvement. Both activities deserve their own place in your planning, with their own responsibilities and acceptance criteria.
What verification methods are distinguished in a SE plan?
A systems engineering plan typically distinguishes four verification methods: inspection, analysis, demonstration, and test. Each method is suitable for a different type of requirement and carries a different burden of proof. The choice of the correct method per requirement is a deliberate decision that you record in your verification matrix.
- Inspection Visual or documentary inspection without active system use. Suitable for requirements regarding material use, dimensions, or documentation itself.
- Analyze Arithmetical or model testing, for example via simulations, calculations, or models. Useful when testing is too expensive or physically impossible.
- Demonstration The system is shown in operation without detailed measurement. Suitable for functional requirements where the outcome is visible and unambiguous.
- Test: Controlled measurement under defined conditions, with recorded measured values as proof. The most formal method, suitable for quantitative performance requirements.
When preparing your systems engineering plan, it is wise to choose the most proportional method for each requirement. Not every requirement justifies a full test; sometimes an analysis or inspection is sufficient. By making this explicit, you prevent discussions during audits and keep the verification burden manageable.
What does a verification matrix look like in practice?
A verification matrix is a table that links each requirement to a verification method, a responsible party, an execution timing, and the status of the evidence. In its simplest form, each row contains one requirement and each column contains an attribute of the verification approach. The matrix is the central instrument for ensuring traceability from requirement to evidence.
A practical verification matrix must contain at least the following columns:
- Item number and description
- Verification method (inspection, analysis, demonstration, or test)
- Responsible party or discipline
- Verification moment or milestone
- Proof document or reference
- Status (planned, in progress, completed, rejected)
In practice, a verification matrix grows with the project. Start with a concise version based on the initial set of requirements and expand it as the design becomes more concrete. A common mistake is to create the matrix late in the project, which results in verification activities not being scheduled and evidence having to be collected retroactively. This causes stress during audits and handovers.
When do you set up the verification approach in the SE process?
You develop the verification approach as soon as the first version of the requirements set is available, typically during the project's definition phase. You do not wait until the design is ready, because the verification approach itself influences design choices and planning decisions. A verification matrix is a living document that you continuously update.
Within the systems engineering process, this aligns with the logical sequence: define requirements, determine verification approach, develop design, execute verification. By defining the verification approach early, you can influence in a timely manner what test facilities are needed, what documentation must be maintained, and who bears which responsibility.
In de praktijk wordt dit moment te vaak uitgesteld. Teams werken eerst het ontwerp uit en bedenken daarna hoe ze gaan aantonen dat het klopt. Dat leidt tot verificatiemethoden die niet meer passen bij het ontwerp, of tot bewijs dat achteraf niet aantoonbaar is. Door de verificatieaanpak als vast onderdeel van je Systems Engineering Plan te behandelen, voorkom je deze valkuil.
Which tools support the link between requirements and verification?
Tools that support the link between requirements and verification offer, at a minimum, the ability to register requirements, assign verification methods, and track the status of evidence in one central environment. The quality of the tool lies not in its complexity, but in the traceability it enables.
Traditionally, teams work with Excel spreadsheets and Word documents. This is understandable, but it has a fundamental disadvantage: traceability is manual and prone to errors. As soon as a requirement changes, you have to manually check all linked verification activities. This is a time-consuming and risky exercise during audits or project transfers.
Gespecialiseerde platforms zoals DOORS of Cameo bieden meer structuur, maar zijn voor veel teams te duur of te complex. Wij ontwikkelden Datastorms specifiek als toegankelijk alternatief: een no-code informatieplatform waarmee je eisen definieert, traceability vastlegt en verificatiematrices genereert binnen één centrale omgeving. Het platform is gebouwd vanuit praktijkervaring in de Nederlandse infra-, water- en maakindustrie en sluit aan op bestaande werkwijzen zonder een volledige toolwisseling te vereisen. Wil je zien hoe dit in de praktijk werkt? Vraag een proeflicentie aan en ontdek het zelf.
How do you keep the verification status up-to-date during a project?
You keep the verification status up-to-date by integrating the verification matrix into your regular project rhythm, rather than treating it as a separate document that is updated periodically. This means that status changes are processed immediately as verification activities are performed or completed, and that the matrix is visible to all stakeholders.
A number of practical measures help with this:
- Assign an owner responsible for tracking the verification status for each claim.
- Link verification milestones to your project planning so they are visible in progress reporting.
- Use a central tool or database instead of individual files, so everyone works with the same up-to-date version.
- Discuss outstanding verifications in regular project meetings, not just during audits or handovers.
A verification matrix that is only updated during audits loses its value as a control instrument. Its strength lies in continuous use: if you can see at any time which requirements have not yet been verified and why, you can make timely adjustments. This makes the systems engineering plan not just a document for the client, but a working instrument for the project team.
Frequently Asked Questions
How detailed should a verification matrix be for a small project?
For smaller projects, a verification matrix doesn't need to be extensive — a concise table with the six basic columns is sufficient to ensure traceability. It's not about the size of the matrix, but its completeness: each requirement must have at least one verification method and one responsible person. An overly extensive matrix for a small project will cost more time than it yields; keep it proportional to the project's complexity and risk profile.
What do you do if a requirement turns out to be unverifiable afterwards?
If a requirement turns out to be unverifiable, it's a signal that the requirement itself needs to be rephrased—not that the verification approach should be bypassed. A good requirement is always measurable or testable; if that's missing, the requirement is too vaguely or broadly defined. Go back to the requirements set, rephrase the requirement in consultation with the client or user, and document the changed wording, including the verification method, again in your verification matrix.
How do you deal with requirements that are only verifiable late in the project, such as integration tests?
Explicitly include these requirements as 'late verification' in your verification matrix, with a clear milestone and responsible party, so they are not forgotten. Simultaneously, ensure interim analyses or partial tests are conducted early to reduce risks. It is also wise to inform the client early on which requirements will only be verified upon delivery or integration, so this is not a surprise during the final audit.
How do you involve the client in the verification approach without overwhelming them with technical details?
Present the verification approach to the client at the level of milestones and acceptance criteria, not at the level of individual requirements and measurement methods. Show when evidence will be provided, who is responsible for it, and how the client will be involved in validation moments. A clear summary of the verification matrix—for example, per system component or per project phase—is more effective for this than sharing the entire matrix.
A common mistake when assigning verification methods to requirements is not clearly defining the acceptance criteria for each verification method.
A common mistake is to default to assigning 'testing' as the verification method for all requirements without assessing if it's proportionate and feasible. Testing is the most formal and expensive method, and far from always necessary; for many requirements, inspection or analysis is sufficient. By deliberately choosing the method per requirement based on the type of requirement and its associated risk, you can keep the verification burden manageable and prevent unnecessary costs and delays.
How do you ensure that verification activities are actually carried out and don't remain as 'planned'?
Link verification activities to concrete deadlines in the project schedule and assign a responsible person for each activity who can be held accountable for progress. Discuss the status of open verifications in regular project meetings, so it becomes a recurring agenda item and isn't only visible during audits. Also consider incorporating verification milestones as formal go/no-go criteria for the next project phase, providing a concrete incentive to complete them on time.
Can a verification matrix also be used for change management during the project?
Yes, and that is even one of the main applications. When a requirement changes, the verification matrix immediately shows which verification activities need to be reassessed or re-executed. This prevents already completed verifications from becoming invalid without anyone noticing. By combining change management and verification management in the same central environment, you maintain traceability and reduce the risk of unnoticed gaps in your evidence upon delivery.
Related Articles
- Hoe draagt eisenbeheer bij aan een succesvolle oplevering en acceptatie?
- How do you adapt a systems engineering plan when the project scope changes?
- When has a systems engineering plan become too complex?
- How do you make a systems engineering plan?
- What is a realistic time investment for creating a systems engineering plan?