Inleiding
Veel projecten gaan, ondanks een enthousiaste start, nooit in productie. Herkenbaar? Bij dergelijke projecten zijn vaak de requirements niet goed van kwaliteit, niet consistent met elkaar of ontbreken volledig.
Tijdens het ontwikkelen van interne standaarden hebben wij uit onze ervaringen best practices gedestilleerd. In dit artikel delen we een aantal van deze best practices. We kijken naar de voordelen voor een project en geven handvatten om deze best practices toe te passen.
Hang je Project Vision ingelijst aan de muur
In veel projecten blijkt het Vision-document achteraf bezien een verspilling van tijd; niet omdat je het document niet nodig had, maar omdat je het vaak vergat te gebruiken. In het begin van het project heb je veel aandacht aan het opstellen en afstemmen van het Vision-document met de klant besteed, maar daarna heb je de technische uitwerkingen en beslissingen in het project niet meer genomen op basis van de oorspronkelijk beschreven needs, maar op basis van de inschatting van een projectmedewerker.
Fig. 1: Zorg dat alle projectleden (de essentie van) het Vision-document kennen. Hoewel het misschien vreemd lijkt om een samenvatting van het Vision-document werkelijk aan de muur te hangen, kan dit in complexe projecten soms werkelijk helpen.
Wij vinden het belangrijk dat ieder teamlid het Vision-document kent. Het Vision-document beschrijft immers waarom het project gestart is (problem statement, needs) en welke functionele oplossing hiervoor gekozen is (features, functionele context). Het Vision-document bevat echter nog niet de gedetailleerde uitwerking van de oplossing in systeemrequirements (Use Cases en Supplementary Requirements).
Wanneer alle teamleden het waarom en wat van een project duidelijk voor ogen hebben, voorkomt dit wantrouwen tussen business en IT – wantrouwen omdat de IT-er vindt dat de business niet duidelijk aangeeft wat ze wil en de business vindt dat de IT-er altijd denkt in onmogelijkheden in plaats van mogelijkheden. Door de IT-er deelgenoot te maken van het probleem dat opgelost moet worden, kan hij ook proactief meedenken en aangeven wat een alternatieve oplossing kan zijn voor een slecht realiseerbare systeemrequirement.
Daarnaast helpt het Vision-document bij het snel bepalen van de oplossing bij wijzigingen doordat het Vision-document de needs en features bevat en de bijbehorende stakeholders (zie ook de best practice over traceability) . Bovendien is het eenvoudiger om de scope van het project te bewaken wanneer alle teamleden het Vision-document kennen. Iedereen weet wat de oorspronkelijk afgesproken scope is, en waarom deze zo is bepaald. Onbewuste afwijkingen van de scope vanwege onbekendheid met de doelstellingen van het project komen zo minder voor.
Fig. 2: Het-Vision document bevat zowel het waarom als het wat van een product en geeft daarmee een goed functioneel overzicht van het project
Betrek de juiste stakeholders
Het is belangrijk om je requirements samen met de juiste stakeholders te verzamelen en af te stemmen. Maar hoe bepaal je wie de juiste stakeholders zijn? Je wilt niet met te veel zogenaamde stakeholders om tafel zitten, want dan eindig je met Poolse landdagen waarbij geen besluit genomen wordt. Je wilt echter ook niet aan het eind van je project ontdekken dat b.v. de beheerafdeling je product niet accepteert omdat het niet aan hun beheerrequirements voldoet. De juiste stakeholder is iemand die:
- Direct geraakt wordt door de uitkomsten van het project, en daarbij ook in staat is de consequenties van de besluiten voor het eindproduct te overzien;
- Besluitvaardig is en hierbij ook mandaat heeft om besluiten over de functionaliteit van het product te nemen;
- Communicatief is (dus ook afstemt met zijn achterban) en mee wil werken aan de ontwikkeling van dit product.
Wanneer je onvoldoende, of verkeerde, stakeholders bij je project betrekt zal dit er altijd toe leiden dat het product uiteindelijk niet geaccepteerd wordt. Betrek dus de juiste stakeholders, en leg de stakeholders en hun verantwoordelijkheden ook vast in het Vision-document.
SMARTificeer de requirements
Met het smartificeren van requirements bedoelen we het SMART opschrijven van de requirements. Hiermee voorkom je dat bijvoorbeeld de tester een requirement anders interpreteert dan de bouwer, die op zijn beurt weer een andere interpretatie heeft dan de functionaliteit die de requirements-specifier voor ogen had.
SMART staat voor Specifiek, Meetbaar, Accepteerbaar, Realiseerbaar/Realistisch, Tijdgebonden/Testbaar/Traceerbaar
SMART staat voor Specifiek, Meetbaar, Accepteerbaar, Realiseerbaar/Realistisch, Tijdgebonden/Testbaar/Traceerbaar.
Een voorbeeld van een niet functionele requirement die niet SMART is, luidt: “De performance van het systeem moet goed zijn.”
Want wat is goed? De ene gebruiker vindt het al goed, als gegevens binnen 5 seconden op het scherm staan, terwijl de andere gebruiker het heel vervelend vindt als hij langer dan één seconde op een antwoord moet wachten.
Een SMARTere specificatie van deze requirement is: “Het tonen van gegevens op het scherm mag in 80% van de gevallen niet langer dan 1,5 sec. duren.”
Deze requirement is nu specifiek, omdat het spreekt over het tonen van de gegevens op het scherm; meetbaar en testbaar omdat het in 80% van de gevallen niet langer dan 1,5 seconde mag duren; accepteerbaar omdat duidelijk is als meer dan 20% er langer dan 1,5 seconde overdoet de requirement niet meer voldoet, en realiseerbaar omdat binnen de voor deze opdracht gebruikte technologieën dit een gangbare performance-eis is.
Bereik overeenstemming over de requirements
Stakeholders vertegenwoordigen allemaal een andere doelgroep dus hebben ze allemaal een ander beeld van het op te lossen probleem en daarom ook verschillende wensen voor de oplossing. Zorg dus dat je alle requirements met alle stakeholders afstemt en eventuele conflicterende requirements aanpast, met ieders instemming. Een goed goedkeuringsproces is hiervoor noodzakelijk. Ons advies hiervoor is simpel: gebruik workshops. Verzamel je requirements in een workshop, zodat alle stakeholders elkaars requirements kennen en erkennen, je de verwachtingen van al je stakeholders kunt managen en je conflicterende requirements direct kunt benoemen en aanpassen – de eindgebruiker heeft hierbij in principe het laatste woord. Alle stakeholders zijn met deze werkwijze volledig in de besluitvorming meegenomen, waardoor toekomstige wijzigingen ook eenvoudiger geaccepteerd worden.
Naast acceptatie van je stakeholders moeten ook alle projectteamleden de requirements begrijpen. Testers en designers zijn bovendien vaak kritische reviewers die vanuit hun rol goed de maakbaarheid en SMART-heid van requirements kunnen bevragen. Door het projectteam op tijd bij de review van de requirements te betrekken voorkom je rework in een latere fase, zorg je voor een eenvoudigere overdracht binnen het team en bereik je de optimale oplossing voor de klant.
Testers en designers zijn bovendien vaak kritische reviewers die vanuit hun rol goed de maakbaarheid en SMART-heid van requirements kunnen bevragen
Testers en designers kunnen opmerkingen hebben die te maken hebben met de maakbaarheid en SMART-heid van requirements. Denk hierbij weer aan het voorbeeld van de performance van een systeem: “Het tonen van gegevens op het scherm mag in 80% van de gevallen niet langer dan 1,5 sec. duren.”
Zoals eerder beschreven kan dit een goede requirement zijn. Echter, in een complexe technische omgeving waarin het systeem verschillende services moet aanroepen, kan dit lastig realiseerbaar zijn. De designer zal je hier dan ook op wijzen. De tester zal je bovendien vragen of er maxima gelden voor de overige 20%, en of het systeem een foutmelding moet tonen als het over deze maximumgrens heengaat. Na overleg met tester en designer kan deze requirement aangepast worden naar: “Het tonen van gegevens op het scherm mag in 80% van de gevallen niet langer dan 2 sec. duren. Wanneer het tonen van de gegevens langer dan 2 sec. duurt, moet de gebruiker een (beheerbare) foutmelding getoond worden.”
Daag je klant uit om niet alles als must have te classificeren
Als je met de klant praat dan merk je al gauw dat hij eigenlijk alles wil. Ook de briljante ideeën die jij ze aan de hand doet willen ze graag hebben. Echter, als je alle requirements zonder prioritering of classificering gaat uitvoeren, dan merk je in het algemeen dat het allemaal wel erg veel, lastig en duur wordt. Daarom is het ook in het belang van de klant, dat hij een onderscheid maakt tussen de ‘must haves’ en de ander ‘haves’ in het MOSCOW-model (Must Have, Should Have, Could Have, Want to Have). Een manier om de klant uit te dagen om dit onderscheid te maken is door hem de vraag te stellen: “Wat gebeurt er als we dit niet in het systeem gaan ondersteunen?”
“Wat gebeurt er als we dit niet in het systeem gaan ondersteunen?”
Ook bij het prioriteren is het belangrijk om de software architect of designer erbij te betrekken. Door de klant feedback te geven over de maakbaarheid van een requirement maak je de klant duidelijk dat sommige requirements erg duur zijn. Deze kosten-baten afweging maakt het voor de klant eenvoudiger om een requirement te ‘downgraden’. Het omgekeerde kan natuurlijk ook het geval zijn. Soms is een requirement voor een klant minder belangrijk, maar geeft de software architect aan dat het geen extra moeite kost om deze tegelijk met een ‘must have’ requirement te realiseren. Door deze requirement dan direct te koppelen aan deze ‘must have’, kan je een voor het project zo efficiënt mogelijke planning maken
Een voorbeeld van een requirement die door middel van het stellen van de vraag “Wat gebeurt er als we dit niet in het systeem gaan ondersteunen?” van een ‘must have’ naar een ‘should have’ zou kunnen verhuizen is de volgende: “Het systeem moet context-gevoelige helpfunctionaliteit kunnen aanbieden.”
Als je vervolgens de klant vraagt wat er gebeurt als er wel helpfunctionaliteit beschikbaar is, maar niet context gevoelig, dan antwoordt de klant vaak dat het op zich niet zoveel uitmaakt, maar dat de gebruiker alleen iets langer moet zoeken om de goede help-ondersteuning te vinden. In dit concrete voorbeeld verandert bij veel projecten deze ‘must have’ vaak naar een ‘could have’ of ‘should have’. Daarnaast moet je wel een nieuwe requirement toevoegen: “Het systeem moet helpfunctionaliteit aanbieden.”
Manage de verwachtingen, zowel van de klant als van jezelf
Net als bij het Vision-document is verwachtingsmanagement een activiteit waar je vaak in de eerste fase van het project op focust om het daarna te vergeten. Wat je je daarbij vaak niet realiseert, is dat een project een levende organisatie is, waarin bijna continu kleine wijzigingen aan de scope worden aangebracht. Wanneer je deze kleine wijzigingen niet duidelijk communiceert, zal het eindresultaat vaak een teleurstelling zijn voor de klant. Minstens net zo belangrijk is het om ook je eigen verwachtingen te managen. Jij verwacht namelijk ook iets van de klant, bijvoorbeeld medewerkers die een bijdrage aan het project leveren, maar ook interface-specificaties of review-activiteiten. Wanneer je deze verwachtingen niet van te voren uitspreekt, zal de klant niet altijd aan jouw verwachtingen voldoen, waardoor het project vertraging kan oplopen.
Voor het managen van klantverwachtingen kun je bijvoorbeeld denken aan ons eerdere voorbeeld over de contextgevoelige helpfunctionaliteit. Op het moment dat je besluit om dit terug te brengen tot een ‘gewone’ helpfunctionaliteit moeten alle stakeholders op de hoogte worden gesteld. Als je dit nalaat, is het voor de gebruikers wel een fikse teleurstelling op het moment dat het systeem in productie gaat.
Veranderingen gedurende het project zijn onvermijdbaar
Sta open voor wijzigingen
Wij komen regelmatig klanten tegen die huiverig zijn voor wijzigingen omdat ze bang zijn dat deze je project lastig bestuurbaar maken. Natuurlijk is de hoeveelheid wijzigingen een maat voor de stabiliteit van je project, maar dit betekent niet dat je alle wijzigingen moet weren. Veranderingen gedurende het project zijn onvermijdbaar. Door deze wijzigingen te verwachten en een goed proces in te richten om deze te behandelen kun je je project ook met wijzigingen bestuurbaar houden. Stem het change-proces ook af met al je stakeholders, zodat iedereen weet hoe een wijziging behandeld wordt en wie daarover mag besluiten.
Een aantal aanbevelingen voor een goed change=proces zijn:
- Zorg dat je expliciet vastlegt wat je met een wijziging doet (uitvoeren, afwijzen of uitstellen);
- Geef aan wanneer uitgestelde wijzigingen wel opgepakt worden;
- Zorg dat de in de wijziging beschreven oplossing in lijn is met het Vision-document; wijzigingen mogen alleen goedgekeurd worden als deze bijdragen aan de needs die beschreven zijn in het Vision-document;
- Als de wijziging een functionele wijziging betreft, volg dan hetzelfde afstemmingsproces als voor alle andere requirements, dus betrek alle relevante stakeholders;
- Zorg dat voor een wijziging niet alleen de code, maar ook de documentatie wordt bijgewerkt.
Een voorbeeld van een wijziging die goed doorgevoerd moet worden is: “Gedurende de test wordt een fout gevonden, die te herleiden blijkt te zijn tot een fout in de requirements.” Als gevolg hiervan moeten de requirements dus gewijzigd worden. Als je niet openstaat voor deze wijziging, betekent dit dat er uiteindelijk een foutief systeem wordt opgeleverd.
Gebruik de (kennis van de) software architect
Bij het opstellen van niet-functionele requirements is vaak ook gedegen technische kennis nodig. Een requirement specifier heeft deze technische kennis vaak niet, maar de software architect natuurlijk wel. Hij kan je dan ook helpen bij het opstellen van goede en haalbare niet-functionele requirements.
Als voorbeeld van de bijdrage die de software architect kan leveren aan het opstellen van niet-functionele requirements, kun je weer denken aan het voorbeeld van de performance requirement: “ Het tonen van gegevens op het scherm mag in 80% van de gevallen niet langer dan 1,5 sec. duren.” Het is wel leuk als je opschrijft dat de gegevens altijd binnen 1,5 seconde op het scherm getoond worden, maar dit moet natuurlijk wel haalbaar zijn. De software architect kan in dit geval heel goed aangeven wat binnen de gebruikte architectuur haalbare performance-eisen zijn. Hij kan de grenzen zetten en vervolgens kan je in overleg met de klant de uiteindelijke performance-eisen bepalen waardoor de uiteindelijke requirement er als volgt uit kan zien: “ Het tonen van gegevens op het scherm mag in 80% van de gevallen niet langer dan 1,5 sec. duren, wanneer geen externe services gebruikt worden en niet langer dan 2,5 sec. duren wanneer externe services gebruikt worden.”
Traceer requirements … maar niet oneindig
Het is belangrijk om requirements van hoog naar laag niveau traceerbaar te maken. Zo kun je detecteren of alle hoog niveau requirements daadwerkelijk verder uitgewerkt zijn. Met andere woorden: dekken de requirements de needs en features? Je wilt immers voorkomen dat de klant om iets heeft gevraagd, maar dat je die high level requirements niet hebt vertaald naar systeemrequirements (scope gap) of dat je een leuke systeemrequirement hebt bedacht die geen aansluiting heeft op de bovenliggende requirements, hiervan heeft de klant dan eerder aangegeven daar geen behoefte aan te hebben (scope creep).
Daarnaast kun je eenvoudig een impactanalyse voor een wijziging uitvoeren. Denk bijvoorbeeld aan een wijziging die later in het project om technische redenen moet worden doorgevoerd. De bijbehorende documentatie moet ook op basis hiervan worden aangepast. Wanneer alle requirements van hoog naar laag getraceerd worden, kun je snel inzichtelijk maken welke documentatie aangepast moet worden. Wanneer je deze traces niet hebt aangebracht, moet je veel uitzoeken en is het risico groot dat je dit, omwille van de tijd, of gewoon omdat het saai werk is, niet meer doet. De documentatie die je dan later aan de beheerafdeling oplevert is niet meer in sync met het werkelijk ontwikkelde product, waardoor het werk voor de beheerafdeling erg lastig wordt.
Hoe meer verschillende soorten requirements er zijn, des te meer mogelijkheden er zijn om de requirements te tracen, maar bedenk bij iedere vorm van tracing goed waarom je de tracing aanlegt en wat de toegevoegde waarde van de tracing is.
Het nadeel van te veel tracen is dat het veel en saai werk is, waardoor ook in de praktijk blijkt dat je deze traces niet goed onderhoudt. Het nadeel van te weinig tracen is dat je onvoldoende profiteert van de toegevoegde waarde van tracing waardoor het werk de moeite niet waard is.
Het is daarom heel belangrijk om bij het begin van het traject te bepalen wat je gaat tracen en met behulp van welke tooling je dit ondersteunt
Het is daarom heel belangrijk om bij het begin van het traject te bepalen wat je gaat tracen en met behulp van welke tooling je dit ondersteunt. Als je wel eens hebt geprobeerd meer dan 1000 requirements in Excel vast te leggen, dan weet je dat je dan het overzicht over alle requirements snel kwijt bent. Maar als je een uitgebreide requirements management tool gebruikt voor een klein project met honderd requirements levert juist dat veel overhead op en voldoet Excel prima.
We adviseren daarnaast ook om vanaf het begin van het project traces vast te leggen; achteraf aanbrengen van tracing is veel en vooral ook saai werk. In figuur 3 geven we een traceability model dat wij aanbevelen, met traces tussen alle requirements typen en naar de belangrijkste van requirements afgeleide deliverables.
Fig 3: Aanbevolen traceability model: dit model tracet alle requirementstypen naar elkaar zonder hierbij in veel detail te gaan en legt een trace naar de belangrijkste van de requirements afgeleide technische en test deliverables
Conclusie
Het opstellen van requirements is een lastig vakgebied en in de praktijk blijkt vaak dat je toch belangrijke zaken uit het oog verliest. In dit artikel hebben we vanuit onze praktijkervaringen een aantal best practices beschreven waarvan wij hebben gemerkt dat iedereen deze in de praktijk – bewust of onbewust – wel eens vergeet. Kort samengevat komen de best practices er op neer dat je vanaf het begin van je project serieus met het opstellen van requirements om moet gaan en gedurende het project deze als leidraad bij alle besluiten moet gebruiken; daarnaast is het erg belangrijk om de juiste personen bij je requirements te betrekken, zowel de stakeholders voor afstemming wat ze willen, als software architecten, designers en testers voor de maakbaarheid en testbaarheid van je requirements.
We hopen duidelijk te hebben gemaakt waarom het belangrijk is om deze best practices altijd toe te passen, en we hebben hierbij een aantal handvatten voor het toepassen gegeven.
Ben je geïnteresseerd in de achtergronden van deze best practices, of de uitbreidingen die de auteurs hiermee op RUP hebben gedaan, neem dan contact op met een van de auteurs.