Maand: juli 2022

Het principe van traceerbare requirements is echt cool: in staat zijn om zowel top-down een requirement te volgen vanaf de creatie tot de implementatie en bottom-up vanaf de implementatie tot de oorsprong. De meeste handboeken geven mooie diagrammen en tabellen die laten zien hoe requirements zijn gekoppeld aan andere requirements en testgevallen. Helaas hebben deze diagrammen en tabellen weinig te maken met de dagelijkse praktijk.
Systeemeisen volgen systems engineering principes. Laten we het voorbeeld nemen van een sluis. Op systeemniveau zal er een vereiste zijn die stelt dat de sluis boten in staat moet stellen om stroomopwaarts en stroomafwaarts door het kanaal te varen. Hoe kunnen we dit opsplitsen als we nog niet hebben besloten hoe we het probleem gaan oplossen, of in de terminologie van eisen: hoe kunnen we aan deze eis voldoen?
In de praktijk zien we een grote verscheidenheid aan oplossingen, van het prachtige Schotse Falkirk Wheel (een echte bootlift) tot de Nederlandse sluizen bij Eefde. Twee totaal verschillende oplossingen voor hetzelfde probleem. Dus wat te doen met de traceerbaarheid van onze systeemvereisten?
In het geval van Eefde bestaat een sluis uit twee poorten en een kamer. Elk onderdeel heeft zijn eigen mogelijkheden, maar geen van de onderdelen kan alleen aan de systeemvereisten voldoen. Daarom hebben we de ontwerpbeslissingen nodig als ankerpunt in de eisenstroom (top-down, eis naar ontwerpbeslissing naar eis) en in de trace-back (bottom-up). Door het ontwerp begrijpen we dat wanneer we een van de poorten openen, het waterniveau in de kamer gelijk wordt aan het niveau bij de geopende poort. Vervolgens kunnen de boten door de geopende poort de kamer in varen. Daarom is een van de zogenaamde afgeleide eisen aan het poortsubsysteem dat het geopend en gesloten kan worden.

