Projecten kansloos zonder goede requirements

Een projectbeschrijving. Het begint vaak met opdrachtgevers die hun visie op de te ontwikkelen toepassing kenbaar maken in termen van technische eigenschappen (open source, webbased et cetera). Een volgende stap in het specificeren van de oplossing ligt veelal bij de gebruikers. Zij zijn de deskundigen als het aankomt op het gebruiken van de nieuwe toepassing. Zij moeten dus als geen ander de verdere specificaties voor de toepassing duidelijk kunnen maken. Het kost hen echter wel moeite om dit te doen. Met de beschikbare informatie van de opdrachtgever kunnen ze ook niet veel (die bestaat nog slechts uit high level specifications). Al snel kunnen ontwikkelaars aan de slag. Bij voorkeur met verstand van de materie en de bestaande applicaties. Met die bagage zijn zij prima in staat het ontwerp- en of programmeerwerk uit te voeren, ook al weten zij dat de beschikbare specificaties niet de schoonheidsprijs verdienen. Maar ja, het is nu eenmaal een gegeven dat de business moeite heeft om duidelijk te maken wat ze wil. Als het project eenmaal goed op gang is - het programmeren is inmiddels gestart - wordt het tijd de testers erbij te betrekken. Met de opgeleverde ontwerpen kunnen zij het testen voorbereiden, want inmiddels is wel duidelijk hoe de applicatie eruit komt te zien. De testmanager begint echter al snel een storende factor in het project te worden. Hij heeft moeite de testen voor te bereiden. Hij vindt het ontwerp niet altijd even helder en zou eigenlijk meer informatie willen hebben over de acceptatie van het systeem. Door zijn vragen krijgen de gebruikers een ongemakkelijk gevoel, hun specificaties geven misschien niet altijd even goed weer wat ze bedoelden. Het steeds blijven aanleveren van specificaties is ook lastig. Er zijn trouwens veel ‘must have’s’. En het budget en de einddatum staan vast. De testuitvoering verloopt vaak moeizaam, er is meer tijd voor het testen nodig. Het komt nog al eens voor dat er niet goed is getest, of dat er is getest zonder rekening te houden met reeds doorgevoerde wijzigingen. Regelmatig blijkt dat er wel is gebouwd volgens de spec’s, maar dat de organisatie toch iets anders wilde. Verkeerde zaken Dit is een project zoals je het vaak tegenkomt; met serieuze betrokkenheid van opdrachtgevers en gebruikersvertegenwoordigers. Het is vooral een project waar - als we het over requirements hebben - veel langs elkaar heen wordt gepraat en in feite over de verkeerde zaken wordt gesproken. Ik noem de moeilijke punten en de mogelijkheden voor verbetering. De visie op de te ontwikkelen toepassing hoeft op zichzelf geen probleem te zijn. Ervan uitgaande dat deze visie aansluit op de architectuurkeuzes van de organisatie, is het goed deze beelden mee te nemen. De kern van de zaak - als het gaat om requirements van de opdrachtgever - ontbreekt echter nog. Waarom is er behoefte aan een nieuwe of gewijzigde applicatie? Welke doelstellingen wil de business met behulp van deze toepassing realiseren? Als we deze informatie hebben kunnen we de relevante businessprocessen afbakenen en vervolgens de gewenste ondersteuning van deze businessprocessen met de gebruikers afstemmen. We kunnen ook prioriteiten toekennen aan requirements omdat we de relatie met de businessdoelstellingen kunnen bepalen. Het houdt natuurlijk niet op met requirements in termen van doelstellingen en procesondersteuning. Er zijn meer eisen waaraan de applicatie moet voldoen, zowel vanuit de optiek van het gebruik - denk aan performance, gebruiksvriendelijkheid en instelbaarheid - als vanuit het beheer (installeerbaarheid en middelenbeslag, security et cetera). Verschillende stakeholders worden hiervoor geraadpleegd en gevraagd met de reeds beschikbare informatie over doelstellingen en processen hun requirements aan te dragen. De beheerorganisatie wordt dan niet slechts gevraagd te kijken of de applicatie aan hun overdrachtscriteria voldoet, maar tevens om mee te denken over de requirements. Dat leidt zowel tot een beter op de situatie afgestemde set requirements als tot een coöperatieve opstelling gedurende de ontwikkel-, test- en mogelijke pilotfase. Testexpertise wordt niet pas betrokken op het moment dat het programmeerwerk start. Testexpertise wordt ingeschakeld om, door vroegtijdige testvoorbereiding, de kwaliteit van requirements vast te stellen. In het verleden kwamen de opmerkingen over onduidelijke en onvolledige requirements vaak op een moment dat het programmeerwerk reeds was gestart, nu dragen ze bij aan het leggen van een goede basis voor zowel de ontwikkeling als het testen. Natuurlijk krijgen we nog te maken met wijzigende inzichten vanuit de business, dat is reëel in een speelveld dat steeds dynamischer wordt. Maar deze wijzigingen gaan niet als ongeleide projectielen het project in. De basis voor het wijzigingenbeheer is gelegd door de gemaakte afspraken over de verzameling requirements (baseline) die voor de eerste oplevering van het project gelden. Wijzigingen op requirements worden allereerst beoordeeld op hun impact op de bestaande requirements en vervolgens op de gevolgen voor het ontwikkel- en testwerk. Overeengekomen wijzigingen worden in een volgende baseline aan de ontwikkelaars en testers beschikbaar gesteld. Uitbesteden Met goede requirements legt men de basis voor succesvolle systeemontwikkelingsprojecten. Steeds vaker worden deze projecten uitgevoerd in een vorm van uitbesteding. De termen offshoring en outsourcing zijn ‘hot’. Hoewel er een aantal overwegingen te noemen is waarom organisaties voor deze optie kiezen, gaat het toch vooral om kostenbeheersing en -besparing. Kwaliteit van IT blijft tenminste op het huidige niveau, is daarbij de verwachting. De beoogde kostenbesparing gaat in de praktijk nog wel eens verloren omdat tijdens de ontwikkeling van de applicatie of het testen daarvan blijkt dat de requirements niet volledig of onvoldoende duidelijk zijn en vervolgens als wijziging of aanvulling worden behandeld. Het gevolg is dat er een omvangrijke kostenpost voor meerwerk ontstaat. De financiële consequenties hiervan worden eerder en duidelijker zichtbaar omdat outsourcen ook betekent dat de relatie tussen de business en IT (klant en leverancier) verzakelijkt. We zien daarom zowel aan de klant- als aan de leverancierskant initiatieven ontstaan om het requirementsproces te verbeteren. Een verstandige actie die veel meer organisaties zouden moeten oppakken. Goedkoper Voor wie zijn requirements gestructureerd opstelt en beheert is de beloning groot. Voor de onderbouwing van deze uitspraak hoeven we ons niet te beperken tot ervaringen bij professionele instellingen zoals de NASA. Financiële instellingen in Nederland hebben die ervaringen ook. Het gestructureerd opstellen van requirements met ondersteuning van een requirements-managementtool heeft tot gevolg dat een team van analisten ongeveer 2,5 keer zoveel projecten in dezelfde tijd kan ondersteunen. Door het gestructureerd opstellen en beheren van requirements kan een project als geheel 15 procent goedkoper worden. Overall gezien, ervaart de business een betere samenwerking met de IT-afdeling. Door requirements te realiseren die daadwerkelijk bijdragen aan de doelstellingen van de business, wordt de businesswaarde hoger. En dat bepaalt tenslotte het rendement van IT. Tinus Vellekoop werkt bij de divisie Software Control van Sogeti Nederland BV en is onder meer verantwoordelijk voor de dienstverlening Requirements Lifecycle Management (tinus. vellekoop@sogeti.nl)Structuur voor requirements Het is belangrijk een gemeenschappelijk beeld te hebben van wat requirements zijn. De volgende omschrijving is goed toepasbaar. Een requirement is een geformuleerde behoefte of eis aan IT-toepassingen. Om duidelijk te maken dat de termen ‘behoefte’ en ‘eis’ te maken hebben met onderscheid in niveaus van requirements wordt er vaak iets aan de omschrijving toegevoegd: Een requirement heeft betrekking op een doelstelling van de business, een te bieden ondersteuning of een eigenschap waaraan een toepassing moet voldoen. In de figuur is de samenhang tussen niveaus van requirements in de vorm van een piramide gevisualiseerd. De drie niveaus zijn: » Business Requirements Deze geven antwoord op de ’why’-vraag: waarom is er behoefte aan een IT-toepassing, welke businessdoelen wil de organisatie realiseren met behulp van het systeem? » User Requirements Deze geven antwoord op de ’what’-vraag: wat moet de gebruiker of in het algemeen de stakeholder met het systeem kunnen doen? » System Requirements Deze geven antwoord op de ’how’-vraag: hoe een systeem te ondersteunen? (Systeem is hierbij een ruim begrip.) De samenhang in niveaus wordt in de requirementsadministratie zichtbaar door het leggen van ‘parent/child’-relaties. Met dit inzicht kan gecontroleerd worden of business requirements worden ingevuld door requirements op lagere niveaus. Deze ‘parent/child’-relaties zijn ook van grote waarde om de impact van wijzigingen op requirements vast te stellen en de traceerbaarheid naar ontwerpen, programmacode en testgevallen mogelijk te maken. In de figuur is ook aangegeven dat er zowel functionele als niet-functionele requirements te onderkennen zijn. Met name niet-functionele requirements - denk aan performance, onderhoudbaarheid, beveiligbaarheid - worden in veel gevallen te laat, onvolledig en onvoldoende concreet opgesteld. Requirementsontwikkeling Veel organisaties hanteren het Capability Maturity Model Integration (CMMI) als referentiekader voor het verbeteren van systeemontwikkelingsprocessen. In CMMI worden Requirements Development en Requirements Management processen genoemd. Requirements Development is geplaatst op maturity level 3 en Requirements Management op level 2. De samenhang van deze processen komt hiermee niet echt tot uiting. Veelal ziet men Requirements Management als een volgtijdelijk proces na Requirements Development. Onterecht, want het wijzigingen-, versie- en statusbeheer en het traceren van verbanden tussen requirements moeten ook worden uitgevoerd tijdens de iteratieve requirements-developmentactiviteiten. Het Requirements Management start dus niet pas na het vaststellen van de baseline van requirements. Requirements-managementtool Het ondersteunen van Requirements Development en Requirements Management vraagt om inzet van een adequaat requirements-managementtool. In een dergelijk tool leg je bijvoorbeeld per requirement de volgende gegevens vast: identificatie, versie, de beschrijving, prioriteit, status, bron, eigenaar en onderlinge relaties. Het bijhouden van deze requirementsattributen en met name het onderhouden van relaties tussen requirements, waardoor bijvoorbeeld het bepalen van de impact van wijzigingen mogelijk wordt, betekent dat het gebruik van Word of Excel voor Requirements Management geen serieuze optie is. De meerwaarde van zo’n requirements-managementtool is ook dat het te koppelen is aan tools voor systeemontwikkeling, testmanagement en bevindingenbeheer. Dit maakt het managen van het totale kwaliteitsproces een stuk effectiever en efficiënter. De bekendste tools zijn: » -CaliberRM van Borland (http://www.borland.nl/ caliber/) » -Doors van Telelogic (http://www.telelogic.com/ products/doorsers/doors/) » --Reconcile van Compuware (http://www.compuware.com/products/reconcile.htm) » -RequisitePro van IBM Rational (http://www-136.ibm.com/ developerworks/rational/ products/requisitepro/) jzigingen gaan niet als ongeleide projectielen het project in