Context en requirements structuur

Vorige week schreef collega @Kaspar van Dam een artikel over ‘Shared Understanding’, in een serie artikelen rondom het thema Requirements en Requirements Engineering.

Nu we enige shared understanding hebben over wat Shared Understanding is, pak ik de handschoen daar op en neem jullie mee naar een complexe omgeving waar ik samen met enkele architecten stoeide met de vraag hoe de requirements te structureren. In tegenstelling tot Shared Understanding is er over hoe requirements te structureren niet zo veel over te lezen. Waarschijnlijk omdat dit zeer context afhankelijk is. Hoe ontwarren we die context, om vervolgens de pure requirements te kunnen structureren?

Context

Als ik de IREB syllabi en handbooks doorzoek op Context analysis, dan wijst alles naar de systeem context. Letterlijk:

De potenti?le aspecten van de systeemcontext omvat onder andere: Personen, Bestaande systemen, Processen, Gebeurtenissen en Documenten. De contextgrens kent ook een grijze zone. Deze bestaat uit de ge?dentificeerde aspecten van de omgeving waarvoor, op een bepaald moment, het onduidelijk is in hoeverre deze aspecten een relatie hebben met het geplande systeem of niet.

Deze context richt zich met name op hoe het systeem moet werken of reageren, welke interfaces er moeten zijn en wie de gebruikers zijn. Use case- en dataflow diagrammen worden genoemd als vormen van documentatie.

Maar dit is niet de context waar ik naar op zoek was. Mijn context was een complexe omgeving die, naast een high-tech multidisciplinair systeem (hardware (elektronica), software, mechanica) ook bestond uit een internationale en historisch gegroeide organisatiestructuur die, los van het systeem, effect heeft op de wijze van requirements engineering. En daar gaan de syllabi niet op in. Ik kom daar zometeen op terug.

Structurering en architectuur

Door de groeiende complexiteit en de omvang van het systeem had ik steeds meer behoefte om de requirements beter te structureren. Ofwel: hoe de-componeer ik het systeem zodat er een soort gelaagde structuur van requirements ontstaat?

Zoekend in de literatuur op de term structuur (en varianten daarvan) kom ik al snel uit in document structuren, ofwel: hoe zou een requirements document eruit moeten zien. Of het heeft betrekking op ‘views’ op requirements en het modelleren van requirements, bijvoorbeeld in UML.

Combining and Decomposing Functions, and Ensuring Consistency komt het meest in de buurt, maar biedt eigenlijk geen richting naar vormen of structuren hoe dit te doen. Ook de verwijzing naar het ‘Twin Peaks Model’ gaat niet verder dan dat er een relatie is tussen architectuur en requirements, maar daar kom ik in een volgend artikel op terug. Suggesties of voorbeelden van decompositie-strategie?n heb ik niet kunnen vinden.

Vanuit mijn testcompetentie ben ik goed bekend met het V-model, waarbij een functioneel ontwerp eigenlijk het best in de buurt komt van wat ik zocht: een systeem wordt opgedeeld in deelsystemen, die zo nodig weer verder worden opgedeeld in meerdere lagen. Vanwege de complexiteit en omvang van het systeem zijn ‘views op requirements’ zoals IREB die kent niet toereikend.

V-model? Dat klinkt wel heel traditioneel, nu veel organisaties agile werken, maar een link naar volgordelijkheid is nu niet van toepassing als ik de gelaagde structuur wil gebruiken. Niemand stelt dat de requirements volledig verdeeld moeten zijn voordat de volgende stap in de ontwikkeling gezet kan worden.

Bij gebrek aan beter, heb ik deze gelaagde structuur als uitgangspunt gebruikt.

In mijn ervaring gebeurt de decompositie van zulke complexe systemen meestal door een of meer (systeem)architecten. In de context van mijn zoektocht, waren er vanwege de complexiteit meerdere lagen van requirements en daarmee ook op meerdere niveaus architecten actief. Met hen was ik in gesprek om de decomposities en niveaus inzichtelijk te krijgen en op basis daarvan de beste strategie voor requirements structurering te bepalen.

Nog meer ‘lagen’?

Hoewel ik verwacht had dat inzicht vlot te kunnen krijgen, kostte dat meer moeite dan verwacht. En dat kwam niet alleen door de verschillende lagen van requirements…

En hier komt de context weer terug:

Mijn verwachting was dat elke decompositie vergezeld gaat van een ontwerp (design) stap, waarbij de keuzes worden vastgelegd en de keuzes leiden tot (detail)requirements op de volgende onderliggende laag van requirements. De verschillende lagen van requirements worden wel onderkend en ook de decomposities worden gemaakt, maar de rationales werden niet altijd vastgelegd.

Gaandeweg het optekenen werden er ook veel discussies gevoerd over hoe de organisatie was ingericht. Ogenschijnlijk lijkt die deels de decompositie te volgen, maar een-op-een was dat zeker niet.

Vervolgens kwamen afhankelijkheden in systeemgedrag ten tonele inclusief de bijbehorende datacommunicatie. Je voelt hem al aankomen: die liepen zeker niet strikt volgens de systeemdecompositie en hi?rarchie. Berichten en afhankelijkheden werden via interfaces afgehandeld en liepen kris-kras door het systeem.

De techniek stond en staat niet stil. Op verschillende lagen kwamen nieuwe technieken beschikbaar en zo kon een verbeterde hardwarecomponent er voor zorgen dat de requirements en software niet alleen in de directe omgeving maar ook op andere lagen aangepast moest worden.

Deze software ontwikkeling gebeurde in een agile SAFe omgeving. Er was onder andere sprake van epics, features en users stories. En door sommige populaties werden user stories als requirements gezien. Echter een users story is vluchtig en is in feite alleen het vehikel om tijdens een sprint uitgewerkt te worden tot een bruikbaar en werkend product.

Dat impliceert, maar wil ik hier expliciet maken: dat de requirements welke onderdeel zijn van de sprint, er voor óf minimaal tijdens de sprint duidelijk moeten zijn en zeker aan het einde van de sprint ook vastgelegd moeten zijn. Bijgewerkte requirements zouden moeten een onderdeel zijn van de Definition of Ready, en zeker van de Definition of Done. Zoals al vermeld bij het V-model, hoeven de requirements dus niet persé op voorhand volledig uitgewerkt te zijn. Requirements worden een continu levend geheel, maar daar komt @kaspar vast nog op terug als we verder ingaan op Living Documentation.

Met andere woorden: naast de gelaagdheid in requirements waren er ook nog diverse ‘lagen’ in de context die de discussie niet eenvoudig maakten.

Hoe te komen tot de juiste structuur?

De les die ik uit voorgaande heb geleerd is dat de top-down gelaagdheid (systeem, subsysteem en verder) niet alleen voor de hand liggend, maar ook de best passend structuur was.

Maar voordat ik tot die conclusie kwam heb ik de context goed moeten afpellen.

De decompositie en requirements structuur kon pas écht goed besproken worden nadat de be?nvloedende factoren zijn onderkend, zoals de organisatorische indeling, de communicatie over innovatie, afhankelijkheden in systeemgedrag en de systeemontwikkelmethode.

Pas na het ontleden van de context kan men zich richten op de kern: de requirements structuur.

Het is belangrijk om de requirements structuur helder te hebben alvorens te kiezen voor hoe de requirements te documenteren: in documenten of in een tool. Deze structuur heeft grote invloed op hoe vervolgens bijvoorbeeld een tool in te richten. Daar komt één van de collega’s later op terug in het vervolg van deze 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.