‘Leveranciers van requirementstools zijn niet bij de tijd’

Het vak requirementsengineering beweegt zo snel dat toolleveranciers het nauwelijks kunnen bijbenen. ‘De software van grote aanbieders houdt vrijwel geen rekening met de nieuwste inzichten in het vakgebied’, zegt Cees Michielsen, trainer systeemrequirementsengineering bij High Tech Institute. ‘Dat is een grote frustratie.’

René Raaijmakers

Klanten centraler, systemen complexer, het ontwerpproces steeds meer verknoopt. In een notendop zijn dat de factoren achter de veranderingen in requirementsengineering. Volgens Cees Michielsen, trainer systeemrequirementsengineering bij High Tech Institute, is zijn vakgebied uit zijn bubbel. ‘Het is intussen een integraal onderdeel van systeemengineering.’

‘Vroeger keken we eigenlijk alleen naar de intrinsieke waarde van een requirement. Zo was de tooling oorspronkelijk ook ingericht. Intussen kijken we steeds meer naar wat zo’n requirement doet in het geheel van de productontwikkeling. We zoomen meer uit. Jammer genoeg zijn de softwaregereedschappen daarin niet meegegroeid.’

Michielsen belicht de komende maanden in Mechatronica&Machinebouw een handvol trends in zijn vakgebied. In dit interview trappen we af met enkele van de onderwerpen die hij gaat behandelen. Eerst de basis. Bij requirementsengineering gaat het erom dat klantwensen op een heldere, eenduidige manier het productontwikkeltraject ingaan zonder informatie te verliezen. Die informatie kan heel concreet zijn: een 2700 K, 350 lumen ledlamp. Maar ook heel vaag: een comfortabele vrachtauto. ‘We moeten tot het juiste product komen’, zegt Michielsen. ‘Wat de klant wil, moeten we op een efficiënte maar correcte manier implementeren.’

Grote bewegingen

Grofweg ziet Michielsen een handvol grote bewegingen in requirementsengineering. Zo is het voor technici een eeuwigdurende uitdaging om de requirements voor een product volledig te krijgen. ‘Het is een terugkerende vraag van de deelnemers aan mijn trainingen’, zegt Michielsen. Daarnaast is er de wens om de kwaliteit van requirements te verhogen. Dit is niet altijd even spannend en tegelijkertijd voor technici een uitdaging, omdat taal en formulering een grote rol spelen bij het opstellen van goede requirements en productspecificaties.

De toenemende behoefte aan traceerbaarheid zou je wellicht een echt nieuwe trend kunnen noemen. ‘Die term slaat op het kunnen nalopen van alle gebeurtenissen en beslissingen in het requirementsengineering-, ontwerp- en besluitvormingsproces, van stakeholders naar productimplementatie’, legt Michielsen uit. ‘Andersom is het belangrijk, zeker in grotere projecten, dat je voor elke willekeurige requirement op elk decompositieniveau de weg weet terug te vinden naar de wensen van de stakeholder. Waarom een zijspiegel op een vrachtwagen vervangen door een buitencamera met beeldscherm in de cabine? Je wilt weten waarom zo’n requirement überhaupt bestaat en waarom het de waarde heeft die het heeft? Wat moeten de eigenschappen van die camera zijn, hoe groot en welke resolutie is het beeldscherm? Welke besluitvorming heeft geleid tot die specifieke waardes voor die requirement?’

‘Een goed requirementsengineeringproces zorgt ervoor dat de stakeholder needs via verschillende iteraties van de ontwikkelprocessen bij de implementatie terechtkomen, zonder dat er informatie verloren gaat, inclusief de intentie van de klantwens. Er mogen ook geen requirements bij komen waar geen stakeholder voor is.’

Waarom is het zo belangrijk om naast het resultaat van een besluit ook de besluitvorming vast te leggen?

‘Je wilt in staat zijn om snel en efficiënt wijzigingen aan je product te kunnen doorvoeren. Daarvoor moet je ook de redenering weten waarmee je tot een oplossing bent gekomen. Als je die besluitvorming niet vastlegt, dan moet je bij wijzigingen dat hele redeneerproces opnieuw doen. Het hele traject opnieuw afleggen en opnieuw op hoog niveau gaan nadenken wat de voorgestelde wijziging betekent.’

‘Leg je de besluitvorming wel vast, dan win je ontzettend veel tijd. Vooral in organisaties die werken met veel productvarianten. Als je weet dat een aanpassing alleen te maken heeft met het onderscheid tussen variant 1 en variant 2, dan ben je veel sneller klaar. Je kunt veel efficiënter werken.’

Dat is belangrijk als je honderd verschillende scheerapparaten maakt.

‘Ja. Als je voor dat soort aantallen goede navolgbaarheid in je requirementsengineeringproces brengt, dan is je administratieve overhead bijna weg.’

Beperkte ondersteuning

Opmerkelijk is Michielsens constatering dat vrijwel alle leveranciers van requirementstooling fors achterlopen bij de werkelijkheid in de productontwikkeling. Zaken als traceerbaarheid en de relaties tussen requirements zijn nog nauwelijks ingevuld in de softwaregereedschappen. Dan heb je het toch over spelers als IBM en Siemens. ‘Het lijkt wel of ze zich nooit hebben verdiept in de stadia die requirements doorlopen vanaf de stakeholder needs tot aan de implementatie. Het ontbreken van een functionele en fysieke breakdown van het systeem heeft tot gevolg dat je ook de requirements niet kunt koppelen aan die specifieke systeemelementen. Je mist feitelijk het grootste deel van de functionele en fysieke breakdown, de linkerkant van het V-model.’

