Zorg dat je systeemeisen compleet zijn

Een vraag die in bijna al mijn trainingen systeemrequirementsengineering opduikt, is: hoe zorgen we ervoor dat onze requirementspecificatie compleet is? Een terechte vraag. Ontbrekende requirements betekent meestal ontbrekende functionaliteit in de producten die we ontwikkelen. Met gevolgen: aan verwachtingen wordt niet voldaan of het product is niet concurrerend.

In de praktijk zijn requirementspecificaties zelden volledig. Het is gewoon heel moeilijk om ze compleet te maken en te houden. Gelukkig hebben we in de afgelopen decennia technieken en methoden geleerd die ons kunnen helpen in ons streven naar volledigheid.

Checken en graven

Ten eerste werken sjablonen en checklists echt. Ze stammen uit de begintijd van engineering en helpen ons om de voor de hand liggende vereisten niet te vergeten. Vandaag de dag is er hulp in overvloed. Het internet is bezaaid met checklists voor requirements.

Je zult ook zelf wat moeten graven: zoek alle stakeholders met een mogelijke impact op het succes van het product. Mis je stakeholders, dan kun je hun behoeftes en verwachtingen niet vastleggen. Dat is een recept voor mislukking. Natuurlijk moet je die stakeholders ook ondervragen en uitdagen om hun echte behoeftes te achterhalen. Het helpt ook om deze behoeftes expliciet te maken. Als je de brandweer pas uitnodigt bij de opening van een nieuw gebouwde tunnel, dan kun je er te laat achter komen dat je essentiële veiligheidsmaatregelen hebt gemist. Dus je moet ze in een vroeg stadium betrekken.

Evenwicht zoeken

Bekijk het vanuit verschillende perspectieven – door de ogen van werkelijke gebruikers, eigenaren en investeerders. Betrek er gebruikers bij die mogelijk negatieve effecten ervaren. Deze perspectieven kunnen soms het beste worden beschreven in een concept of operations, user stories, use cases en scenario’s.

 advertorial 

Test less, verify Moore

At the Bits&Chips Event 2023 on 12 October 2023, Phillipa Hopcroft from Crocotec and Ivo ter Horst from ASML will kick off with a keynote speech on transforming how lithography machine software is built. Make sure to keep an eye on the website for program updates and save the date!

Realiseer je dat de requirements elicitation-stap (waarin je stakeholders en hun behoeftes identificeert) plaatsvindt op elk decompositieniveau van je productarchitectuur voor elk systeemelement! Op elk niveau zul je nieuwe belanghebbenden vinden die specifiek zijn voor dat systeemelement op dat niveau. Denk aan coderingsnormen voor software in een multidisciplinair product.

Analyseer de behoeftes op een gestructureerde manier. Dit betekent dat je onderscheid moet maken tussen hoofd- en subfuncties. Tussen een functie, haar eigenschappen en haar ontwerpbeperkingen. Uiteindelijk moet je een evenwicht vinden tussen de eisen die aan functies worden gesteld inzake prestaties en eigenschappen van hulpbronnen.

Als bij een personenauto ‘mensen vervoeren’ de hoofdfunctie is, dan moeten we uitdrukken en kwantificeren hoe goed we mensen moeten vervoeren: hoe comfortabel, hoe betrouwbaar, hoeveel mensen, hoe veilig? Dit zijn voorbeelden van prestatie-eigenschappen (of kwaliteiten) van een functie. Ze worden afgewogen tegen de middeleneigenschappen, zoals: hoeveel energie mag deze prestatie kosten, hoeveel materiaal mag het kosten, hoeveel geluid mag het maken? Terwijl de eisenanalysestap de functies, eigenschappen en beperkingen identificeert, kwantificeert de eisenspecificatiestap de eigenschappen.

Emerging properties

Dit is een onderdeel van de gestructureerde eisenanalysemethode en is een effectieve manier om de zogeheten emerging properties te ontdekken – eigenschappen waarom geen enkele belanghebbende heeft gevraagd, maar die een specifiek productaspect vertegenwoordigen als gevolg van keuzes die in het ontwerp zijn gemaakt.

De keuze voor een verbrandingsmotor geeft bijvoorbeeld geluid en giftige gasemissies als bijkomende eigenschappen. Sommige van deze eigenschappen kunnen ineens zeer belangrijk worden, kijk maar naar NO_x-emissie. Het punt is dat als een ontwerpkeuze eenmaal is gemaakt, je moet kijken naar de gevolgen (goede, slechte en lelijke) om te zien of er nieuwe eisen moeten komen om de emerging proporties te beheersen.

In de loop der jaren zijn de namen van de afdelingen productontwikkeling nogal eens veranderd, vooral de groepen die verantwoordelijk zijn voor het schrijven van de eisen op product- of systeemniveau. Van productdefinitie, via systeemengineering, zien we nu groepen (soms afdelingen) die zo heten dat het heel duidelijk is waar ze voor staan, zoals ‘product properties and customer functions’. Zo zegt ook de titel van Porsche’s Hansjörg Maier alles: ‘Leiter Produkt-Eigenschaften und Kunden-Funktionen’. Dit geeft een enorme focus op wat belangrijk is voor het product, zowel zijn functionaliteit als zijn eigenschappen, en wat het product onderscheidt van de concurrentie.

Cees Michielsen is trainer systeemrequirementsengineering bij High Tech Institute.