Trend 3: Traceerbaarheid

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?