‘Ik vind dat leveranciers van product lifecycle management-tools op het moment een te beperkte kijk hebben op de rol van requirementsengineering binnen systeemengineering. Daarnaast ondersteunen ze de linkerkant van het V-model niet of onvoldoende. Om die reden vind ik dat ze de titel plm-toolleverancier onwaardig zijn. Ze ondersteunen ten slotte maar een beperkt deel van de cyclus’, aldus Michielsen.

Kun je een voorbeeld geven van wat eraan mankeert?

‘In de traditionele manier van werken houden engineers per product of onderdeel bij in hoeverre dat deel uitmaakt van een functionele module. Neem als voorbeeld een fietsstuur type X met een geïntegreerde fietsbel Q in het handvat van dat stuur. Voor fietsstuur type X is dit een vast onderdeel. Stel dat fietsstuur type Y meerdere mogelijkheden kent om een fietsbel te plaatsen, waarbij een geïntegreerde versie ook een optie is. Fietsstuur type Y bestaat optioneel uit fietsbel type Q. Traditioneel leggen we de relatie tussen het object fietsbel Q met de fietssturen X en Y vast als kenmerkende informatie van fietsbel Q. Dit heeft tot gevolg dat het object fietsbel type Q telkens moet worden aangepast, bij elke nieuwe relatie met een fietsstuur. Het versie- of revisienummer, de status, enzovoorts. Bovendien moeten alle bestaande koppelingen worden gecontroleerd. Dit betekent een grote administratieve overhead.’

‘Maar dit is in feite niet nodig, want het object fietsbel Q is in het geheel niet veranderd. Alleen de relaties tussen de onderdelen zijn veranderd. De oplossing is relatief eenvoudig: zorg dat de informatie die aangeeft wat de aard van de relatie tussen objecten is een conditionele relatie is. Deze mogelijkheid ontbreekt echter bij de huidige tools. De administratieve overhead werkt door tot en met de requirements, die ook de relatie met andere objecten als attribuut beschrijven. We hebben het hier echt over tooling van de grote plm-leveranciers; die kan dat gewoon nog niet op dit moment. Hier valt dus nog veel te winnen.’

Je zou zeggen dat partijen als IBM en Siemens met hun gigantische ontwikkelafdelingen toch bij de tijd kunnen zijn?

‘Maar dat zijn ze niet. Nog niet. De requirementsengineeringpraktijk heeft echt gigantische stappen gemaakt, maar die zijn niet gevolgd door de leveranciers van requirementstooling. Ook kleinere spelers als Top Team, Cockpit en Contact Software zijn er nog niet. Dat is een grote frustratie.’

Nieuwe toolleveranciers hebben een markt te veroveren en zouden gemotiveerd moeten zijn om functionaliteit toe te voegen?

‘Dat doen ze nog onvoldoende, terwijl ze als nieuwkomers wel de flexibiliteit hebben om dit te doen. Relatics uit Ridderkerk is een partij die het wel aardig doet, maar zij zitten vooral in de civiele techniek en niet in de machinebouw. Relatics heeft zijn hele tool gebouwd rondom semantic modeling, waarbij je de hele wereld beschouwt als objecten en relaties daartussen en alle bijbehorende attributen.’

W-model

Requirementsengineering beïnvloedt ook de manier waarop we naar productcreatie kijken. In de hightech wordt vaak verwezen naar het V-model als het gaat om het proces van eerste ideeën naar productimplementatie. Het Dit model begint met een functionele breakdown, de linkerpoot van de V. Michielsen: ‘Een praktisch probleem is dat je in de traditionele functionele breakdown niet alle requirements kunt meenemen. Dat geldt onder meer voor de fysieke eigenschappen van producten. Massa, volume, dat soort dingen. Het zou verstandig zijn om twee parallelle trajecten te starten in die linkerpoot. Later blijkt dat je in de opgaande poot, bij het integreren, niet datgene kunt testen wat je hebt gespecificeerd. Dat komt bijvoorbeeld voor als een submodule of functie is verdeeld of gedistribueerd over verschillende fysieke modules. In dat geval ben je niet in staat om die specifieke subsystemen als afzonderlijke modules een op een te testen.

Het subsysteem is eigenlijk pas te testen als de hele machine is samengesteld. ‘Je wilt zo’n functie al in het begin kunnen testen, maar dat lukt inderdaad niet’, aldus Michielsen. ‘Je hebt dan twee parallelle ontwikkeltrajecten nodig, inclusief de verantwoordelijkheden en budgetten die je daaraan kunt toewijzen. Voordat je überhaupt iets gaat laten maken of assembleren, doe je met simulatietooling een virtuele functionele integratie en een virtuele fysieke integratie. Met als doel om eerst vast te stellen dat het ontwerp klopt. Dat alles werkt en alles past. Dat is de opgaande poot in het midden.’

‘Als je dan aan het einde komt van die virtuele ontwikkeling, weet je ook precies dat je de juiste bouwblokken hebt ontwikkeld. Je bent dan compleet ten aanzien van de functionaliteit. Tegelijkertijd weet je ook waar die bouwblokken in verschillende fysieke modules terechtkomen, want dat toon je aan via je fysieke ontwerp. Als het virtueel past, dan ga je implementeren, construeren, programmeren, enzovoorts.’ Deze vorm van ontwikkelen noemt Michielsen het W-model en daaraan zal hij een apart artikel wijden.

De trendreeks over systeemrequirementsengineering is ook beschikbaar als Bits&Chips-podcasts op Apple, Buzzsprout en Spotify.