Vrijdagmiddag, half vijf. Je telefoon gaat. De projectmanager klinkt gestrest: “We hebben een probleem. De software werkt perfect in de testomgeving, maar crasht bij de klant. En maandag gaan we live.”
Herkenbaar? Dit scenario speelt zich helaas vaker af dan je zou willen. En eerlijk? In veel gevallen ligt de oorzaak niet bij slechte code of te weinig tests. Het probleem zit dieper: er is niet goed nagedacht over hoe alle onderdelen van het systeem samenwerken.
Daar komt systems engineering om de hoek kijken.
Wat is systems engineering precies?
Systems engineering is eigenlijk een manier van denken. In plaats van te focussen op losse onderdelen (de software, de hardware, de gebruikersinterface), kijk je naar het geheel. Hoe werken al die onderdelen samen? Wat gebeurt er als één component faalt? En misschien wel de belangrijkste vraag: bouwen we eigenlijk wat de klant echt nodig heeft?
Het verschil met software engineering? Een software engineer focust op de code. Een systems engineer kijkt breder. Die vraagt zich af: past deze software wel in het grotere plaatje? Werkt het samen met de andere systemen? En kunnen we straks bewijzen dat het doet wat het moet doen?
Bij organisaties als ASML, ProRail en Rijkswaterstaat is deze aanpak al jaren standaard. Niet omdat het hip is, maar omdat het werkt. Complexe systemen vragen nu eenmaal om een holistische blik.
Verificatie en validatie: het hart van systems engineering
Nu wordt het interessant voor testers. Want in het hart van systems engineering vind je twee begrippen die je als tester moet kennen: verificatie en validatie. Vaak afgekort tot V&V.
Het verschil? Verificatie beantwoordt de vraag: “Bouwen we het systeem goed?” Dus: werkt de code volgens de specificaties? Validatie gaat een stap verder en vraagt: “Bouwen we het goede systeem?” Oftewel: lost dit echt het probleem van de gebruiker op?
Weet je wat veel teams fout doen? Ze zien V&V als een testfase aan het eind van het project. Iets wat je doet vlak voor de livegang. Maar dat is fundamenteel verkeerd.
Bij elke requirement die je opstelt, moet je dag één al weten: hoe ga ik dit verifiëren? Hoe ga ik dit valideren? Niet achteraf bedenken, maar vooraf. ISO 15288, de internationale standaard voor systems engineering, schrijft dit expliciet voor. En terecht.
Stel bij elke vereiste (requirement) direct de vraag: hoe test ik dit? Kun je die vraag niet beantwoorden? Dan is je vereiste niet goed genoeg gedefinieerd. Zo simpel is het eigenlijk.
De vier processen die elke tester moet kennen
Systems engineering draait om vier kernprocessen. Als tester hoef je geen expert te worden in allemaal, maar het helpt enorm als je snapt hoe ze werken.
Requirements management gaat over het vastleggen en beheren van wat het systeem moet doen. Voor testers is dit goud waard. Want weet je wat we vaak zien? Dat teams beginnen met testen voordat de requirements stabiel zijn. Onderzoek laat zien dat zo’n 40% van alle defecten niet komt door slechte code, maar door onduidelijke requirements. Bij een fintech-klant zagen we dat drie weken investeren in requirements review acht weken testwerk bespaarde. Die rekensom is snel gemaakt.
Design synthesis is het vertalen van requirements naar een concreet ontwerp. Hier kun je als tester al vroeg invloed uitoefenen. Is dit ontwerp eigenlijk wel testbaar? Kunnen we straks geautomatiseerd testen? Die vragen moet je nu stellen, niet als de bouw al klaar is.
Verificatie en validatie hebben we al besproken. Dit is waar testen en systems engineering elkaar raken.
Risicobeheer gaat over het identificeren en managen van wat mis kan gaan. Als tester ken je dit waarschijnlijk als risk-based testen: je beperkte testtijd inzetten waar de grootste risico’s zitten. Systems engineering tilt dit naar een hoger niveau door risico’s over de hele levenscyclus te bekijken.
Systems engineering in de praktijk
Waar komt deze aanpak eigenlijk vandaan? De lucht- en ruimtevaart. Logisch ook: als je een raket bouwt, kun je je geen fouten permitteren. Elke schroef, elke lijn code, elke interface moet kloppen. En je moet ook kunnen bewijzen dat het klopt.
Maar de principes zijn net zo relevant voor enterprise IT. Denk aan een digital transformation traject waar je legacy systemen vervangt. Of een compliance-kritische omgeving waar je moet kunnen aantonen dat je systemen doen wat ze moeten doen. ProRail en Rijkswaterstaat eisen systems engineering methodiek juist omdat complexe infra-projecten anders uit de hand lopen.
En in agile teams dan? Ja, ook daar past het. De kunst is om de principes toe te passen zonder te verzanden in bureaucratie. Denk aan een “definition of ready” die V&V-criteria bevat. Of een architect die bij elke sprint meedenkt over systeemintegratie. Het hoeft niet zwaar te zijn.
De valkuilen (en hoe je ze voorkomt)
Laten we eerlijk zijn: systems engineering kan ook misgaan. Dit zijn de valkuilen die we in de praktijk tegenkomen.
Te late betrokkenheid van testers.
Als je pas bij de testfase aanschuift, ben je te laat. De belangrijkste beslissingen zijn dan al genomen. Zorg dat je vanaf het begin meepraat over requirements en ontwerp.
Scope creep door onduidelijke requirements.
“Dat bedoelden we niet zo” is een zin die je niet wilt horen tijdens systeemtests. Investeer in heldere, testbare requirements. Vraag door tot je precies weet wat er verwacht wordt.
De communicatiekloof tussen disciplines.
Hardware engineers, software developers en testers spreken vaak verschillende “talen”. Dezelfde term kan iets heel anders betekenen per vakgebied. Het woord “interface” bijvoorbeeld wordt door een hardware engineer anders geïnterpreteerd dan door een softwareontwikkelaar. Systems engineering dwingt een gemeenschappelijke taal af. Dat is geen bureaucratie, het voorkomt miscommunicatie die miljoenen kan kosten.
Systems engineering en agile: kan dat samen?
Een vraag die nu volgt: past dit wel bij agile werken? Het korte antwoord: ja. Het langere antwoord: het vraagt wel wat aanpassingen.
De kernprincipes van systems engineering, denken in systemen, vroegtijdig nadenken over V&V, risico’s managen, passen prima in een agile werkwijze. Wat je moet vermijden is het overnemen van alle formaliteiten uit de klassieke systems engineering wereld. Geen dikke documenten die niemand leest. Wel de mindset.
Praktische tips: neem V&V-criteria op in je definition of done. Betrek een systems engineer of architect bij sprint planning. En zorg dat je bij elke user story nadenkt over de impact op het grotere systeem.
Aan de slag
Systems engineering klinkt misschien abstract, maar de kern is simpel: denk na over het geheel, niet alleen de onderdelen. Stel de juiste vragen aan het begin, niet aan het eind. En zorg dat je kunt bewijzen dat je systeem doet wat het moet doen.
Als tester kun je hier direct mee aan de slag. Begin bij je volgende project eens met de vraag: hoe ga ik deze requirements straks verifiëren en valideren? Je zult merken dat die ene vraag al heel veel duidelijkheid geeft.
Wil je sparren over hoe systems engineering principes kunnen werken in jouw organisatie? Of zoek je ondersteuning bij het testen van complexe systemen? We denken graag met je mee. Plan een vrijblijvend gesprek en we verkennen samen de mogelijkheden.
