Waarom hebben we deze eis en waarom heeft die deze waarde?

In de kern is het idee van traceerbare requirements echt cool: in staat zijn om top-down een requirement te volgen van zijn creatie tot zijn implementatie en de andere kant op, bottom-up van zijn implementatie tot zijn oorsprong. De meeste leerboeken geven goed uitziende diagrammen en tabellen die tonen hoe requirements zijn verbonden met andere requirements en testgevallen. Helaas hebben deze diagrammen en tabellen weinig te maken met de dagelijkse praktijk.

Systeemvereisten volgen de principes van systeemengineering. Neem een sluis in een kanaal. Op systeemniveau zal er een eis zijn die stelt dat de sluis het mogelijk moet maken dat boten stroomopwaarts en stroomafwaarts door het kanaal kunnen varen. Hoe moeten we dit uitsplitsen als we nog niet hebben besloten hoe we het probleem moeten oplossen, of in requirements-terminologie: 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 botenlift) tot de Nederlandse sluizen bij Eefde. Twee totaal verschillende oplossingen voor hetzelfde probleem. Dus, wat te doen met de traceerbaarheid van onze systeemeis?

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 in zijn eentje aan de systeemeis voldoen. Daarom hebben we de ontwerpbeslissingen nodig als ankerpunt in de requirementsflow (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 zal worden aan het niveau bij de geopende poort. Vervolgens kunnen de boten door de geopende poort de kamer binnenvaren. Daarom is een van de zogeheten afgeleide eisen voor het subsysteem poort dat het geopend en gesloten kan worden.

De vragen die we moeten beantwoorden en waarvoor we de bottom-up sporen nodig hebben, zijn: waarom hebben we deze eis en waarom heeft die deze waarde? De antwoorden kunnen alleen worden gevonden via sporen van de eisen op subsysteemniveau naar de ontwerpbeslissingen één niveau hoger, in ons geval het systeemniveau van de waterwegsluis.

Systeemingenieurs moeten ook rekening houden met de budgetten voor hulpbronnen, zoals massa, volume, energie, operationele ruimte en materiaalkosten. Al deze eisen komen op systeemniveau in de specificatie van eisen terecht als individuele eisen, maar ze worden nooit doorgegeven aan de subsystemen zonder ze in samenhang te analyseren, een ontwerp te maken dat rekening houdt met alle voor- en nadelen en uiteindelijk te beslissen welke oplossing het best aan deze systeemeisen voldoet.

In werkelijkheid zijn er veel afhankelijkheden tussen, in dit geval, de eisen aan de eigenschappen van hulpbronnen. Vooral in de automobielindustrie zijn massa en materiaalkosten twee voertuigeigenschappen die sterk met elkaar verweven zijn. Op systeemniveau wordt het totale massabudget vastgesteld: het voertuig moet minder dan 1500 kilo wegen, en dat geldt ook voor het materiaalkostenbudget: de totale materiaalkosten mogen niet meer dan 7000 euro bedragen. Vervolgens wordt, voor het geval moeilijke beslissingen moeten worden genomen, een prioriteit bepaald, bijvoorbeeld minder gewicht is belangrijker dan materiaalkosten.

Het ontwerp op systeemniveau probeert hiervoor een oplossing te vinden en wijst budgetten toe voor massa en materiaalkosten, waarbij deze eisen tegen elkaar worden afgewogen en tegelijkertijd wordt uitgegaan van bepaalde capaciteiten van de subsystemen die aan deze budgetten bijdragen. Ten slotte, wanneer een beslissing is genomen voor een oplossing, worden delen van de budgetten voor massa en materiaalkosten toegewezen aan de subsystemen.

Als u verantwoordelijk bent voor een van deze subsystemen en u krijgt een massabudget van 100 kilo, waar zou u dan antwoorden zoeken op de vragen: waarom heb ik een massabudget en waarom is het 100 kilo?