Wat is de scope van mijn project?
Weer een change! Kunnen die requirements nu niet eens stabiel zijn?
Waarom maken we dit eigenlijk?
Komen deze vragen je bekend voor, dan ben je waarschijnlijk niet op de hoogte van het visiedocument.
Wat is een visiedocument?
Als je als ontwikkelmethode RUP gebruikt zou voor je project een visiedocument (RUP terminologie: Vision) aanwezig moeten zijn. Onze ervaring is echter dat dit vaak niet aanwezig is, terwijl het visiedocument in onze ogen één van de belangrijkste documenten voor een project is. De redenen (of smoesjes) die je vaak te horen krijgt als het document niet aanwezig is zijn legio. De klant geeft bijvoorbeeld aan dat het in de offerte al zo duidelijk omschreven is wat ze willen dat het zonde van de tijd en het geld is om alsnog een visiedocument te maken. Of de projectmanager wil graag zo snel mogelijk met de realisatie beginnen en geeft aan dat een visiedocument niet nodig is als je snel code oplevert.
Maar wat is nou precies een visiedocument en waarom vinden wij het zo belangrijk.
Het visiedocument is eigenlijk de afspraak tussen de opdrachtgever en de leverancier. De belangrijkste informatie die je uit het visiedocument kunt halen is het doel en de scope van je project. Hiertoe zijn in het visiedocument de stakeholders, de gebruikers en de features waaraan het systeem moet voldoen beschreven.
Wanneer het projectteam niet een gezamenlijk beeld heeft van het doel, de scope en de functionaliteit van het project, kun je je voorstellen dat een project moeizaam verloopt. Zonder project context en scope zal de software architect bijvoorbeeld een incompleet overzicht hebben op de gevraagde functionaliteit en daardoor een suboptimale oplossing uitwerken, zal de bouwer moeite hebben patronen te herkennen en daardoor minder herbruikbare code ontwikkelen en zal de tester alle gerealiseerde functionaliteit gelijke importantie geven waardoor testen en regressietesten minder efficiënt verlopen.
Het visiedocument geeft iedereen dezelfde achtergrondinformatie, dezelfde redenen waarom het project uitgevoerd wordt, met andere woorden: op basis van het visiedocument weet iedereen het doel en de scope van het project.
In ons vorige artikel hebben we daarom ook de best practice "hang het Vision aan de muur" genoemd, in dit artikel werken we deze best practice verder uit.
Waaraan herken je een goed visiedocument?
Een goed visiedocument bevat minimaal:
- de beschrijving van het probleem of de opportunity en daarbij dus ook het doel van het project
- de projectcontext
- de rollen die baat hebben of betrokken zijn bij het project
- de scope middels een beschrijving van de gewenste functionaliteit (needs en features inclusief de traces).
Een goed PID (project initation document) dat een volledige business case en requirementslijst bevat zou dus ook als vervanging van een visiedocument kunnen dienen. In de praktijk zien we echter vaak dat een PID of plan van aanpak zich voornamelijk richt op hoe het project uitgevoerd wordt en niet op wat er binnen het project ontwikkeld gaat worden en waarom.
Figuur 1: De checklist voor een compleet visiedocument bestaat uit de probleemomschrijving, projectcontext, stakeholders en gebruikers alsook de functionaliteit in needs en features.
In dit artikel zullen we ingaan op wat wij vinden dat er in een goed visiedocument moet staan. Deze checkpunten werken we daartoe verder uit. Om duidelijk te maken wat wij precies bedoelen geven we per checkpunt aan de hand van de gedefinieerde case een voorbeeld.
Voorbeeldcase
Organisatie X heeft momenteel te maken met veel klachten van klanten. Zij zijn niet goed in staat om deze klachten af te handelen. Hun klanten hebben geen inzicht in de afhandeling en voortgang van hun klachten waardoor klanten weglopen. Ook de organisatie zelf heeft geen inzicht hierin. Daarnaast zijn zij ook al door de ombudsman op hun klachtenafhandeling aangesproken. De ombudsman heeft daarom ook de eis neergelegd dat het komende jaar de klachtenafhandeling drastisch moet verbeteren. Daarom zal de ombudsman de klachtenafhandeling het komende jaar monitoren om te kunnen controleren of deze ook daadwerkelijk verbetert.
De checkpunten voor het visiedocument
1. De beschrijving van het probleem of de opportunity
In het visiedocument moet je terug kunnen vinden wat de aanleiding is geweest om jouw project te starten. Dit kan zijn om een probleem op te lossen, zoals in onze case, maar ook om bijvoorbeeld een marktkans in te vullen. Dit probleem of deze kans staat in het visiedocument beschreven vanuit business perspectief. Daarbij staat ook opgenomen voor wie jouw project de problemen oplost.
Voorbeeldcase
Probleem: Het probleem dat opgelost wordt is dat het afhandelen van de klachten ver beneden de maat is. De organisatie moet daarnaast voor de ombudsman aantoonbaar maken dat ze het komende jaar hun klachtenafhandeling verbeterd hebben. Analyses vertellen dat er momenteel onvoldoende inzicht is in de afhandeling van de klachten, waardoor het ook niet mogelijk is de pijnpunten in de klachtafhandeling te onderkennen.
Stakeholders: Het probleem wordt opgelost voor de verantwoordelijke voor het afhandelen van de klachten en de klanten die een klacht hebben ingediend. De verantwoordelijke voor de klachten heeft na realisatie van dit project een beter behoud van klanten die een klacht hebben ingediend; daarnaast heeft hij een beter inzicht in het verloop van de afhandeling van klachten, zoals de doorlooptijd van de afhandeling, de afhandeling zelf als de soort klachten die er ontstaan.
De klant heeft na realisatie van dit project inzicht in de status van zijn ingediende klacht.
De ombudsman heeft na realisatie van dit project inzicht in de afhandeling van de binnengekomen klachten.
Wij vinden de beschrijving van het probleem belangrijk, omdat iedereen – zowel onze klant als ook wijzelf – goed in de gaten heeft en kan houden, waarom we met dit project bezig zijn. Als de beschrijving van het op te lossen probleem ontbreekt, lopen we in het verdere traject het risico dat we ons bezig gaan houden met zaken die niets toevoegen aan het oplossen van het daadwerkelijke probleem. Stel je bijvoorbeeld voor dat de klant gaandeweg het project bedenkt dat het misschien wel handig is dat er allerlei informatie geregistreerd wordt over de persoon die de klacht heeft. Op zo’n moment kun je teruggrijpen naar het visiedocument en zie je daar dat dit niets te maken heeft met het oplossen van het daadwerkelijke probleem.
De probleembeschrijving wordt in het visiedocument verder uitgewerkt in business requirements (RUP terminologie: needs).
2. Wie worden geraakt door of hebben baat bij ons project?
In het visiedocument moeten zowel de stakeholders als de gebruikers, inclusief hun wensen met betrekking tot het nieuwe systeem, beschreven zijn.
Stakeholders zijn diegenen die geraakt worden door de uitkomsten van dit project. Naast de meer voor de hand liggende stakeholders, bijvoorbeeld de opdrachtgever, zul je ook minder voor de hand liggende stakeholders vinden. Denk bij deze laatste bijvoorbeeld aan de interne accountantsdienst, de toekomstige beheerders of de juridische afdeling.
Gebruikers zijn degenen die het systeem daadwerkelijk gaan gebruiken, zoals de (externe) klanten, maar ook de interne contentbeheerders, degenen die de managementrapportages maken etc. De gebruikers hebben vaak een vertegenwoordiger als stakeholder.
Stakeholders voor het te ontwikkelen systeem zijn de financieel directeur, de verantwoordelijke voor de klachten, de automatiseringsafdeling, de ombudsman en de klant.
Gebruikers van het systeem zijn de klanten die een klacht hebben, de verantwoordelijke voor de klachten die de doorlooptijd kan inzien en inzicht heeft in management informatie, de medewerker die de klachten invoert en de klant die een klacht heeft en deze wil opgeven en wil kunnen inzien wat de status van zijn klacht is.
Als bij het opstellen van het visiedocument niet goed gekeken is naar wie de stakeholders en wie de gebruikers zijn, ontstaan er veelal ver in het project behoorlijke problemen.
Komt het je bijvoorbeeld bekend voor dat je een product in gebruik wilt nemen, maar dat de beheerafdeling ineens dwars ligt omdat niet aan hun eisen is voldaan? Of dat de juridische afdeling ineens ingebruikname van het product blokkeert omdat het niet aan de wet- en regelgeving voldoet? Of dat de gebruikers bij de acceptatietesten heel negatief oordelen over het product en weigeren het te gaan gebruiken omdat het voor hun niet bruikbaar is? In figuur 2 vind je daarom een checklist om te controleren of alle stakeholders in het visiedocument genoemd zijn.
Figuur 2: De checklist voor een complete stakeholderlijst. Blijf je continu afvragen of je stakeholderlijst compleet is.
3. De context van het project
In het visiedocument moet aandacht besteed zijn aan de context waarbinnen het project wordt uitgevoerd. Naast de business context, moet ook de context van het te ontwikkelen product beschreven zijn. Onze ervaring is namelijk dat het voor alle projectbetrokkenen belangrijk is om de business context en de product context te kennen. Uit een goed beschreven product context kun je de interfaces met andere systemen onderkennen. Daarnaast helpt deze context je ook om de scope van je project helder te houden en goed te communiceren. De business context helpt je om het project en het belang daarvan voor de organisatie te plaatsen; deze geeft ook inzicht in mogelijke stakeholders die belangrijk zijn voor het project.
Vroegtijdige herkenning van alle externe interfaces voorkomt veel problemen in het project. Niets is vervelender dan dat je pas bij het aansluiten van externe systemen achter komt dat het externe systeem informatie van jouw systeem verwacht die niet beschikbaar is. De product context in het visiedocument maakt deze externe afhankelijkheden op hoofdniveau al vroeg duidelijk in het project.
Voorbeeldcase
Business context Product context
Zoals uit deze 2 plaatjes blijkt heeft onze klant relaties met zijn klanten en de ombudsman. Om de communicatie met de buiten wereld te ondersteunen gaat ons systeem interfaces krijgen met de klant en met de ombudsman. Met de klant zal de interface bestaan uit één of meerdere schermen en de interface met de ombudsman uit een elektronisch bericht.
4. De features waaraan het systeem moet voldoen
Het laatste belangrijke onderdeel uit het visiedocument is de beschrijving van de features van het te ontwikkelen systeem. Vanuit deze features worden de systeemrequirements beschreven die als input voor realisatie dienen. Elke systeemrequirement die wordt geïmplementeerd is altijd te herleiden naar één of meerdere features uit het visiedocument. In figuur 3 staan de verschillende detailniveaus van requirements afgebeeld.
Figuur 3: Het visiedocument beschrijft zowel het waarom als het wat van een project en geeft daarmee een goed functioneel overzicht van het project.
Bij het vaststellen van de features is het wel van belang om de stakeholders goed te managen. De algemene vraag stellen aan een stakeholder wat het systeem allemaal moet kunnen is als een kind voor een snoepkraam zetten en vragen welk snoepje hij wil. Domme vraag, alles natuurlijk! Zoals een kind ook leert dat hij voor de meegekregen 50 cent niet alle snoepjes kan krijgen, moet je de stakeholder ook helpen keuzes te maken in de eisen die hij aan het systeem stelt. Door alle gevraagde functionaliteit te relateren aan de probleemomschrijving (draagt dit werkelijk bij aan het oplossen van het probleem?) kun je komen tot een minimale set functionaliteit die aan de volledige probleemomschrijving voldoet.
Figuur 4: Een stakeholder vrijelijk alle wensen laten uiten is als een kind loslaten in een snoepwinkel; het helpt om de grenzen aan te geven van wat (vanuit het oogpunt van financiën, tijd, kwaliteit of gezondheid) mogelijk is.
Omdat het visiedocument een overzichtsdocument is, wordt hierin niet de volledige functionaliteit op detailniveau beschreven. De features in het visiedocument zijn over het algemeen van een hoog en abstract niveau. In theorie moeten de features ook al in het visiedocument volledig SMART beschreven zijn. Echter in de praktijk blijkt dit meestal niet het geval te zijn. De requirements specifier werkt deze features verder uit tot meerdere use cases en supplementary specifications. Tijdens deze detaillering in de systeemrequirements kan de requirements specifier vaak ook de features aanscherpen. Het resultaat van de werkzaamheden van de requirements specifier zal voor de designers en bouwers als input dienen voor de verdere ontwikkeling van het systeem.
Categorieën features
Om de leesbaarheid en de toegankelijkheid van de features te vergroten vinden wij dat deze gegroepeerd moeten zijn. Wij gebruiken een groepering die onderscheid maakt in functionele features, gebruiksfeatures, onderhoudsfeatures en constraints.
Voorbeeldcase
Een functionele feature in ons systeem is dat een klant de mogelijkheid moet hebben om een klacht te kunnen registreren. Deze feature zul je in de requirements terugvinden als een use case die deze functionaliteit ondersteunt.
Een gebruiksfeature van ons systeem is dat er minimaal 100 klachten tegelijkertijd geregistreerd moeten kunnen worden.
Een onderhoudsfeature kan zijn dat correspondentie met de klant over de klacht minimaal x jaar bewaard moet worden om te voldoen aan eisen die de ombudsman stelt.
Een constraint van ons systeem kan zijn kan zijn dat de te ontwikkelen applicatie moet voldoen aan de beveiligingseisen van de organisatie.
De vertaling van de gebruiksfeatures, onderhoudsfeatures en constraints naar systeemrequirements kun je meestal in de supplementary specifications terugvinden.Zoals je nu ziet zijn niet al deze features SMART gedefinieerd. Het is daarom ook de taak van de requirements specifier om deze bij het vertalen naar de supplementary specifications SMART te maken. Voor ons voorbeeld met betrekking tot de beveiligingseisen komt in de supplementary specifications te staan wat deze beveiligingseisen zijn of de verwijzing naar het document van de klant waarin deze eisen SMART zijn gedefinieerd.
In de hierboven genoemde opsomming en voorbeelden van features zou de indruk kunnen ontstaan dat de nadruk van het visiedocument op de niet functionele specificaties ligt. Dit is niet waar, meestal is de lijst met functionele features lang terwijl de andere features relatief kortere lijstjes zijn. De functionele features zijn echter de specificaties waar de meeste stakeholders direct aan denken, de niet functionele specificaties worden sneller vergeten. We raden overigens ook aan om de functionele features nog verder in subcategorieën in te delen om zo ook eenvoudiger de compleetheid te kunnen controleren. Je kunt hierbij denken aan subcategorieën over autorisatie en authenticatie, rapportages, beheerfunctionaliteit etc.
Scopebeheersing
Het visiedocument stelt je ook in staat de scope te beheersen. Dit document beschrijft de needs en de features; elke feature is getraced naar een need. Bij de detailuitwerking van de features in systeemrequirements (use cases en supplementary specifications) trace je deze ook weer naar de feature waar je de systeemrequirement van hebt afgeleid.
Wanneer je een systeemrequirement hebt die je niet kunt tracen naar een feature, heb je een scope creep: je beschrijft meer functionaliteit dan eigenlijk gewenst. Hiervoor zijn twee oplossingen. Gezamenlijk met de klant bespreek je of deze functionaliteit inderdaad niet in scope is en niet gerealiseerd wordt, of dat deze functionaliteit eigenlijk wel gewenst is, gerealiseerd moet worden en dus als change voor het project ingediend wordt. Het indienen van de change stelt je –na acceptatie van de change – ook in staat om het visiedocument bij te werken, zodat je volledige scope weer overeenkomt met de gewenste realisatie.
Wanneer je een feature hebt waarnaar geen systeemrequirement tracet, heb je een scope gap: je hebt minder functionaliteit beschreven dan eigenlijk gewenst. Ook hiervoor zijn twee oplossingen. Gezamenlijk met de klant kun je constateren dat de feature (en eventueel ook de bovenliggende need) niet meer van toepassing is, zodat deze kan komen te vervallen; ook hiervoor dien je een change voor het project in. Ten tweede kan je de feature verder uitwerken in systeemrequirements, zodat de scope volledig is uitgewerkt en gerealiseerd kan worden.
Dezelfde analyse doe je vervolgens bij de uitwerking van de systeemrequirements in de werkproducten zoals het software architecture document, de use case realisation en de test case. Elke systeemrequirement moet in de architectuur, design en de testcases terugkomen, zodat duidelijk zichtbaar is dat alle functionaliteit is gerealiseerd en getest. Het V-model zoals weergegeven in figuur 5 maakt deze relatie tussen de requirements, de realisatie en het testen duidelijk.
Figuur 5: Het Extended V-model maakt duidelijk dat de requirements in lagen worden ontwikkeld en als basis dienen voor de realisatie van het systeem; testen van het gerealiseerde systeem vinden vervolgens weer plaats op basis van de requirements
In figuur 6 zie je het door ons aanbevolen traceability model, met traces tussen de requirements en werkdocumenten. Een van onze lessons learned is dat we geen directe trace hebben tussen een supplementary specification en een use case realisation, maar dat deze trace altijd via het software architecture document loopt. Door de trace via het software architecture document te laten lopen garandeer je een generieke oplossing voor deze meestal ook generieke supplementary specification en voorkom je bijvoorbeeld drie verschillende implementaties van een authenticatiemechanisme.
Figuur 6: Het traceabilitymodel van de requirements naar alle werkproducten.
Samenvatting
Het visiedocument legt de basis voor het gehele project en is voor alle betrokkenen in het project een belangrijk document. Hierin vinden we namelijk waarom we ons project uitvoeren, wat de context is waarbinnen het te ontwikkelen product zich begeeft, wie er bij betrokken zijn en wat de eigenschappen zijn waaraan het systeem moet voldoen. Het visiedocument maakt het daarom mogelijk, om samen met een goed ingerichte traceability, het project te beheersen. Dit is dan ook alleen mogelijk als alle betrokkenen het visiedocument tussen de oren hebben. Of met andere woorden: hang het visiedocument aan de muur!
Figuur 7: Zorg dat alle betrokkenen bij het project het visiedocument goed kennen, zodat alle projectbesluiten gericht zijn op het halen van het projectdoel.