“Requirements tooling suppliers zijn niet up-to-date en dat is frustrerend”

Gepubliceerd op: 08 april 2022

Expert:

Cees Michielsen

Trainer

Lees meer over Cees Michielsen

Deel

---

Het vakgebied van requirements engineering beweegt zo snel dat leveranciers van tools het nauwelijks kunnen bijhouden. “De software van grote leveranciers houdt nauwelijks rekening met de nieuwste inzichten in ons vakgebied”, zegt Cees Michielsen, trainer System requirements engineering bij High Tech Institute.

Klanten komen meer centraal te staan, systemen worden complexer en het ontwerpproces raakt steeds meer verweven. In een notendop zijn dit de factoren die verandering in requirements engineering stimuleren. “Requirements engineering is uit zijn bubbel”, zegt Cees Michielsen, trainer van system requirements engineering bij High Tech Institute. “Het is nu een integraal onderdeel van systems engineering.”

“In het verleden keken we alleen naar de intrinsieke waarde van een vereiste. Zo was de tooling oorspronkelijk ook opgezet. Inmiddels richten we ons steeds meer op wat zo’n requirement doet in het geheel van de productontwikkeling. We zoomen meer uit. Helaas zijn de softwaretools niet met ons meegegroeid.”

De komende maanden zal Michielsen in Bits&Chips een handvol trends in zijn vakgebied belichten. In dit interview beginnen we met een aantal van de onderwerpen die hij gaat behandelen.

Belangrijke trends

Requirements engineering is ervoor zorgen dat de wensen van de klant op een duidelijke, ondubbelzinnige manier in het productontwikkelingsproces terechtkomen, zonder dat er informatie verloren gaat. Die informatie kan heel concreet zijn: een LED-lamp met 2700 K en 350 lumen. Maar het kan ook vaag zijn: een comfortabele vrachtwagen. “We moeten tot het juiste product komen,” merkt Michielsen op. “We moeten op een efficiënte maar correcte manier implementeren wat de klant wil.”

Grofweg ziet Michielsen een handvol grote trends in requirements engineering. Het compleet krijgen van de requirements voor een product is bijvoorbeeld een blijvende uitdaging voor engineers. “Het is een terugkerende vraag van deelnemers aan mijn trainingen,” merkt Michielsen op. Er is ook een wens om de kwaliteit van requirements te verhogen. Hoewel niet altijd even spannend, is dit een uitdaging voor ingenieurs omdat taal en formulering een sleutelrol spelen bij het opstellen van goede requirements en productspecificaties.

De toenemende behoefte aan traceerbaarheid kan misschien wel een echt nieuwe trend worden genoemd. “Die term verwijst naar het kunnen volgen van alle gebeurtenissen en beslissingen in het requirements engineering-, ontwerp- en besluitvormingsproces, van belanghebbenden tot productimplementatie”, legt Michielsen uit. “Omgekeerd is het belangrijk, vooral in grotere projecten, dat je voor elke vereiste op elk decompositieniveau weet hoe je de weg terug kunt vinden naar de behoeften van de stakeholder. Waarom zou je een zijspiegel op een vrachtwagen vervangen door een achteruitrijcamera en een display in de cabine? Je wilt weten waarom zo’n vereiste überhaupt bestaat en waarom het de waarde heeft die het heeft. Wat moeten de kenmerken van die camera zijn, hoe groot en welke resolutie heeft het display? Welke besluitvorming heeft geleid tot die specifieke waarden voor die eis?”

“Een goed requirements engineering proces zorgt ervoor dat de behoeften van de belanghebbenden door de verschillende iteraties van de ontwikkeling heen bij de implementatie komen zonder dat er informatie verloren gaat, inclusief de intentie van de eis van de klant. Ook mogen er geen requirements worden toegevoegd waarvoor geen stakeholder is.”

Waarom is het zo belangrijk om niet alleen de uitkomst van een beslissing vast te leggen, maar ook het besluitvormingsproces?

“Je wilt snel en efficiënt wijzigingen in je product kunnen aanbrengen. Om dat te kunnen doen, moet je ook de redenering kennen waarmee je tot een oplossing bent gekomen. Als je het besluitvormingsproces niet vastlegt, moet je bij elke wijziging het hele redeneringsproces opnieuw doen. Je moet het hele proces opnieuw doorlopen en op een hoog niveau opnieuw gaan nadenken over wat de voorgestelde verandering betekent.”

“Als je de besluitvorming vastlegt, bespaar je ontzettend veel tijd. Vooral in organisaties die met veel productvarianten werken. Als je weet dat een aanpassing alleen te maken heeft met het onderscheid tussen variant 1 en variant 2, ben je veel sneller klaar. Je kunt veel efficiënter werken.”

Dat is belangrijk als je honderd verschillende scheerapparaten maakt.

“Ja. Voor dat soort getallen, als je goede traceerbaarheid in je requirements engineering proces brengt, is je administratieve overhead bijna verdwenen.”

Trainer Cees Michielsen

Tot Michielsens grote frustratie lopen bijna alle leveranciers van requirements tooling substantieel achter op de realiteit in productontwikkeling. Zaken als traceerbaarheid en de relaties tussen requirements zijn nauwelijks ingevuld in de softwaretools van leveranciers als IBM en Siemens. “Het lijkt alsof ze zich nooit hebben verdiept in de stadia die requirements doorlopen vanaf de behoeften van belanghebbenden tot aan de implementatie. Het ontbreken van een functionele en fysieke uitsplitsing van het systeem betekent dat je de requirements niet kunt koppelen aan die specifieke systeemelementen. Je mist eigenlijk het grootste deel van de functionele en fysieke uitsplitsing – de linkerkant van het V-model.”