[Courseinstructor heading=”‘Waarom hebben we deze vereiste en waarom heeft het deze waarde?'”.

De vragen die we moeten beantwoorden en waarvoor we de bottom-up sporen nodig hebben zijn: waarom hebben we deze eis en waarom heeft het deze waarde? De antwoorden kunnen alleen worden gevonden via sporen van eisen op subsysteemniveau naar de ontwerpbeslissingen een niveau hoger, in ons geval het systeemniveau van de sluis.
Systeemingenieurs hebben ook te maken met budgetten voor middelen, zoals massa, volume, energie, operationele ruimte en materiaalkosten. Al deze zaken komen in de specificatie van eisen op systeemniveau als individuele eisen, maar ze worden nooit doorgegeven aan de subsystemen zonder ze in samenhang te analyseren, een ontwerp te maken dat alle voors en tegens in overweging neemt en uiteindelijk te beslissen welke oplossing het beste voldoet aan deze systeemeisen.
In werkelijkheid zijn er veel afhankelijkheden tussen, in dit geval, de eisen aan middeleneigenschappen. Vooral in de auto-industrie zijn massa en materiaalkosten twee voertuigeigenschappen die sterk met elkaar verweven zijn. Op systeemniveau wordt het totale massabudget vastgesteld: het voertuig moet minder wegen dan 1.500 kg, en hetzelfde geldt voor het materiaalkostenbudget: de totale materiaalkosten mogen niet hoger zijn dan 7.000 euro. Vervolgens wordt, als er moeilijke beslissingen moeten worden genomen, een prioriteit bepaald, bijvoorbeeld minder gewicht is belangrijker dan materiaalkosten.
Het ontwerp probeert hier een oplossing voor te vinden en wijst budgetten toe voor massa en materiaalkosten, waarbij deze vereisten in evenwicht worden gebracht en tegelijkertijd wordt uitgegaan van bepaalde capaciteiten van de subsystemen die bijdragen aan deze budgetten. Uiteindelijk, wanneer een beslissing is genomen voor een oplossing, worden delen van de budgetten voor massa en materiaalkosten toegewezen aan de subsystemen.
Als je verantwoordelijk bent voor een van deze subsystemen en je krijgt een massabudget van 100 kg, waar zou je dan zoeken naar antwoorden op de vragen: waarom heb ik een massabudget en waarom is het 100 kg?

Kunnen we objectief zeggen dat een vereiste van goede kwaliteit is? Wat zou de maatstaf voor goed zijn? Bestaat er zoiets als ‘goed genoeg’? De meeste antwoorden op deze vragen zijn te vinden in het werk van Philip Crosby, William Edwards Deming en Joseph Juran. Deze drie kwaliteitsgoeroes zijn niet meer onder ons, maar hun ideeën blijven een grote bron van inspiratie.

Aangezien requirements het resultaat zijn van een requirements engineering proces, lijkt het logisch om te controleren of een requirement voldoet aan de doelen van het proces. Ten eerste zijn de behoeften van de belanghebbenden vastgesteld en ten tweede is een correcte en volledige overgang van de behoeften van de belanghebbenden gewaarborgd tot het decompositieniveau waarop de eisen kunnen worden geïmplementeerd in hardware- of softwarecomponenten. Ik zal me hier richten op het tweede doel.

Er wordt onderscheid gemaakt tussen intrinsieke en extrinsieke requirementskwaliteit. Intrinsiek betekent dat de kwaliteit van een requirement wordt bepaald door de manier waarop het is gedocumenteerd of gepresenteerd aan de lezer – de syntax van de requirement. Dit kan puur tekstueel zijn of verfraaid met afbeeldingen, tabellen en meer. De controle kan in theorie worden uitgevoerd door personen of applicaties zonder kennis van het onderwerp. Ze hoeven niet te begrijpen waar de eis over gaat, maar ze moeten eerder kijken of het in strijd is met de regels voor het schrijven van eisen. Deming spreekt van “trots op vakmanschap” en “goed opgestelde eisen”. In de loop van de laatste 10-15 jaar zijn softwaretools om deze kwaliteitscontroles te ondersteunen steeds geavanceerder geworden. In tools zoals QVScribe zijn checklists zoals de Writing Requirements richtlijn van de International Council on Systems Engineering (Incose) volledig ingebed en intrinsieke kwaliteitscontroles zijn volledig geautomatiseerd (inclusief diverse requirements templates zoals EARS en IREB).

Merk op dat de intrinsieke kwaliteit slechts een derde van de totale kwaliteit van de vereisten dekt. Maar de intrinsieke kwaliteitscontroles hebben wel degelijk waarde. Als ze worden uitgevoerd en correcties worden aangebracht voordat de requirement wordt beoordeeld door materiedeskundigen en relevante belanghebbenden, kunnen deze tools tijd besparen en inderdaad nuttig zijn om de kwaliteit van requirements te verbeteren.

Maar tools helpen je niet om te bepalen of je requirement zinvol is voor het beoogde publiek. Dit is waar de extrinsieke kwaliteit van requirements om de hoek komt kijken. Het is van toepassing in twee richtingen: terug naar de belanghebbenden die vroegen om een specifieke eigenschap van het te ontwikkelen product of een productkenmerk of gedrag (het bronpubliek), en vooruit naar de ontvangers van de vereiste (het doelpubliek).

Laten we eens kijken naar de volgende eis: “De reactiesnelheid van het systeem mag niet groter zijn dan 0,5 ms.” Deze eis zal waarschijnlijk met vlag en wimpel door de geautomatiseerde kwaliteitscontroles komen. In de praktijk wordt deze eis vaak geformuleerd als: “Systeemresponsiviteit: ≤ 0,5 ms.” Zou je zeggen dat deze eisen van gelijke kwaliteit zijn? Vanuit een syntactisch perspectief zal de eerste een hogere score opleveren omdat deze een richtlijn bevat, maar pas als we het de relevante belanghebbenden vragen, hebben we enig idee of de bedoelde betekenis correct is vertaald.

[Courseinstructor heading=”‘equirements engineers moeten hun eisen laten controleren en beoordelen.'”

Kwaliteit is conformiteit aan de vereisten, zegt Crosby. Hebben wij, als requirements engineers of business analisten, de behoefte van de stakeholder correct vertaald naar een systeemvereiste? Dit kan alleen worden beantwoord door de belanghebbenden die de oorspronkelijke behoefte hebben geformuleerd. Dus requirements engineers moeten hun requirements laten controleren en beoordelen – een activiteit die als moeilijk wordt ervaren.

Stel dat de klant zegt dat de ingenieur het verzoek niet heeft begrepen? Of dat hij het punt volledig heeft gemist? Zulke feedback is niet altijd prettig en dat zorgt ervoor dat een requirements engineer deze confrontaties uit de weg gaat. Hij neemt vaak de veilige weg door contact op te nemen met iemand van het project om de klant of stakeholder te vertegenwoordigen.

Dat is geen slimme houding. We willen er zeker van zijn dat we de behoeften van de belanghebbenden hebben begrepen en dat we ze correct en volledig hebben vertaald in vereisten. Daarom is er geen andere manier dan deze moeilijke vragen direct te stellen.

Kwaliteit is geschiktheid voor het doel, zegt Juran. Requirements moeten voldoende informatie en details bevatten voor ontwerpers om oplossingen te bedenken. Van de requirements wordt verwacht dat ze gekwantificeerd zijn zodat testers de succesvolle implementatie ervan kunnen verifiëren en valideren. Kortom, ze moeten duidelijk, ondubbelzinnig en zinvol zijn en voldoende gedetailleerd voor degenen die de vereisten ontvangen als input voor hun werk.

Ik heb gevallen gezien waarin er geen documentatie over vereisten bestond tussen een OEM en een van zijn leveranciers van onderdelen. Alleen een mondelinge overeenkomst. Hoewel dit in sommige culturen een onaanvaardbare situatie lijkt, werden de doelen van het requirements engineering proces gehaald. De leverancier levert het onderdeel nu al meer dan twaalf jaar met constante kwaliteit tot tevredenheid van de klant.

Wat zou jij doen in dit soort situaties? Hoe kijk je aan tegen de kwaliteit van requirements in jouw bedrijf? Hoe zou jij omgaan met behoeften van stakeholders zoals “ik wil dat de volgende versie van de auto energiezuiniger is”? Ik hoor graag van je, om te leren en door te geven.

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.