Inspiratie / Theorie · 20 oktober 2011

Weg met de eisenboom!

Ik ben langzamerhand steeds meer tot de conclusie gekomen dat twee concepten van Systems Engineering zoals in de GWW sector worden gehanteerd enige aanpassing verdienen. Dit zijn de eisenboom en de objectenboom. Ik ben benieuwd naar je reactie!

Eisenboom

Allereerst denk ik dat het hele concept ‘eisenboom’  zoals in de ‘Leidraad SE‘ helemaal is uitgewerkt, niet goed werkt. De termen boven- en onderliggende eisen lijken er op te wijzen dat onderliggende eisen inderdaad afgeleid kunnen zijn van bovenliggende eisen. Echter, op steeds ‘diepere lagen’ komen er óók  eisen aan het licht die niet afgeleid zijn van ‘bovenliggende’ eisen. Met wat gekunstel kun je het dan wel aan een bovenliggende eis koppelen, maar soms ook eigenlijk niet en komt de eis gewoon van een persoonlijke voorkeur of ervaring o.i.d. Denk aan een eis als ‘de leuningen moeten blauw van kleur worden’. Ik ben steeds meer aan het denken aan een eisen- en objectennetwerk. Ik weet nog niet hoe dat vorm gegeven of weergegeven moet worden, maar ik wordt er wel steeds enthousiaster over.

Ik heb het nog niet gedaan, maar ik denk aan de volgende oplossing: Als je het plaatje van de twee pyramides (eisenboom en objectenboom) zou integreren met elkaar en minder hiërarchisch zou maken, dan krijg je om en om een laag van eisen, dan een laag objecten, dan weer een laag eisen en dan weer objecten.  Mijn oplossing/suggestie is één structuur waarin beide zijn gecombineerd.

In onderstaand figuur uit de eerste leidraad SE is dit ook eigenlijk weergegeven. Let in de figuur op de locatie van het woord “Afleiden”.

Mijn uitleg bij de figuur is: Vanuit een bepaald ontwerp(keuze) (Lees: object) ga je nieuwe eisen opstellen. Dit hoeft niet per sé vanuit eisen te zijn, het kan dus ook vanuit een eerste gedachte over een object komen. Je gaat immers pas eisen aan een fundering stellen als er een fundering moet komen en niet eerder.

De reden hiervoor is dat als je een keus hebt gemaakt voor een bepaald systeem/object, dat je dan pas nieuwe eisen kunt afleiden voor de laag eronder. Die nieuwe eisen zorgen voor een oplossingsgebied met een keus voor een oplossing (=object). Aansluitend kun je weer de nieuwe eisen aan het onderliggende object benoemen. Op die manier is ook duidelijker tot waar je als opdrachtgever gaat in het zoeken (=medeontwerpen) naar oplossingen. Of andersom is het voor de opdrachtnemer beter om te zien tot waar de opdrachtgever is gebleven.

Een bijkomend voordeel is dat je op deze wijze mogelijk ook sneller ‘vanaf de plank’ oplossingen kunt aandragen. Een oplossing die aan alle eisen van de opdrachtgever voldoet en al eerder eens is toegepast, kan mogelijk snel geverifieerd worden en ingezet worden in het ontwerp. Ook dit wil ik nog nader onderzoeken.

Objectenboom

Daarnaast denk ik dat de boomstructuur van met name objecten minder hiërarchisch, maar meer als netwerk moeten worden weergegeven. We moeten duidelijker maken welke objecten relaties met elkaar hebben. Soms hebben objecten/systemen van verschilende diepteniveau’s namelijk een nauwe relatie met elkaar. In dat geval kun je ook een relatie tussen die twee objecten in een eis formuleren en duidelijker maken waaraan de oplossing dient te voldoen. Dit model zal de “raakvlakkenmatrix” vervangen.

 

Reacties!

Ik ben nog in de experimentele fase over het denken van deze beide concepten en heb het nog niet toegepast, maar ik ben benieuwd naar jouw meningen hierover.