A systems engineering plan describes how you perform systems engineering within a project, while a system specification describes what the system must do and what requirements it must meet. Both documents complement each other but have a fundamentally different purpose. In this article, we answer the most frequently asked questions about the difference, coherence, and use of both documents.
What does a systems engineering plan describe exactly?
A Systems Engineering Plan (SEP) is a management document that describes how systems engineering activities on a project will be organized, executed, and monitored. It documents the approach, methods, roles, and responsibilities that the project team will use to manage, verify, and validate system requirements throughout the project lifecycle.
In practice, a systems engineering plan includes, among other things:
- The SE method used and the applicable framework (such as the SE Guideline or INCOSE)
- The structure of claim decomposition and the verification process
- Roles, Responsibilities, and Decision-Making Processes
- The coherence with other project plans and management disciplines
- Agreements on documentation, tooling, and knowledge transfer
The SEP is therefore primarily an internal management document. It provides the project team with guidance and ensures that everyone follows the same methodology. Without a clear Systems Engineering Plan, each team member quickly tends to work in their own way, leading to inconsistent results and loss of traceability.
What is in a system specification?
A system specification is a technical document that describes what a system must be able to do, what functional and non-functional requirements it must meet, and what operating conditions it must function under. It forms the contractual and technical basis against which the design and implementation are tested.
A full system specification typically includes:
- Functional requirements: what the system must do
- Performance requirements: how well the system should execute those functions
- Boundary conditions and constraints: environment, interfaces, legislation and regulations
- Verification criteria: how is it demonstrated that a requirement has been met
- Traceability to higher or lower specification levels
Where the SEP is about the approach, the system specification is about the content. It is the document that designers, suppliers, and verifiers base their work on. A well-drafted system specification makes it possible to unambiguously assess whether a system meets the stated expectations.
What is the core difference between both documents?
The core difference is that a systems engineering plan describes how you work, while a system specification describes what The system must be. The SEP is a procedural document; the system specification is a technical-content document. Both are indispensable, but they answer fundamentally different questions.
A handy way to remember the distinction: if someone asks “how do you approach systems engineering on this project?”, refer to the SEP. If someone asks “what must this system comply with?”, refer to the system specification. The confusion often arises because both documents are in the same project file and managed by the same systems engineer.
When do you prepare each document in a project?
A systems engineering plan is created at the beginning of the project, even before the detailed specification begins. The system specification is drawn up and refined during the early project phases, but remains a living document that is maintained until delivery and handover.
In practice, the order usually looks like this:
- Initiation Phase: The SEP is prepared to define the SE approach and align it with all stakeholders.
- Definition phase: The system specification is built based on stakeholder needs and project objectives.
- Design phase Both documents are tracked and reconciled as the design progresses.
- Realization and Verification: The system specification serves as the test document; the SEP manages the verification process.
- Transfer Both documents are part of the project file being transferred to the management organization.
A common mistake is to draft the SEP only after the specification is well underway. By then, the approach has already been implicitly decided, and you're documenting what's already been set in stone instead of guiding it from the outset.
How do a systems engineering plan and systems specification work together?
The Systems Engineering Plan and the Systems Specification work together because the SEP determines the rules of engagement within which the Systems Specification is created, managed, and verified. For example, the SEP describes how requirements are numbered, how changes are implemented, and how traceability is maintained. The Systems Specification provides the content on which those rules are applied.
A concrete example: the SEP stipulates that each requirement must be assigned a verification method (test, inspection, analysis, or demonstration). The system specification contains the requirements themselves, including these verification methods. Without the SEP, consistency in how these verification methods are applied is lacking; without the system specification, the SEP has nothing to operate on.
In well-functioning projects, both documents are actively maintained and regularly compared with each other. If a requirement in the specification changes, it can have consequences for the verification approach in the SEP, and vice versa.
Which tools support the management of both documents?
For managing a systems engineering plan and a systems specification, you need tooling that supports traceability, version control, and collaboration. Many teams start with Word and Excel, but that approach quickly breaks down as projects become more complex and multiple team members work on the same documents simultaneously.
More mature alternatives include:
- Specialized MBSE Platforms Manage requirements, traceability, and verification matrices centrally
- Requirements management tools like DOORS or Polarion, which are powerful but often complex and expensive
- Low-code platforms with a semantic data structure, that flexibly grow with project needs without turning the organization upside down
Wij ontwikkelden Datastorms specifiek voor systems engineers die grip willen houden op eisen, traceability en verificatie, zonder de hoge drempel van traditionele MBSE-tools. Het platform biedt een centrale omgeving voor zowel de procesafspraken uit het SEP als de eiseninhoud uit de systeemspecificatie, inclusief automatisch gegenereerde verificatiematrices en volledige traceability van eis tot bewijs. Zo blijft kennis geborgd in het systeem, ook als teamleden wisselen. Wilt u zelf ervaren hoe dit werkt? Vraag een proeflicentie aan en ontdek wat het platform voor uw project kan betekenen.
Frequently Asked Questions
Moet elk project een apart systems engineering plan hebben, of kan één SEP voor meerdere projecten gelden?
In principe stel je voor elk project een eigen SEP op, omdat de aanpak afhangt van de projectomvang, het team, de opdrachtgever en de toepasselijke normen. Wel kun je binnen een organisatie een standaard-SEP-sjabloon ontwikkelen dat als basis dient voor nieuwe projecten. Zo borgt je de organisatiebrede werkwijze en bespaar je tijd, terwijl elk project toch zijn eigen, op maat gemaakte versie heeft.
Wat zijn de meest voorkomende fouten bij het opstellen van een systeemspecificatie?
De meest voorkomende fouten zijn: eisen formuleren die niet verifieerbaar zijn (zoals 'het systeem moet gebruiksvriendelijk zijn'), functionele eisen verwarren met ontwerpbeslissingen, en ontbrekende traceability naar stakeholderbehoeften of hogere specificatieniveaus. Een goede vuistregel is dat elke eis een duidelijke verificatiemethode moet hebben en herleidbaar moet zijn naar een concrete behoefte of randvoorwaarde.
Hoe gedetailleerd moet een systems engineering plan zijn voor een klein project?
Voor kleinere projecten hoeft een SEP geen uitgebreid document te zijn; een beknopte beschrijving van de gehanteerde methode, de rolverdeling en de belangrijkste procesafspraken is vaak voldoende. Het gaat erom dat het team dezelfde werkwijze hanteert en dat er achteraf aantoonbaar is hoe beslissingen zijn genomen. Een te uitgebreid SEP voor een klein project leidt juist tot onnodige overhead en wordt in de praktijk niet bijgehouden.
Hoe houd je een systeemspecificatie beheersbaar als de projecteisen tijdens het project veranderen?
Zorg voor een formeel wijzigingsbeheerproces dat in het SEP is vastgelegd: elke wijziging in de specificatie doorloopt een gecontroleerde beoordeling voordat deze wordt doorgevoerd. Gebruik versiebeheer zodat altijd duidelijk is welke versie van de specificatie op welk moment geldig was. Met een requirements management tool of platform zoals Datastorms kun je bovendien de impact van een wijziging direct zichtbaar maken via de traceability-links naar ontwerp en verificatie.
Wie is verantwoordelijk voor het opstellen en bijhouden van het SEP en de systeemspecificatie?
Doorgaans is de systems engineer of lead engineer verantwoordelijk voor beide documenten, maar de inhoud komt tot stand in samenwerking met het gehele projectteam en de relevante stakeholders. Het SEP is primair de verantwoordelijkheid van de SE-lead in afstemming met de projectmanager, terwijl de systeemspecificatie ook inbreng vraagt van vakdisciplines, de opdrachtgever en toekomstige beheerders. Duidelijke eigenaarschap per document voorkomt dat beiden 'van iedereen' worden en daardoor van niemand.
Is een systeemspecificatie hetzelfde als een programma van eisen (PvE)?
Niet helemaal: een programma van eisen (PvE) beschrijft doorgaans de behoeften en eisen vanuit het perspectief van de opdrachtgever, vaak op een hoger abstractieniveau. Een systeemspecificatie is technisch diepgaander en beschrijft de eisen waaraan het systeem zelf moet voldoen, inclusief prestatie-eisen, interfaces en verificatiecriteria. In veel projecten vormt het PvE de directe input voor de systeemspecificatie, waarbij de systems engineer de vertaalslag maakt van behoefte naar verifieerbare technische eis.
Vanaf welk projectmoment is gespecialiseerde tooling echt noodzakelijk, en wanneer volstaan Word en Excel nog?
Word en Excel volstaan vaak nog bij projecten met een beperkt aantal eisen (ruwweg minder dan 100-150), één of twee betrokken disciplines en weinig wijzigingen gedurende het project. Zodra traceability over meerdere specificatieniveaus loopt, meerdere teamleden tegelijk in de documenten werken of wijzigingsbeheer structureel wordt, schiet de aanpak met Word en Excel tekort. Op dat punt levert gespecialiseerde tooling direct tijdwinst op door het automatiseren van verificatiematrices, impactanalyses en rapportages.