Van Twin Peaks naar Twin Pines

Vorige week schreef ik een artikel over ‘Context en Requirements Structuur’, in een serie artikelen rondom het thema Requirements en Requirements Engineering.

In dat artikel verwees ik naar het Twin Peaks model. Maar toen ik daar nog eens goed over nadacht, realiseerde ik me dat die ‘peaks’ meer verweven zijn dan het model doet vermoeden. Reden dus om daar wat dieper op in te gaan.

Requirements Structuur en Architectuur

In mijn vorige artikel over Context en requirements structuur beschreef ik al de aanleiding. In een high-tech multidisciplinaire en complexe omgeving was ik op zoek naar een manier om de requirements te structuren. Nadat ik daar de contextuele lagen had afgepeld kon ik me past echt focussen op de requirements structuur.

Uiteindelijk kwam ik tot de conclusie dat de top-down gelaagdheid (systeem, subsysteem en verder) de meest voor de hand liggende en ook de best passende structuur was.

Tijd dus om daar dieper in te duiken en de structuur te gaan bepalen.

Twin Peaks

In het “Handbook of Requirements Modeling According to the IREB Standard“ wordt de relatie tussen ‘Requirements models’ en ‘Ontwerp (Design) model’ beschreven en ge?llustreerd met het ‘Twin Peaks model’ van Bashar Nuseibeh, professor aan de Open University UK and Lero, en the Irish Software Engineering Center.

Doel van de figuur is aan te geven dat er tijdens de ontwikkeling van complexe softwaresystemen een sterke interactie is tussen de definitie van eisen en het systeemontwerp.

Het begint met de vraag, of negatiever uitgedrukt: het probleem, dat leidt tot de algemene requirements. Logischerwijs de eerste stap. Op basis daarvan wordt er nagedacht over de oplossingsrichting, worden ontwerpbeslissingen genomen en ontstaat een eerste definitie van de systeemarchitectuur.

Zo’n initi?le systeemarchitectuur bestaat meestal uit (logische of op functionaliteit ingedeelde) subsystemen. Die leiden dan tot eisen / requirements voor de afzonderlijke subsystemen.

Voor complexe systemen, zoals uit mijn context, herhalen deze stappen zich nog enkele keren, tot men op het laagste niveaus is aangekomen: de software unit requirements.

Heet dat altijd software unit requirements? Uhm, neen, ook dat is afhankelijk van de context, maar omdat bijvoorbeeld in de medische en ook in de automotive industrie een unit als kleinste onderdeel wordt beschouwd door verschillende internationale standaarden, hanteer ik hier die naam.

Sterke interactie

Zoals al aangegeven is het doel van de figuur de sterke interactie aan te geven. Ontwerpbeslissingen op het ene niveau hebben een aanzienlijke invloed op de requirements op het volgende lagere detailniveau. Sterker nog, de requirements op het volgende niveau zijn gebaseerd op de eerder genomen ontwerpbeslissingen, en zo verder tot mogelijk op het laagste niveau. Daarin schuilt ook een grote valkuil, welke ik hieronder nog nader benoem.

Twin Pines

IREB schrijft dat het des te belangrijker is het om het requirementsmodel strikt te scheiden van het ontwerp (design) model.

OK, ik ben het er mee eens dat requirements en ontwerp (design) sterk verschillend zijn en niet door elkaar gehaald moeten worden. Iets wat ik in de praktijk vaker heb gezien. Maar naar mijn mening zijn deze documenten sterker met elkaar verbonden dan de figuur van Bashar doet vermoeden.

Ik ben dan eigenlijk ook meer een voorstander van de metafoor van twee bomen die naast elkaar staan, waarvan de takken in elkaar groeien: Twin Pines.

Structurering en architectuur

Ogenschijnlijk zou de scheiding tussen requirements en design duidelijk moeten kunnen zijn. Zeker initieel. Maar niet elk systeem wordt als complex systeem geboren. In veel gevallen begint het met een wens, eis of idee, waarvoor een oplossing wordt bedacht. Denk daarvoor nog even terug aan veel ‘stand alone’ applicaties uit de jaren 90.

Maar steeds meer systemen integreren, nieuwe technieken en mogelijkheden komen beschikbaar, waardoor de initi?le ontwerpen niet meer voldoen maar wel nog blijven voortbestaan als legacy. En niet elk systeem leent zich voor een grondig re-design omdat het te grote investering in tijd en geld vraagt, waarin bijvoorbeeld geen nieuwe dingen ontwikkeld kunnen worden.

En dat brengt me eigenlijk ook weer terug naar de context uit mijn vorige artikel, want naast deze integratie of innovatie, hebben ook organisatorische indeling, de communicatie over innovatie, afhankelijkheden in systeemgedrag en de systeemontwikkelmethode in de loop der jaren zo hun effecten op ontwerp en requirements gehad.

