Modellen om te bouwen (5)

Om te beginnen wil ik iedereen het beste wensen voor 2021. Dat het jullie zowel privé als zakelijk brengt wat jullie in gedachten hebben.

Als afsluiting van 2020 heeft collega Patrick Duisters in een tweetal artikelen (Context en requirements structuur en Van Twin Peaks naar Twin Pines) uiteengezet wat zijn ervaring is met requirements in complexe omgevingen, structurering van requirements en de verwevenheid van requirements en ontwerpen. In dit artikel wil ik een lans breken voor het gebruiken van modellen in de fase van projecten waarin requirements worden verzameld en vastgelegd.

In complexe omgevingen hebben we vaak te maken met grote hoeveelheden requirements. Gelaagdheid van producten en systemen en verschillende dimensies van waaruit we naar een product of systeem kunnen kijken. Met een beetje geluk zijn deze requirements netjes vastgelegd in een tool, voorzien van een categorisering en aan elkaar gelinkt indien van toepassing. Helaas. De requirements zijn terug te vinden in een verzameling documenten of spreadsheets. Ook in Wiki achtige web omgevingen of een omgeving die we toch al hebben waarin we het werk voor de ontwikkelaars vastleggen (meer over het goed inzetten van tools en wat wil je nu eigenlijk vastleggen over en bij requirements in artikelen later in deze serie). Voor de personen die aan deze manier van vastleggen van requirements hebben meegewerkt, kan het zijn dat hier best nog chocolade van te maken is. Voor eenieder die daar niet direct bij betrokken is geweest, maar waarvan wel verwacht wordt dat ze iets met de requirements gaan doen, wordt dat al een stuk lastiger. Dit is het eerste voordeel wat aangegeven kan worden voor het gebruiken van modellen: het aanbrengen van structuur en overzicht.

In diverse IREB syllabi en handbooks wordt dit ook onder de aandacht gebracht. IREB geeft daarin aan dat voor het vastleggen van requirements het beste een combinatie gebruikt kan worden van natural language en modellen. Op Advanced niveau is aan modellen en modelleren zelf een hele module gewijd. Voldoende aanleiding om hier wat verder op in te gaan.

Meer voordelen

Binnen veel organisaties en projecten worden modellen al wel gebruikt. Met het toepassen van modellen start men dan vaak in de ontwerp fase. Om gewenst functioneel gedrag te beschrijven worden Use Case en/of activity diagrams gebruikt. Wanneer er sprake is van het moeten vastleggen van gegevens, modellen als entity relationship of class diagrams. Is het een meer technisch geori?nteerde omgeving dan worden modellen als sequence diagrams en/of state transition diagrams gebruikt. Wanneer modellen, gebruik makend van daarvoor geschikte tools, in de ontwerp fase opgesteld worden, kunnen deze gebruikt worden om vanuit het tool een implementatie van het product of systeem te maken (geheel of gedeeltelijk automatisch). Een duidelijk voordeel van modellen en bijbehorende tools in deze fase van ontwikkeling. Maar waarom zouden we niet eerder starten met het gebruiken van modellen?

Cre?ren van structuur en overzicht is een voordeel dat kan worden weergegeven. Er zijn meer voordelen aan te geven. Wanneer natural language wordt gebruikt, is het een uitdaging om op eenduidige, niet ambigue wijze, voor alle gebruikers van de requirements, deze vast te leggen. Modellen kunnen hierbij helpen. Modellen gebruiken altijd een bepaalde invalshoek van waaruit naar het te ontwikkelen product of systeem wordt gekeken. Gewenst functioneel gedrag, vastleggen van gegevens en gedrag bij gebruik werden al aangegeven. Daarbij is de woordenschat waaruit geput kan worden beperkter en daarmee overzichtelijker. Vele malen eenvoudiger vanuit syntactisch en semantisch oogpunt in vergelijking met natural language. Een model is daardoor, mits men de ‘taal’ begrijpt, op eenduidige wijze uitlegbaar.

