Trend 1: Je systeemvereisten compleet krijgen

Een vraag die in bijna al mijn lessen over systeemvereisten opduikt, is: hoe kunnen we ervoor zorgen dat onze specificatie van vereisten volledig is? Dit is een terechte vraag. Ontbrekende requirements betekent meestal dat we mogelijkheden missen van de producten die we ontwikkelen. Dat heeft gevolgen voor het succes van die producten. Ofwel zijn de gebruikers van een product teleurgesteld omdat ze iets verwachtten dat niet geleverd wordt, ofwel is het product niet competitief genoeg in vergelijking met andere producten met vergelijkbare functionaliteit.

De praktijk wijst uit dat eisenspecificaties zelden volledig zijn. Het is gewoon erg moeilijk om ze compleet te maken en te houden. Gelukkig hebben we in de afgelopen decennia een aantal technieken en methoden geleerd die ons kunnen helpen in ons streven naar volledigheid.

Ten eerste werken sjablonen en checklists echt. Ze stammen uit de begindagen 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 staat vol met checklists die speciaal gericht zijn op requirements.

Je moet zelf ook wat graven: zoek alle belanghebbenden met een potentiële impact op het succes van het product. Stakeholders vergeten betekent vaak dat je ook hun behoeften en verwachtingen van de mogelijkheden van het product niet zult vastleggen. Dat is een recept voor mislukking. Natuurlijk moet je je stakeholders bevragen en uitdagen om erachter te komen wat hun echte behoeften zijn. Het helpt ook om deze behoeften expliciet te maken. Nodig de brandweer niet uit wanneer je een nieuw gebouwde tunnel in gebruik neemt om er vervolgens achter te komen dat je misschien een aantal essentiële veiligheidsmaatregelen over het hoofd hebt gezien. Je moet de brandweer al in een vroeg stadium betrekken bij het verzamelen van eisen.

Zorg ervoor dat je het te bouwen product vanuit verschillende perspectieven bekijkt. Bekijk het door de ogen van daadwerkelijke gebruikers, eigenaren en investeerders. Betrek ook belanghebbenden die ook de negatieve effecten ervaren. Deze perspectieven kunnen soms het beste worden beschreven in een concept of operations, user stories, use cases en scenario’s.

Realiseer je dat de requirements elicitation stap (waar je stakeholders en hun behoeften identificeert) plaatsvindt op elk decompositie niveau van je productarchitectuur voor elk systeemelement! Op elk niveau vind je nieuwe belanghebbenden die specifiek zijn voor dat systeemelement op dat niveau. Denk aan software coderingsstandaarden in een multidisciplinair product.

Analyseer de behoeften op een gestructureerde manier. Dit betekent onderscheid maken tussen de hoofdfunctie van een product en zijn subfuncties, tussen een functie, zijn eigenschappen en zijn ontwerpbeperkingen. Uiteindelijk moet je een balans vinden tussen de eisen die functies stellen aan prestaties en resource-eigenschappen.

Als we een personenauto als voorbeeld nemen en zeggen dat “mensen vervoeren” de belangrijkste functie 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 resource-eigenschappen, zoals: hoeveel energie mag deze prestatie kosten, hoeveel materiaal mag het kosten, hoeveel lawaai? Terwijl de analyse de functies, eigenschappen en beperkingen identificeert, kwantificeert de specificatiestap de eigenschappen.

Dit maakt deel uit van de gestructureerde methode voor eisenanalyse en is een van de effectieve manieren om de zogenaamde opkomende eigenschappen te ontdekken – eigenschappen waar geen enkele belanghebbende om heeft gevraagd, maar die een specifiek productaspect vertegenwoordigen als gevolg van keuzes die tijdens het ontwerp zijn gemaakt. Bijvoorbeeld, de keuze voor een verbrandingsmotor geeft geluid en uitstoot van giftige gassen als opkomende eigenschappen. Sommige van deze opkomende eigenschappen kunnen plotseling heel belangrijk worden na lange tijd genegeerd te zijn, zoals we hebben gezien bij de NOx-uitstoot. Het punt is dat als er eenmaal een ontwerpkeuze is gemaakt, je moet kijken naar de gevolgen (goed, slecht en lelijk) om te zien of er nieuwe vereisten moeten worden opgesteld om de opkomende eigenschappen te beheren.

In de loop der jaren zijn de namen van de productontwikkelingsafdelingen nogal veranderd, vooral de groepen die verantwoordelijk zijn voor het schrijven van de requirements op product- (of systeem-) niveau. Van productdefinitie via systeemengineering zien we nu groepen (soms afdelingen) die zo heten dat het heel duidelijk is waar ze voor staan, zoals “Producteigenschappen en klantfuncties”. Op dezelfde manier zegt de titel van Hansjörg Maier van Porsche alles: “Leiter Produkt-Eigenschaften und Kunden-Funktionen.” Dit geeft een enorme focus op wat belangrijk is voor het product, zowel de functionaliteit als de eigenschappen, en wat het product onderscheidt van de concurrentie.