Climbing the Twin Pines: Open Challenges

In een artikel van IEEE Software: The Twin Peaks of Requirements and Architecture, wordt ook een aantal uitdagingen benoemd. Hoewel uit 2012, nog steeds relevant: 

• Communicatie. Veel projecten, en zeker bij complexe systemen is communicatie tussen analisten en architecten moeilijk, zeker als het over meerdere architectuurlagen heen gaat.
• Architectuurkennis en ontwerpbeslissingen worden niet altijd voldoende of goed vastgelegd, laat staan onderhouden, waardoor na langere tijd onderhoud of innovatie lastiger wordt.
• Visualisatie van de architectuur ontbreekt. De architectuur van het software systeem is , net als in mijn context, complex en er is geen of te weinig inzicht bij de verschillende stakeholders, onder andere door de vele lagen, disciplines en afhankelijkheden.
• Requirementskennis en vastlegging. Van veel systemen worden minder of te weinig requirements vastgelegd, laat staan onderhouden. “Working product over comprehensive documentation” wordt soms te letterlijk genomen, waarbij het woord ‘comprehensive’ (uitgebreide) voor het gemak wordt weggelaten.
• Evolutie in agile omgevingen. Software en architectuur groeien en veranderen continu door de iteratieve requirements en ontwerpprocessen en de filosofie van ‘embrace change’. Impactanalyse is moeilijk en wordt steeds belangrijker.
• Traceerbaarheid. De mogelijkheid om relaties tussen verschillende artefacten vast te stellen en te begrijpen, wordt steeds belangrijker. Ook in industrie?n waar dit niet door veiligheid en/of het bedrijfskritisch zijn van systemen wordt afgedwongen.
• Opleiding. Educatie in software-engineering gaat niet altijd direct in op de onderlinge afhankelijkheid tussen requirements en architecturen. Tijdens hun opleiding en in het begin van hun carrière werken studenten vaak maar aan één deel van het systeem tegelijk.
• Abstractieniveau. Geen onderwerp uit het artikel maar wel een veel voorkomende valkuil: detailrequirements op een te hoog (requirements)niveau vastleggen. Het beperkt de ontwerpers om op het juiste niveau de oplossingsrichting te kiezen. Een voorbeeld? Een medisch apparaat dat mobiel moet kunnen werken. Op systeemniveau werd al gespecificeerd dat het op een batterij moest werken. Ogenschijnlijk een logische keuze, maar wellicht was men op een laag technisch niveau tot een betere oplossing (zonnepaneel bijvoorbeeld) wat per definitie door het batterij-requirement werd uitgesloten.

Uitdagingen genoeg dus, maar daarover gaan we graag met u in gesprek, om deze en andere valkuilen of uitdagingen te lijf te gaan.

Samenvattend

Naast de complexiteit van de context uit mijn vorige artikel, liggen er ook op het vlak van architectuur en requirementsstructuur dus nog de nodige uitdagingen.

Wanneer je met een schone lei kunt beginnen, is ontwerpen relatief eenvoudig. Maar een bestaand ontwerp aanpassen vraagt de nodige aandacht. Wat mij betreft staat de foto boven dit artikel (en hieronder) van het Lethbridge Viaduct in Alberta Canada daar symbool voor. In een complexe en sinds 1909 werkende constructie als deze, maak je ook niet zomaar een bocht. Dat zou geheid tot een compleet nieuw ontwerp en nieuwbouw leiden (met alle gevolgen van dien: economisch, ecologisch, technisch, beschikbaarheid, etc.).

En wederom is belangrijk om de requirements structuur helder te hebben alvorens te kiezen voor hoe de requirements te documenteren. Voor inrichting van documentatie en tooling, maar meer nog voor communicatie, inzicht, onderhoud en innovatie.

De verwevenheid van ontwerp en requirements is dus een belangrijk aandachtspunt. Enerzijds is er de sterke band, anderzijds moeten ze niet door elkaar gehaald worden. Misschien is Twin Peaks dan toch meer geschikt dan Twin Pines?

De ‘pines’ lenen zich wel beter om een brug te slaan naar de komende feestdagen??:

De Requirements Engineering consultants van @Improve Quality Services wensen je fijne feestdagen en een beter 2021!

En in januari 2021 vervolgen we de reeks van artikelen. 

Dit artikel is een artikel in de reeks over het veelzijdige vak van Requirements Engineering waarbij de komende maanden iedere week een collega van Improve Quality Services de lezer meeneemt in de zaken waar de Requirements Engineer vandaag de dag tegenaan loopt. Elk artikel zal herkenbaar zijn aan de brug, de verbinding tussen twee oevers, die symbool zal staan voor ons vak: de verbinding tussen twee partijen die goed willen samenwerken, door goed te communiceren en die wij daar graag in willen helpen.  

Met dank aan @Niels Duisters voor de kerstversiering.