Het visuele aspect van modellen kan ook een belangrijke rol spelen. Mensen zijn vaak visueel ingesteld; geef ze een visuele representatie en ze zijn veel beter in staat om daar een oordeel over te geven of aan te geven wat ontbreekt. Het spreekt mensen aan en geeft een startpunt om op basis van een model verdere gesprekken aan te gaan. Gelaagdheid in te ontwikkelen producten of systemen, kunnen we ook visualiseren in modellen. Data flow en state transition diagrams hebben dit in zich. Use case diagrams in mindere mate (al wordt dat binnen use cases deels ondervangen door de use case specifications waarin via natural language een verdere detaillering aangebracht kan worden). Hiermee zijn we dus in staat om overzicht en structuur aan te brengen door deze te visualiseren.

Als laatste, wanneer we in de requirements fase starten om zaken vast te leggen in modellen, kunnen we deze modellen op eenvoudiger wijze omzetten naar modellen die we in de ontwerp fase kunnen gebruiken. Omdat we al eerder gestart zijn met de modellen, er daardoor door meer maar ook vooral andere mensen, naar de modellen gekeken is, zijn we hierdoor ook in staat om eerder en meer potentiele fouten in de modellen te ontdekken.

Nadelen

Dus het gebruiken van modellen in de requirements fase heeft alleen maar voordelen? Nee natuurlijk niet. Voor mensen afkomstig uit of werkzaam in het ICT domein, zijn modellen in meer of mindere mate wel bekent. Voor mensen met een meer business geori?nteerde achtergrond, kan dat veel minder het geval zijn. Mijn ervaring is dat, afhankelijk van het type model, modellen ondanks deze beperking nog steeds bruikbaar zijn. Use case diagrams kunnen zeer goed gebruikt worden om overzicht te cre?ren vanuit het perspectief van de gebruiker. Maar ook de, voor business wellicht, minder toegankelijke modellen (state transition en class diagrams) zijn prima toepasbaar. Blijft staan dat alle mensen die werken met op deze manier vastgelegde requirements, zich in enige mate zullen moeten bekwamen in het interpreteren van modellen. Op zichzelf staand of door een model heen gepraat worden, in beide gevallen bieden modellen voordelen.

Zijn er verschillende dimensies van het product of systeem die we vast moeten leggen, dan hebben we daar meerdere modellen voor nodig. Bedenk daarbij wel dat we hier ook mee te maken hebben wanneer niet gekozen is voor modellen maar voor het vastleggen van requirements in natural language. Ook dan zullen bekeken vanuit de verschillende dimensies deze vast moeten leggen waarbij het bewaren van overzicht en het behouden van structuur een uitdaging vormen.

Ten slotte de mate van detail die we (niet) kunnen aanbrengen wanneer we gebruik maken van modellen. Het vocabulaire is beperkt. Hierdoor zal het nodig blijven om in aanvulling op de modellen, natural language te gebruiken voor bijvoorbeeld de benodigde detaillering maar ook om acceptatie criteria vast te leggen. Modellen kunnen daarbij dan gebruikt worden voor structuur, overzicht en de hoofdlijnen waarbij natural language op de benodigde plekken op het benodigde moment om de detaillering aan te brengen. De relaties tussen de modellen en de details vastgelegd in natural language zullen daarbij wel gecontroleerd moeten worden.

Conclusie

Modellen en modeleren kunnen prima een bijdrage leveren in het aanbrengen van structuur in complexe omgevingen. Daarnaast kunnen ze helpen om het grijze gebied tussen requirements en ontwerp te overbruggen door modellen voor beide te gebruiken en door te ontwikkelen. Natuurlijk moet daarbij de balans in de gaten gehouden worden tussen het op voorhand alles zo gedetailleerd mogelijk te willen vastleggen en het zelf regisserende vermogen van teams in een Agile geori?nteerde omgeving. Het vinden van deze balans en deze bewaken is onderdeel van het managen van het requirements proces.

In het verlengde van modellen gaat collega Piet de Roo volgende week verder in op use case diagrammen.

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.