“Ik denk dat leveranciers van product lifecycle management tools momenteel een te beperkte kijk hebben op de rol van requirements engineering binnen systems engineering. Bovendien ondersteunen ze de linkerkant van het V-model niet of onvoldoende. Daarom vind ik dat ze de titel ‘PLM tool vendor’ onwaardig zijn. Ze ondersteunen immers maar een beperkt deel van de levenscyclus.”

Kun je een voorbeeld geven om uit te leggen wat er mis is?

“In de traditionele manier van werken houden ingenieurs bij in welke mate elk onderdeel of product deel uitmaakt van een functionele module. Neem als voorbeeld een fietsstuur van het type X met een geïntegreerde fietsbel Q in het handvat van dat stuur. Voor fietsstuur type X is dit een vast onderdeel. Fietsstuur type X bevat fietsbel type Q.”

“Stel dat fietsstuurtype Y meerdere opties heeft voor het plaatsen van een fietsbel, waaronder een geïntegreerde versie. Fietsstuurtype Y bevat optioneel fietsbel type Q. Traditioneel leggen we de relatie tussen het object fietsbel Q en de fietssturen X en Y vast als kenmerkende informatie van fietsbel Q. Dit heeft tot gevolg dat het object fietsbel Q telkens moet worden aangepast bij elke nieuwe relatie met een fietsstuur. Het versie- of revisienummer, de status, enzovoort. Bovendien moeten alle bestaande koppelingen worden gecontroleerd. Dit betekent een grote administratieve overhead.”

“Maar dat is eigenlijk niet nodig, want het object fietsbel Q is helemaal niet veranderd. Alleen de relaties tussen de onderdelen zijn veranderd. De oplossing is relatief eenvoudig: zorg ervoor dat de informatie die de aard van de relatie tussen objecten aangeeft een voorwaardelijke relatie is. Deze mogelijkheid ontbreekt echter in de huidige tools. De administratieve overhead werkt door in de requirements, die ook de relatie met andere objecten als attribuut beschrijven. We hebben het hier over tools van de grote PLM-leveranciers! Op dit moment kunnen ze het gewoon niet. Er valt hier dus nog veel te winnen.”

U zegt dat grote spelers als IBM en Siemens met hun enorme ontwikkelingsafdelingen niet up-to-date zijn?

“Dat zijn ze zeker nog niet. De requirements engineering praktijk heeft enorme stappen gemaakt, maar deze zijn nog niet gevolgd door de tool leveranciers. Zelfs kleinere spelers als Top Team, Cockpit en Contact Software zijn er nog niet. Dat is een grote frustratie.”

Verkopers van nieuwe tools hebben een markt te veroveren en moeten gemotiveerd zijn om functionaliteit toe te voegen.

“Dat doen ze nog te weinig, terwijl ze als nieuwkomers wel de flexibiliteit hebben om dat te doen. Het Nederlandse bedrijf Relatics uit Ridderkerk is een leverancier die het goed doet, maar zij zijn vooral gericht op civiele techniek en niet op werktuigbouw. Relatics heeft zijn hele tool gebouwd rond semantisch modelleren, waarbij je de hele wereld beschouwt als objecten en relaties daartussen en alle attributen die daarbij horen.”

Requirements engineering beïnvloedt ook de manier waarop we naar productcreatie kijken. In hightech wordt vaak verwezen naar het V-model als het gaat om het proces van eerste ideeën tot productimplementatie. Dit model begint met een functionele uitsplitsing, de linkerpoot van de V. Michielsen: “Een praktisch probleem is dat je niet alle eisen kunt opnemen in de traditionele functionele uitsplitsing. Dat geldt onder andere voor de fysieke eigenschappen van producten. Massa, volume, dat soort informatie. Het zou verstandig zijn om in dat linkerbeen twee parallelle trajecten te starten. Want later zal blijken dat je in het opgaande been, als je integreert, niet kunt testen wat je hebt gespecificeerd. Dit gebeurt bijvoorbeeld als een submodule of functie is verdeeld of opgedeeld over meerdere fysieke modules. In dat geval kun je die specifieke subsystemen niet één voor één als afzonderlijke modules testen.”

Het subsysteem kan pas worden getest als de hele machine is geassembleerd?

“Je zou zo’n functie het liefst meteen aan het begin willen kunnen testen, maar dat werkt inderdaad niet. Je hebt dan eigenlijk twee parallelle ontwikkeltrajecten nodig, inclusief de verantwoordelijkheden en budgetten die je daaraan kunt toekennen. Voordat je überhaupt iets laat maken of assembleren, gebruik je simulatietooling om een virtuele functionele integratie en een virtuele fysieke integratie te doen. Het doel is om eerst vast te stellen dat het ontwerp klopt. Dat alles werkt en alles past.

“Als je aan het einde van die virtuele ontwikkeling komt, weet je ook precies dat je de juiste bouwstenen hebt ontwikkeld. Je bent compleet wat betreft functionaliteit. Tegelijkertijd weet je ook waar die bouwstenen terechtkomen in de verschillende fysieke modules, omdat je dat kunt aantonen met je fysieke ontwerp. Zodra het virtueel past, begin je met implementeren, bouwen, programmeren, enzovoort.”

Het W-model, zoals Michielsen deze vorm van ontwikkeling noemt, zal het onderwerp zijn van een aparte aflevering in zijn trendreeks.

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

Dit artikel is geschreven door René Raaijmakers, techredacteur van Bits&Chips.