Eenduidige requirements zijn cruciaal voor succesvolle validatie, maar blijken in de praktijk lastig vast te leggen. Door beter te definiëren, structureren en herleiden wat een systeem moet doen, kunnen veel problemen in een later stadium worden voorkomen, zo leerde Bart van Liere bij een training van High Tech Institute.
Wanneer een chirurgische robot een hechting moet zetten op microschaal, lijkt de functionele eis helder: positioneer en beweeg met een nauwkeurigheid van enkele tientallen micrometers. Maar zodra niet is vastgelegd in welk type weefsel die hechting moet plaatsvinden, ontstaat er direct ruimte voor interpretatie. Zacht weefsel vraagt om een andere krachtopbouw dan stug of vezelig materiaal, wat zowel de benodigde actuatie beïnvloedt als de keuze van het hechtmateriaal. Tijdens de validatie blijkt dat een specificatie die op papier klopt, in de praktijk ontworpen is met aannames die nergens expliciet zijn gemaakt.
‘Voldoen aan de eis’ is waar Bart van Liere, Integration Engineer bij TMC, gedetacheerd bij MTA, dagelijks mee te maken heeft. Hij staat aan de achterkant van het ontwikkeltraject, waar moet worden aangetoond dat een systeem doet wat vooraf is vastgelegd. ‘Als een eis te vaag is geformuleerd, een randvoorwaarde impliciet is gebleven of stakeholders niet goed hebben kunnen overbrengen wat ze voor ogen hadden bij hetzelfde ‘functionele’ doel, komen we daar tijdens de validatie achter.’
Integrator
Na zijn hbo-opleiding Mechatronica specialiseerde Van Liere zich verder met de masters Mechanical Engineering en AI for Engineering Systems aan de Technische Universiteit Eindhoven. Inmiddels is hij via TMC actief als Integration Engineer. Via TMC worden technisch inhoudelijk geschoolde mensen, zogenoemde employeneurs, ingezet op uiteenlopende projecten bij verschillende hightech opdrachtgevers.
Momenteel is Van Liere gedetacheerd bij MTA, waar hij onder andere betrokken is bij een project bij Microsure rond een chirurgische robot die op 50 micrometer nauwkeurig moet opereren. In zijn rol als systeemintegrator vormt hij de schakel tussen ontwerp en praktijk. Hij werkt met engineers aan de technische invulling en met stakeholders aan de vertaalslag naar concrete specificaties en validatiecriteria.
Die rol is hem niet vreemd. Eerder richtte Van Liere samen met partners een eigen bedrijf op, waarin een drone werd ontwikkeld voor inzet in risicovolle gebieden. ‘In dat traject merkten we hoe belangrijk het is om in het begin scherp te krijgen wat je precies probeert te bouwen’, geeft hij aan. ‘Als je daar de essentie mist, zie je dat later terug in een eindproduct dat niet volledig voldoet aan het beeld dat je voor ogen had.’
Interpretatieverschil
In de praktijk ontstaat dit probleem zelden door onkunde, maar door de manier waarop eisen tot stand komen. Een stakeholder formuleert wat het systeem moet bereiken, terwijl een engineer geneigd is om dat impliciet te vertalen naar hoe het systeem dat zou kunnen doen. Die twee perspectieven sluiten niet automatisch op elkaar aan. Zonder expliciete afbakening van de primaire functie en de randvoorwaarden ontstaat zo een set eisen waarin intentie en implementatie door elkaar lopen. Het gevolg is dat specificaties volledig lijken, maar bij nadere beschouwing verschillende interpretaties toelaten.
Om te voorkomen dat eisen gedurende het traject verschillend worden geïnterpreteerd, is een meer gestructureerde aanpak voor het opstellen van requirements nodig. Zo moet vastgelegd worden wat een systeem moet doen, maar ook waarom keuzes gemaakt worden en onder welke voorwaarden ze gelden. Om daar meer grip op te krijgen, verdiepte Van Liere zich in de training System Requirements Engineering van High Tech Institute, gegeven door Cees Michielsen.
‘In deze training leerden we dat het helder en duidelijk opstellen van de requirements begint bij het stellen van de juiste vragen’, vertelt Van Liere. ‘Wat is de primaire functie van het systeem en welke randvoorwaarden zijn bepalend? Alles wat je vervolgens op papier zet, moet telkens opnieuw hieraan getoetst worden.’
Deze methode dwingt je tot het maken van scherpere keuzes in een vroeg stadium. ‘Engineers zijn geneigd om in een brainstorm alles mee te nemen’, zegt Van Liere geamuseerd. ‘Dan krijg je een lijst die op papier compleet is, maar waar weinig focus in zit. Bovendien lijkt alles belangrijk.’ Door eerst vast te stellen wat minimaal nodig is om het systeem te laten doen wat het moet doen, wordt het eenvoudiger om bijzaken te onderscheiden van essentiële eisen en de zogenaamde nice to haves. Dat zorgt voor meer overzicht in de ontwerpfase en houdt rekening met de uiteindelijke validatie.
Wijzigingen bijhouden
Van Liere kon de methode direct toepassen in een lopend project waarin hij vanuit de validatiehoek betrokken was bij het opstellen van requirements. ‘Je merkt dat je met een andere blik kijkt’, zegt hij. ‘In plaats van meteen eisen te formuleren, ga je eerst terug naar de kern: wat proberen we hier eigenlijk te bereiken?’ Door die stap expliciet te maken, ontstond er meer focus in het proces en werd sneller duidelijk welke eisen essentieel waren en welke konden wachten. ‘Dit kost in het begin wat meer tijd, maar dat is nog altijd goedkoper dan een prototype moeten aanpassen omdat de requirements niet goed zijn opgesteld.’
Naast het stellen van de juiste vragen ging trainer Michielsen tijdens de cursus ook in op het vastleggen en bijhouden van wijzigingen gedurende het ontwikkelproces. Hierbij haalde hij voorbeelden aan uit zijn ervaring bij onder andere DAF en ASML. ‘Tijdens het ontwikkelproces kunnen inzichten veranderen en worden keuzes gemaakt om een bepaalde reden,’ vertelt Van Liere. ‘Bij de validatie wil je echter weten of een uitkomst het resultaat is van een fout of een bewuste keuze tijdens het ontwikkelproces.’ Door wijzigingen en onderliggende argumentatie structureel vast te leggen, blijft inzichtelijk hoe een requirement zich heeft ontwikkeld en op basis waarvan beslissingen zijn genomen.
Universele principes
Tijdens de training zat Van Liere met deelnemers uit uiteenlopende sectoren, van hightech tot energietransitie. ‘De context verschilt, maar de problemen zijn hetzelfde’, zegt hij. ‘De discussies die zij met hun stakeholders hebben, heb ik ook. Blijkbaar zit daar dus vaak de uitdaging.’
Voor Van Liere zat de waarde van de training vooral in de manier waarop het denken rond requirements werd gestructureerd. ‘Je leert gerichter doorvragen en beter vastleggen wat er eigenlijk wordt bedoeld. Juist die structuur helpt om bewuster keuzes te maken en het gesprek met stakeholders scherper te voeren.’ De reader van de cursus ligt inmiddels standaard op zijn bureau, als naslagwerk voor momenten waarop hij die denkwijze opnieuw wil toepassen.
De cursus begon voor zijn gevoel in een rustig tempo, maar kwam daarna snel op gang. ‘Het is een tweedaagse training naast je werk, dus je moet ergens een balans vinden. Maar er was genoeg ruimte om de diepte in te gaan en eigen casussen in te brengen. De ruime ervaring van Michielsen maakte dat hij de diversiteit aan inbreng goed kon onderbrengen.’ Zo werd de theorie direct getoetst aan de praktijk. ‘Je leert daarbij echt het hele traject volgen, zodat je later kunt herleiden waarom een eis is opgesteld en welke keuzes daar gaandeweg in zijn gemaakt.’
