Tien tips voor een goed requirementsbeheer
Er loopt heel wat mis in de wittebroodsweken van een project. Een studie van de Standish Group stelt dat de slaagkans van projecten tussen 1994 en 2003 steeg van amper 16% naar 31%. Er is een merkbare vooruitgang, maar de leerling is nog steeds gebuisd. Volgens dezelfde studie lopen projecten vooral fout op onduidelijke objectieven, vage en wijzigende behoeftedefinitie en gebrek aan user input. Zeg maar, de fase van requirementsdefinitie.
De laatste decennia is heel wat werk verricht aan deze fase. De vereisten voor CMMI-certifi catie (Capability Maturity Model Integration) vormen daarvoor een duidelijk bewijs. Zo wordt een promotie van maturiteitsniveau 1 naar 2 in eerste instantie afhankelijk gemaakt van een investering in de requirementsfase. Dit artikel geeft tien tips voor een goed requirementsbeheer, gebaseerd op industry best practices.
TIP 1: ONDERKEN DE VERSCHILLENDE NIVEAUS VAN REQUIREMENTS
Een requirementsdefi nitie is niet één document dat alle waarheden bevat. Veeleer is het een verzameling van documenten die op elkaar verder bouwen en elkaar verfi jnen. Belangrijk daarbij is dat men het niveau van elk deel respecteert. Zo komen functionele requirements pas op een tweede niveau aan bod en dienen ze zich te baseren op een voorafgaande visie en probleemdefi nitie. Dat lijkt evident, maar deze regel wordt meermaals met de voeten getreden.
TIP 2: INVESTEER IN EEN BEGRIJPBAAR VISIEDOCUMENT
Laten we even stilstaan bij de bovenste laag: het visiedocument. De IT-vingers jeuken om alvast het analysemodel, de architectuur en zelfs het design te schetsen. Maar wat baat dat als er nog onduidelijkheid bestaat rond het nut van het project en diens stakeholders. Het visiedocument brengt de opportuniteiten en de uitgangsproblemen van het project in kaart. Het definieert de stakeholders en de systeemcontext. En het geeft je een volledige lijst van features die de basis vormt voor verdere analyse. Als sluitstuk biedt het visiedocument een verklarende woordenlijst. Zo’n woordenlijst klinkt misschien banaal. Maar heel wat misverstanden kan je al vroeg in het project oplossen met een eenduidige definitie van concepten die anders door de verschillende stakeholders verschillend begrepen zouden worden.
Maar laten we beginnen met de belangrijkste vraag van het visiedocument: welke opportuniteiten en/of problemen vormen het uitgangspunt van dit project? Voor zo’n analyse kan je kiezen uit een indrukwekkende set aan technieken. De SWOTanalyse, root-cause analyse of de Problem Statement (RUP) zijn enkele voorbeelden. Gebruik de techniek die het beste past bij jouw organisatie. Het doel van de analyse is dat alle partijen hun kaarten op tafel leggen: waarom willen we dit project en wat willen we ermee bereiken? Dergelijke vragen worden doorgaans bij de koffi emachine of tijdens de lunchpauze gesteld. Blijven de antwoorden in het informele en politieke circuit hangen, dan zijn ze een risico voor het project.
Daarna komt de vraag naar wie allemaal bij dit project betrokken is: de stakeholders. Het organigram, de stakeholdersmap en de RACI-matrix zijn voorbeelden van technieken die je hiervoor kan gebruiken. Opnieuw kies je hier een techniek die het best gepast is voor de organisatie en het project. Misschien werd vroeger al één van deze technieken gebruikt. Dat spaart je een hoop uitleg en overtuiging.
Bij het vastleggen van de systeemcontext komt de informaticus weer op bekend terrein. Op basis van use case diagrammen, value chain of activity diagrammen wordt de opdrachtgever op een bevattelijke wijze ingeleid in de wereld der applicaties.
Dit is het referentiekader voor het echte ‘vlees’ van het visiedocument: de features. Een feature is een functionaliteit van het systeem. Die kan neergeschreven zijn in de vorm van een use case, een elementair proces of een service. Het visiedocument geeft een volledige en consistente lijst van features. De features krijgen een prioriteit toegekend. Zo ontstaat al een eerste vorm van release planning.
Hierboven benoemden we de belangrijkste componenten van het visiedocument. In de volgende tips komen we op enkele ervan terug. Maar eerst moeten er duidelijke afspraken worden gemaakt rond de rolverdeling tussen business en het projectteam.
TIP 3: BEPAAL DE RAAKPUNTEN TUSSEN BUSINESS EN HET IT-PROJECTTEAM
Iedereen kent wel van die projecten waarin business en IT halsstarrig vasthouden aan de eigen documentatie. In zo’n projecten heerst wantrouwen rond de inhoud en het gebruik van documenten die niet van eigen hand zijn. Uiteindelijk loopt zo’n project fout op misverstanden. Het is dus belangrijk dat alle partijen van bij het begin van het project duidelijk de raakpunten tussen business en projectteam bepalen. Deze raakpunten concretiseer je best in termen als deliverables en je stelt ook de auteurs en reviewers van die deliverables vast. Zowel IT als business hebben de neiging om belangrijke delen van documenten van review uit te sluiten. Het heet dan bijvoorbeeld dat hoofdstuk X en Y te technisch of business-specifi ek is. Dat maakt jouw review een stuk makkelijker. Maar nadien heb je natuurlijk geen verhaal meer als bepaalde ’technische’ keuzes belangrijke consequenties hebben op performantie, maintainability enzovoort.
Vertaal eventueel technische opties naar functionele en nietfunctionele requirements opdat voor iedereen de gevolgen van zo’n beslissing duidelijk zijn. Vooral in de context van een offshore developmentproject besteed je best wat aandacht aan deze afspraken. Het bepalen van de juiste check-points met zo’n externe partij is een discipline op zich.
TIP 4: PAS DE JUISTE REQUIREMENTS ENGINEERING TECHNIEK TOE
Een informaticus tekent graag. Zijn businesspartner geeft de voorkeur aan het geschreven woord. Ook daar lijken de beide partners van een andere planeet te komen. Maar geen nood, er bestaat een heel arsenaal aan requirements engineering technieken. Wie met een open geest zoekt, vindt het gepaste instrument voor elk project, elk bedrijf en elke gesprekspartner.
We noemen er enkele die vast bekend in de oren klinken: interviewing, modelling workshop, prototyping en brainstorming. Uit de wereld van de pakketimplementatie komt dan weer de productwalkthrough.
Daarbij krijgt een groep van sleutelgebruikers eerst een opleiding in het pakket. Daarna loopt de pakketintegrator in modulegerichte workshops door de processen van de gebruiker. Apprenticing is dan weer een techniek waar waarbij de analist de job leert door observatie en gerichte vragen on the job. Deze techniek moet evenwel gericht toegepast worden. Informatici zijn als resources te duur om maandenlang in een operationele dienst rond te kuieren.
TIP 5: SLICING AND SIZING
De vraag hoe je een olifant eet is haast retorisch geworden. Voor wie die klassieker nog niet gehoord heeft: een olifant eet je schijf per schijf. Daarmee wordt aangeduid dat kleinere projecten een grotere kans op succes hebben. Ook dat is een klassieker en een evidentie als een klok. Toch worden er telkens weer mastodontprojecten geboren, met doorlooptijden van meerdere jaren. Toegegeven, het is niet gemakkelijk om een projectscope in deelreleases op te delen. Zoiets heeft zijn kostprijs en z’n risico’s. Denk maar aan het versiemanagement, de migratie- inspanning en de impact op het onderhoudscontract met de externe leverancier. Maar de baten overstijgen in de meeste gevallen de kosten en risico’s.
Enkele tips voor de slicing and sizing van een project. Releases kunnen gericht zijn op risico, baten, het werk of de vooropgestelde architecturale prioriteiten. Dit zijn geen alleenstaande keuzes maar keuzes die rechtstreeks volgen uit de vooropgestelde opportuniteiten en problemen van het visiedocument (zie tip 2). Eens de oriëntatie van de releases bepaald is, volgt de opdeling in Must have, Support, Could have en Won’t have features (de veelgebruikte Moscow-techniek). Ook hier start de discussie bij het visiedocument, namelijk van de featureslijst. Must
have features zijn de minimum set van kernfunctionaliteiten.
Die horen sowieso in de eerste release thuis. Support features zijn belangrijke functionaliteiten waarvoor evenwel een alternatieve werkwijze bestaat. De Could have feature kan in eender welke release ingepland worden, van zodra de supportfunctionaliteit het daglicht heeft gezien. Aan het einde van het lijstje staat de Won’t have feature. Dat is een feature waarvan de prioriteit herbekeken moet worden. Sizing is een iteratieve oefening. Daarbij blijft de beheersbaarheid van het project het hoofddoel.
TIP 6: DEK HET VOLLEDIGE SPECTRUM VAN REQUIREMENTS AF
Het diagram in figuur 1 toont een brede waaier aan software requirements. Zowel business als IT zijn niet wars van een zekere hokjesmentaliteit. Het gebeurt dan ook vaak dat een deel van de requirements niet worden bekeken omdat ze niet tot de ‘eigen’ problematiek worden gerekend. Neem nou bijvoorbeeld change requirements. Change requirements betreffen het invoeren van een systeem in de organisatie. Een treffend voorbeeld is de impact van de invoering van een real-time systeem op een helpdesk die tot dan toe werkte met batch overnight processing. Het gebeurt maar al te vaak dat voor zo’n impact de bal in het kamp van de business wordt gelegd.
Nochtans heeft zo’n verandering directe gevolgen voor niet-functionele requirements zoals online beschikbaarheid en support Service Level Agreements (SLAs). Het zal in vele gevallen ook leiden tot nieuwe functionele requirements zoals real-time rapporten en logging. En dan hebben we nog niet gesproken over de impact op timing en migratie. Gebruik voor deze requirementstypes zoveel mogelijk sjablonen die op de markt beschikbaar zijn. Het Volere sjabloon en het RUP – SRS template zijn enkele voorbeelden.
In een succesvol project worden al deze requirements van dag één tot de gemeenschappelijke scope gerekend. Ze worden allen in kaart gebracht en het projectteam neemt gezamenlijke verantwoordelijkheid. Daarmee is niet gezegd dat IT ook verantwoordelijk zou zijn voor de implementatie van alle organisatorische wijzigingen. De taakverdeling tussen business en IT blijft gerespecteerd. Het is belangrijk dat de hele scope onderwerp is van de requirementsdefinitie.
TIP 7: INVESTEER DE NODIGE TIJD IN NIETFUNCTIONELE REQUIREMENTS
ISO9126 stelt zes niet-functionele requirements voorop. Een ISO-norm heeft een lage aaibaarheidsfactor maar is een handige cross-check om project- en implementatierisico’s in kaart te brengen. We gebruiken de Engelstalige notatie: functionality, reliability, usability, efficiency, maintainability en portability. De ISO-standaard benoemt deze als quality subcharacteristics die verder gespecificeerd zijn in attributen. De interoperabiliteit, compliance en toepasbaarheid zijn voorbeelden van kwaliteitsattributen voor functionaliteit.
Maintainability vertaalt zich dan weer naar de attributen stabiliteit, analyseerbaarheid, veranderbaarheid en testbaarheid. Onze tip bestaat erin deze checklist doorheen de hele requirementsoefening consequent en exhaustief te doorlopen en in te vullen. Het zal je helpen tegengestelde verwachtingen vroeg in het project aan de oppervlakte te brengen.
TIP 8: ZET EEN QUALITY GATEWAY KLAAR
Kwaliteitsmeting wordt soms als een bureaucratische bottleneck ervaren. Nochtans is het belangrijk om hier werk van te maken. De impact van een ‘gemiste’ requirement stijgt exponentieel naarmate die later in de projectcyclus ontdekt wordt. Onze tip gaat hierin redelijk ver.
We adviseren de installatie van een Single Quality Check Point. Alle requirements dienen door deze gateway te lopen en worden gecheckt op vooropgestelde metingcriteria. Zo moet een requirement eenduidig zijn. Er mag geen ruimte voor interpretatie zijn en de gebruikte terminologie moet duidelijk gedefinieerd zijn.
Andere vragen rond de kwaliteit van requirements zijn: is de requirement volledig, testbaar, consistent, niet redundant, uniek geïdentificeerd en vooral correct en met een duidelijke waarde voor de klant? Het is duidelijk dat een kwaliteitmeting die op die manier opgevat wordt, meer is dan een check van de vorm. We spreken hier over zowel vormelijke als inhoudelijke checks van de kwaliteit van de requirement. Dat stelt dus heel wat eisen aan de medewerkers van de quality gateway. Een quality gateway beman je niet met bureaucraten. De gateway moet inhoudelijk werken. Onze aanbeveling is om hem te organiseren in de vorm van walkthroughs met business- en IT-specialisten.
TIP 9: INVESTEER IN SCOPE CONTROL EN SCOPE TRACEABILITY
Scope creep is inderdaad een belangrijk probleem in projecten. En je kan er dus maar beter rekening mee houden dat het zal gebeuren. Stel dus een procedure op om deze wijzigingen op te vangen. Zoals het spreekwoord zegt, het bloed kruipt waar het niet gaan kan. Je businesspartner overvallen met een hoop handtekeningen is niet de beste methode. Dat kan de storm gedurende een korte periode luwen, maar het geeft het project een vals gevoel van veiligheid. Verbindt dus een requirements management procedure aan je design-, test- en change/configuratiemanagement. Dat garandeert een complete en consistente requirements base doorheen de gehele doorlooptijd van jouw project.
TIP 10: BASEER JE BUDGETINSCHATTING DIRECT OP DE REQUIREMENTS
De laatste tip gaat over geld. Zoals in elke relatie speelt geld ook in die tussen business en IT een belangrijke rol. Onze aanbeveling is om een budgetteringstechniek te gebruiken die rechtstreeks gebaseerd is op een lijst van functionaliteiten. Er bestaan heel wat technieken, waaronder Product based estimation (lees ook het artikel Budgetteringstechnieken, back to basics, in nummer 21 van dit blad)
BOVENAL: GEBRUIK GEZOND VERSTAND
Het uitgangspunt van een succesvol project is een goede verstandhouding tussen business en IT. Bovengenoemde technieken en tips zijn slechts hulpmiddelen voor beide partijen om de kaarten op tafel te leggen. De rest is gezond verstand. Gezond verstand is de tip die bij alle best practices hoort.
