Onderzoek naar de kritieke succesfactoren bij het toepassen van requirements management binnen projecten Vrije Universiteit Amsterdam Faculteit der Economische Wetenschappen en Bedrijfskunde (FEWEB) Afstudeerrichting: Postgraduate IT auditing opleiding De Boelelaan 1105 1081 HV Amsterdam Begeleider Vrije Universiteit: E. Koning (DNB) KPMG IT Advisory Burgemeester Rijnderslaan 10-20 1185 MC Amstelveen Bedrijfsbegeleider: M. Vrins (KPMG) Auteur: D. Bremmer (KPMG)
Voorwoord Deze scriptie is geschreven in het kader van het afstudeertraject van de Postgraduate IT Audit Opleiding aan de Faculteit der Economische Wetenschappen en Bedrijfskunde (FEWEB) van de Vrije Universiteit Amsterdam. Ik heb ervoor gekozen deze scriptie te schrijven over het onderwerp requirements management binnen IT projecten. Requirements management is een boeiend onderwerp en mijns inziens één van de meest onderschatte kwesties in het bedrijfsleven en daar buiten. In de kern komt requirements management neer op het op een juiste manier vertalen van behoeften van A (vaak de business) naar B (vaak het orgaan dat de oplossing biedt op de behoefte). Deze communicatie blijkt in de praktijk weerbarstig te zijn gezien het grote aantal onderzoeken die telkens in deze richting wijzen wanneer het gaat om faalfactoren van projecten. Dit onderzoek richt zich op wat de succesfactoren zijn in deze vertaalslag. Ik heb dit onderzoek als een unieke manier gezien om het vakgebied requirements management vanuit verschillende perspectieven te bekijken. Ten eerste vanuit de literatuur en vervolgens vanuit de leverende en ontvangende partij in de praktijk. Ten slotte heb ik uitgebreid met deskundige collega s binnen KPMG over dit onderwerp gepraat. Mijn dank gaat daarom uit naar de verschillende personen die bereid zijn geweest om mee te werken aan dit onderzoek in de vorm van interviews. De interviews hebben een grote bijdrage geleverd aan de uiteindelijke realisatie van de scriptie. Daarnaast wil ik KPMG IT Advisory bedanken, voor de gelegenheid die is geboden om een passende afstudeeropdracht binnen de organisatie uit te voeren. Speciale dank gaat uit naar Evert Koning en Martijn Vrins als scriptiebegeleiders. Evert bedankt voor je kritische en constructieve houding. Martijn, bedankt voor je waardevolle inhoudelijke aanvullingen. Utrecht, oktober 2009 i
Samenvatting Uit onderzoeken blijken veel projecten te kampen met het niet behalen van hun oorspronkelijke doelstelling in termen van kosten, tijd en kwaliteit ondanks de toegenomen aandacht voor projectbeheersing. Eén van de meest belangrijke succes criteria van het doen slagen van een project is in een vroeg stadium van een project de juiste gebruikers behoeften (requirements) te doorgronden. Gedurende het ontwikkelproces wordt vaak veel tijd in beslag genomen door veranderende gebruikerseisen terwijl de ontwikkelaars al aan het werk zijn. Dit is niet het gevolg van onvoorziene ontwikkelingen in de technologie, maar veel vaker gaat het om voortschrijdend inzicht en technische complicaties. Met andere woorden zaken die te voorzien waren geweest als er beter was nagedacht over de op te leveren functionaliteit. Op basis van literatuurstudie is onderzocht wat de kritieke succesfactoren zijn van een beheerst requirement management proces in een project. Dit is onderzocht voor de algemeen geldende factoren voor requirements management en voor de specifieke factoren vanuit de meest toegepaste projectmanagement methode (PRINCE2) en de twee meest toegepaste systeem ontwikkel methodieken (SDM II; waterval methode en RUP; iteratieve methode). Vanuit de in de literatuurstudie onderkende succesfactoren is een relatie gelegd met Governance model CobiT. Er is een analyse uitgevoerd op de vier CobiT domeinen. Als resultaat is een inventarisatie uitgevoerd binnen de CobiT-processen die relevant zijn voor requirements management binnen projecten. Vervolgens is een analyse en beoordeling uitgevoerd van de control objectives binnen de geselecteerde CobiT processen voor het toetsen van requirements management in projecten. Tenslotte zijn per control objective op een generiek niveau de test activiteiten uitgewerkt. Dit heeft geleidt tot een concept control framework. Vervolgens is met behulp van een case studie een analyse uitgevoerd op het concept control framework met als doel de tekortkomingen en onvolkomenheden te identificeren. Daarnaast is het concept control framework op bruikbaarheid getoetst. De case studie is uitgevoerd bij een project van een verzekeraar waarbij een polisadministratie wordt geïmplementeerd. Het concept control framework is voorgelegd aan betrokkenen van de leverende- en de vragende kant van het project. Het framework is tevens besproken met een senior IT auditor van KPMG. Uit de analyse blijkt dat op basis van de vertaling van de succesfactoren naar control objectives een framework is aangereikt dat als uitgangspunt kan dienen voor een IT auditor. Het framework dient nog wel specifiek gemaakt te worden voor de situatie waarin het framework zal worden gebruikt. Op basis hiervan is een oordeel te geven over de effectiviteit van requirements ontwikkeling en requirements management in IT projecten. Wanneer de aanbevelingen op basis van het specifiek gemaakte concept control framework door het project worden overgenomen vergroot dit de slagingskans om toekomstige projecten met het gewenste resultaat op te leveren. Hierbij dient te worden opgemerkt dat audits vaak achteraf worden uitgevoerd. Dit is te laat om resultaten in het lopende project te bewerkstelligen. Dit kan worden ondervangen door tussentijdse/periodieke project audits uit te voeren, om zo tijdig te kunnen bijsturen. ii
Inhoudsopgave Voorwoord Samenvatting Inhoudsopgave i ii iii 1 Onderzoeksopzet 1 1.1 Aanleiding en probleemstelling 1 1.2 Doelstelling 2 1.3 Onderzoeksvraag 3 1.4 Methode 3 1.5 Opbouw scriptie 4 2 Requirements management 5 2.1 Wat is een requirement? 5 2.2 Verschillende typen requirement documenten 6 2.3 Technieken voor requirements verzameling 8 2.4 Wat is requirements management? 9 2.5 Traceerbaarheid tussen requirements 11 2.6 Samenvatting 11 3 Requirements management binnen IT projecten 13 3.1 Projectmanagementmethode 13 3.1.1 PRINCE2 14 3.1.2 Requirements management binnen PRINCE2 15 3.2 Systeem ontwikkeling methodieken 16 3.2.1 Meest toegepaste systeem ontwikkelingsmethodieken 16 3.2.2 Rational Unified Proces (RUP) 16 3.2.3 System Development Methodology II (SDM-II) 17 3.3 Samenvatting 18 4 Concept control framework requirements management 19 4.1 Inleiding 19 4.2 CobiT Framework 19 4.3 Inventarisatie van te selecteren CobiT-processen 20 4.4 Analyse van de relevante control objectives 20 4.5 Afronding 22 5 Validatie concept control framework 23 5.1 Inleiding 23 5.2 Casestudie 23 5.2.1 Gebruikers requirement 23 iii
5.2.2 Requirements ontwikkeling 23 5.2.3 Requirements management 24 5.2.4 Succesfactoren 25 5.3 Concept control framework 26 5.4 Conclusie 26 6 Conclusie 28 6.1 Inleiding 28 6.2 Analyse 28 6.3 Conclusie 28 7 Reflectie 30 Literatuurlijst 31 Geïnterviewden en begeleiders 32 Geïnterviewden 32 Begeleiders 32 A Kwaliteitsaspecten NEN-ISO 9126 33 B PRINCE2 35 B.1 Faseringen binnen het PRINCE2-procesmodel 35 B.2 Componenten van projectmanagement binnen PRINCE2 35 C Verdeling van meest gebruikte systeem ontwikkeling methodieken 37 D Rational Unified Proces 38 E SDM II 39 F CobiT Model 40 G CobiT concept control framework 42 G.1 Plan and Organize 42 G.2 Acquire and implement 48 H Casestudy 52 H.1 Background 52 H.2 Requirement and Solution 52 H.3 What went well? 54 H.4 Lessons learned? 54 iv
1 Onderzoeksopzet In dit hoofdstuk wordt achtereenvolgens de aanleiding en probleemstelling, de doelstelling, de vraagstelling, de gehanteerde methode en de opbouw van de rapportage besproken. 1.1 Aanleiding en probleemstelling Bij organisaties in de financiële sector (banken en verzekeraars) worden continue nieuwe projecten in een hoog geautomatiseerde omgeving geïnitieerd. De aanleiding voor deze veranderingen zijn uiteenlopend, zoals het vanuit compliance oogpunt moeten voldoen aan nieuwe wet en regelgeving, nieuwe eisen en wensen vanuit de gebruikersorganisatie, introductie van nieuwe producten en het vervangen van complete legacy systemen en architecturen om kosten te reduceren. Veel projecten blijken in de praktijk te kampen met het niet behalen van hun oorspronkelijke doelstelling in termen van kosten, tijd en kwaliteit ondanks de toegenomen aandacht voor projectbeheersing. De belangrijkste oorzaak voor het mislukken van projecten blijkt vaak te liggen in het feit dat projectdoelstellingen ambitieus en complex zijn. Er is veel literatuur beschikbaar over hoe projecten moeten worden gemanaged en hoe de risico s binnen projecten het beste kunnen worden beheerst. Desondanks weet volgens onderzoek van de Standish Group 1 slechts 32% van de projecten het gewenste resultaat te leveren. 44% van de projecten worden opgeleverd met een overschrijding van het budget, de planning of met beperkte functionaliteit. Van 24% van de projecten is gezegd dat projecten voortijdig zijn gestopt en functionaliteit nooit is gebruikt. Eén van de in het rapport opgenomen succes criteria, is in een vroeg stadium van een project de juiste gebruikers behoeften (requirements) te doorgronden. Gedurende het ontwikkelproces wordt vaak veel tijd in beslag genomen door veranderende gebruikerseisen terwijl de ontwikkelaars al aan het werk zijn. Dit is niet het gevolg van onvoorziene ontwikkelingen in de technologie, maar veel vaker gaat het om voortschrijdend inzicht en technische complicaties. Met andere woorden zaken die te voorzien waren geweest als er beter was nagedacht over de op te leveren functionaliteit. Deze scriptie richt zich op het spanningsveld van de vertaling van de gebruikers behoefte naar een technische oplossing. Deze vertaling kenmerkt zich door een hoge complexiteit en onderlinge afhankelijkheid tussen verschillende (nieuwe) functionaliteiten. Deze aspecten worden versterkt wanneer de behoeften gedurende een project veranderen. Daarnaast spelen er tevens verschillende belangen. Een IT organisatie is binnen een project gebaat bij een situatie waarin de vooraf gedefinieerde behoeften zo min mogelijk wijzigen. Daar staat tegenover dat de opdrachtgever van een project in een snel veranderende omgeving vaak flexibiliteit wenst te houden en geen gefixeerde requirements. De opdrachtgever van een IT project komt meestal uit de gebruikersorganisatie (de business) en het zwaartepunt van de uitvoering van een project ligt meestal bij de IT organisatie. Een mogelijk gevaar bestaat dat het project door de IT organisatie als een zuiver technische uitdaging wordt gezien. Het IT project zal dan voor het behalen van de doelstellingen de neiging 1 Standish Group report CHAOS 2009 1
hebben om te sturen op tijd en kosten en niet zozeer op de specifieke behoefte van de gebruikersorganisatie. Daar staat tegenover dat vanuit de gebruikersorganisatie vaak door de conceptuele status van de behoeften (kwaliteit), een vooraf bepaald budget (kosten) en tijdslijn een interessante uitdaging wordt meegegeven. De variabelen tijd en kosten van het project worden vastgezet, waardoor de enige vrijheid van het project kan worden gevonden in de op te leveren kwaliteit of functionaliteit van het product. Tijd en kosten zijn relatief eenvoudig meetbaar en stuurbaar te maken. Het probleem van het meetbaar en stuurbaar maken van kwaliteit ligt al in de definitie ervan besloten. Kwaliteit is in de praktijk een subjectief gegeven, dit wordt voornamelijk veroorzaakt doordat de requirements niet duidelijk gespecificeerd (kunnen) worden en kwaliteit langs veel aspecten gemeten kan worden. Hierbij valt bijvoorbeeld te denken aan de indeling van kwaliteitsaspecten volgens NEN-ISO 9126. De kwaliteitsaspecten zijn ter illustratie opgenomen in bijlage A. De kwaliteit van een product zegt iets over de mate waarop het product voldoet aan de vooraf gestelde acceptatie criteria. Deze acceptatie criteria zijn af te leiden uit de requirements. Hierdoor is ook kwaliteit meetbaar en stuurbaar te maken. De probleemstelling luidt: Succesvol afronden van IT projecten wordt vaak belemmerd doordat de randvoorwaarden voor een beheerst requirements management proces ontbreken, wat nadelig is voor de kwaliteit van de requirements definitie. 1.2 Doelstelling De doelstelling van deze scriptie is om te onderzoeken wat de kritieke succesfactoren zijn van een beheerst requirement management proces in een project. Verder zal worden onderzocht hoe de inrichting van het requirements management proces binnen projecten door de IT auditor kan worden getoetst met behulp van een door dit onderzoek samengesteld concept control framework. De scope van dit onderzoek is de requirements definitie waarmee de behoefte vanuit de gebruikersorganisatie wordt vertaald naar een technisch oplossing en het requirements managent proces dat deze vertaling ondersteunt. In figuur 1 is dit op een hoog niveau weergegeven. Figuur 1: Requirements management proces binnen projecten 2
1.3 Onderzoeksvraag De onderzoeksvraag van de scriptie luidt: Welke succesfactoren binnen het requirements management proces in de literatuur en praktijk dragen bij aan de ontwikkeling van een control framework om tot een beheerst requirements management proces te komen, waarmee de slagingskans toeneemt om projecten met het gewenste resultaat op te leveren? Om de onderzoeksvraag te kunnen beantwoorden, dienen de volgende deelvragen te worden beantwoord: a. Wat wordt in de literatuur verstaan onder requirements management en wat is het doel van het requirements management proces? b. Wat zijn de in de literatuur beschreven randvoorwaarden voor een beheerst requirements management proces? c. Welke methodieken worden in de praktijk het meest toegepast om een beheerst requirements management proces binnen projecten te ondersteunen? d. Hoe verhouden deze inzichten zich tot de in CobiT opgenomen algemene normen voor IT Governance en beheersmaatregelen voor IT organisaties om te komen tot een concept control framework? e. Is het in dit onderzoek ontwikkelde concept control framework bruikbaar in de praktijk en welke aanvullende succesfactoren worden vanuit de praktijk benoemd? 1.4 Methode Het onderzoek wordt uitgevoerd door middel van de volgende onderzoeksmethodieken: literatuurstudie; case studie: interviews met projectleiders en betrokkenen van een project binnen een verzekeringsmaatschappij. De literatuurstudie heeft als doel om inzicht te verschaffen in wat onder requirements management wordt verstaan en wat volgens de literatuur de succesfactoren binnen het requirements management proces zijn. Daarnaast is door middel van interviews en een case studie onderzocht hoe in de praktijk wordt omgegaan met het beheersen van requirements binnen een project. Op basis van de succesfactoren vanuit de literatuur en de casestudie is een concept control framework opgesteld. Dit concept control framework kan door een IT auditor als uitgangspunt worden gebruikt bij het toetsen van een requirements management proces gedurende een project audit. 3
1.5 Opbouw scriptie De opbouw van deze scriptie is als volgt. In hoofdstuk twee wordt ingegaan op requirements ontwikkeling en requirements management. In hoofdstuk drie zal van de meest gebruikte project management- en systeem ontwikkeling methodieken worden beschreven hoe zij het requirementsmanagement proces ondersteunen. De in hoofdstuk twee en drie beschreven succesfactoren van requirements management zijn het uitgangspunt voor een concept control framework dat in hoofdstuk vier wordt beschreven. Dit concept control framework zal doormiddel van een case studie in de praktijk worden gevalideerd. Dit is beschreven in hoofdstuk vijf. Deze scriptie is geschreven in het kader van de IT Audit opleiding aan de Vrije Universiteit van Amsterdam. Om deze reden zal ook stil worden gestaan bij het belang en de gevolgen van dit onderzoek voor het vakgebied IT auditing. Dit wordt in hoofdstuk zes beschreven. Ten slotte wordt in hoofdstuk zeven mijn persoonlijke reflectie beschreven. 4
2 Requirements management In dit hoofdstuk wordt beschreven wat requirements zijn en welke technieken voor handen zijn om requirements inzichtelijk te maken en te documenteren. Deze fase is kort te omschrijven als de requirements ontwikkel fase. Ten slotte wordt beschreven hoe het requirements management proces kan worden ingericht, zodat de ontwikkelde requirements op een gecontroleerde manier kunnen worden beheerd. 2.1 Wat is een requirement? Voordat we naar het requirements management proces kijken moet eerst worden bepaald wat een requirement daadwerkelijk is. In de Van Dale is het engelse woord requirement vertaald als eis/vereiste of behoefte/ benodigdheid. In projecten is het engelse woord requirement al een veel gebruikt begrip, daarom zal in deze scriptie de engelse variant wordt gebruikt. Daarnaast zijn in de literatuur verschillende definities terug te vinden waarin de verklaring van het begrip requirement wordt gegeven. Hieronder worden enkele definities beschreven. Volgens de IEEE Standard 2 is een requirement het beste te definiëren als: 1. Een conditie of vermogen dat nodig is voor een gebruiker om een probleem op te lossen of om een doel te behalen. 2. Een conditie of vermogen dat een systeem (onderdeel) moet bereiken of bezitten om te voldoen aan een contract, standaard, specificatie of een ander formeel afgedwongen document. 3. Een gedocumenteerde representatie van een conditie of vermogen zoals in (1) en (2) Een andere definitie is de volgende 3 : Requirements zijn specificaties van datgene dat moet worden geïmplementeerd. Dit zijn beschrijvingen van hoe het systeem zich moet gedragen. De volgende definitie 4 is een combinatie van de twee bovengenoemde en daarom gebruikt voor deze scriptie. 2 IEEE Standard Glossary of Software Engineering Terminology (1990) 3 Requirements Engineering A good practice guide (Sommerville en Sawyer, 1997) 4 Software requirements: practical techniques for gathering and managing (Wiegers, 2005) 5
Een uiteenzetting van een behoefte of doelstelling of een conditie of vermogen over wat een product moet bevatten, zodat dit toereikend is om de behoefte of doelstelling van de opdrachtgever te beantwoorden. Vereenvoudigd wil dit zeggen dat het gaat om de vaststelling van de behoeften van een opdrachtgever ten aanzien van een systeem. Hierbij is het van belang de nadruk te houden op de behoeften van de opdrachtgever, zodat niet het risico wordt gelopen gedurende het verloop van het IT project het beschrijven van de technische oplossing van het probleem voorop te stellen. Requirements zijn belangrijk omdat ze de behoeften van de opdrachtgever en de gebruikers weergeven. Dit biedt de basis voor de verdere werkzaamheden binnen een IT project. Goed gedefinieerde requirements geven weer wat de tussen de opdrachtgever/gebruikers en de leverende partij overeengekomen functionaliteit moet bevatten. Dit is een basis voor de verdere werkzaamheden. Daarnaast definiëren requirements wat er moet worden opgeleverd en niet het hoe. Ten slotte vormen de requirements de basis voor het bepalen van tijd, kosten en de kwaliteit in een project, hierin schuilen tevens de acceptatiecriteria. Verder is naast de betekenis van het begrip requirements ook onderscheid te maken in het niveau van requirements. In de praktijk blijken verschillende belanghebbenden behoefte te hebben aan verschillende niveaus en detaillering van het begrip requirements. De verschillende niveaus die terug zijn te zien in projecten wordt verder beschreven in paragraaf 2.2. Maar een grove indeling is als volgt. Op het hoogste niveau geeft de opdrachtgever/sponsor een projectmanager een projectdoelstelling mee. Dit is voor beide partijen de requirement. Voor gebruikers, analisten en ontwikkelaars is dit niveau van requirements definitie echter te algemeen, zij verwachten een beschrijving waarin veel detail is aangebracht. 2.2 Verschillende typen requirement documenten Het onderstaande requirements model van Wiegers geeft de relaties weer tussen de diverse lagen van requirements (gebruikers en functionele requirements) en tussen de functionele en niet functionele requirements. Daarnaast is per laag aangegeven in welk type document een requirement wordt vastgelegd gedurende het requirements ontwikkel proces. 6
Functional requirements Non-Functional requirements Business requirements Visie en Scoping User requirements Business rules Quality attributes Use Case Interfaces Technical requirement Functional requirement Constrains Software requirement specifications Figuur 2: Het requirementmodel, (Wiegers, 2003) Hieronder zijn enkele van de in bovenstaand model opgenomen type requirements documenten beschreven: In het visie en scope document worden de business requirements vastgelegd. De business requirements geven op een conceptueel niveau de behoefte van de organisatie of opdrachtgever weer en waarom die behoefte er is. De business requirements zijn vaak afkomstig van de sponsor van het project, de opdrachtgever, de manager van de toekomstige gebruikers of product ontwikkeling/marketing. In use cases worden de gebruikers requirements vastgelegd. De gebruikers requirements behelzen de doelen of taken van wat de gebruikers wensen te doen met het nieuwe systeem. Per use case wordt vaak 1 proces weergegeven en een voorbeeld hiervan is het proces: voer een nieuwe polis op voor een verzekeringsproduct. Verder worden in de use case van een proces de precondities en de actoren vastgelegd. Voor het genoemde voorbeeld is een preconditie dat de gebruiker dient te zijn ingelogd in het systeem voordat een nieuwe verzekeringspolis kan worden ingevoerd. Actoren kunnen gebruikers maar ook ander systemen zijn. Functionele requirements geven weer wat de software functionaliteit is die door de ontwikkelaars dient te worden gebouwd, zodat de gestelde business requirements worden 7
behaald. De functionele requirements zijn gedocumenteerd in de software requirements specificatie. In de software requirements specificatie is zo volledig als nodig de werking van het systeem beschreven. Naast de functionele requirements zijn in de software requirements specificatie ook de niet functionele requirements beschreven. Dit kunnen onder andere de gewenste perfomance van het systeem en de karakteristieken (gebruikersgemak, integriteit, efficiency en robuustheid) zijn. Andere niet functionele requirements zijn de interfaces met andere systemen (bijvoorbeeld communicatie via xml met de gemeentelijke basis administratie) en de design en implementatie beperkingen (de constraints). De constraints schrijven de beperkingen voor waar tot de ontwikkelaar zich aan moeten houden met betrekking tot het ontwerp (bijvoorbeeld de gebruikersinterface) en het bouwen (bijvoorbeeld alleen mogen programmeren in JAVA). Het ontwikkelen van requirements is een iteratief proces, waarbij telkens als een nieuwe functionaliteit wordt gevraagd, terug zal moeten worden gekeken in het scoping document om te bepalen of de functionaliteit tot de scope behoort of niet. Wanneer dit niet het geval is zal de opdrachtgever van het project aan moeten geven of de scope wordt uitgebreid of niet. Deze communicatie over en weer vergt een goede en heldere communicatie tussen de opdrachtgever en de opsteller(s) van de requirements. Het uitbreiden van de scope heeft directe gevolgen voor de planning en het budget. Dit geeft het sturende vermogen van goed gedefinieerde requirements documenten aan. Er kan namelijk niet worden gestuurd op requirements die op meerdere manieren zijn te interpreteren. Zij vormen dan een onvolledige en mogelijk onjuiste basis voor de acceptatiecriteria van het op te leveren systeem. 2.3 Technieken voor requirements verzameling Het opstellen en vaststellen van de requirements is een uitdagend proces, dat moet resulteren in requirements die SMART (specifiek, meetbaar, acceptabel, realistisch en tijdgebonden) en samenhangend zijn. Activiteiten die daarom moeten worden uitgevoerd om requirements vast te stellen zijn 5 : verzamelen van requirements (elicitation); analyseren van requirements (analysis); specificeren van requirements (specification); valideren van requirements (validation). Deze activiteiten worden per requirements niveau uitgevoerd en hebben invloed op elkaar. Dit heeft te maken met de relaties tussen de niveaus. Business requirements (doelstellingen) geven bijvoorbeeld richting aan de gebruikers requirements (processen). Daarnaast zijn bij de verschillende requirements niveaus verschillende belanghebbenden betrokken (zoals: de 5 Guide to the software engineering body of knowledge (Abran, 2005) 8
stuurgroep/opdrachtgever, de projectmanager, het projectteam) en zijn er meerdere mogelijkheden om de requirements te verzamelen, te weten: 6 Modeleren, door middel van een vereenvoudigde weergave van de gewenste behoefte; Document analyse, veel projecten zijn een gevolg van een eerder uitgevoerd project, door document analyse is gebruik te maken van de eerder opgestelde requirements; Checklists, worden gebruikt om te waarborgen dat geen van de belangrijke activiteiten of informatie wordt vergeten; Brainstorming, gedurende brainstormsessie wordt in korte tijd een grote hoeveelheid out-ofthe-box ideeën gegenereerd. Vervolgens worden de ideeën op haalbaarheid beoordeeld; Mind Maps, in een mind map worden grafisch de verbanden binnen een deelgebied weergegeven. Het hoofd onderdeel wordt in het midden weergegeven en alle ideeën en gedachten worden er omheen geordend; Interviews, in een interview wordt direct de mening van verschillende betrokkenen gevraagd. Dit is een van de meest voor de handliggende manieren van informatie verzamelen, maar blijkt in de praktijk niet effectief te zijn. Observatie, door middel van observatie van informatie vastleggen hoe processen lopen. Het eindresultaat van requirements ontwikkeling is de baseline. Een baseline is een verzameling overeengekomen requirements die de ontwikkelingsfase ingaat. Zoals eerder beschreven heeft onafhankelijk van de manier waarop requirements worden verzameld requirements ontwikkeling een iteratief karakter. Er zijn vaak meerdere slagen nodig om tot de benodigde requirements definitie te komen. De geformuleerde requirements kunnen na de afstemming vervolgens worden beheerd in het requirements management proces. Dit proces wordt in de volgende paragraaf beschreven. 2.4 Wat is requirements management? De in deze scriptie gehanteerde definitie voor requirements management luidt 7 : 6 Requirements Management: The interface between Requirements Development and all other systems engineering processes (Hood, 2008) 7 The future of requirements management tools (A.Finkelstein and W. Emmerich, 2000) 9
Requirements management is een systeem ontwikkel activiteit die zich bezig houdt met het organiseren, documenteren en groeperen van requirements voor systemen waarbij de focus ligt op het onderhouden van traceerbaarheid van wijzigingen op requirements. Onder requirements management zijn de volgende activiteiten te verstaan: Het aftekenen van de requirements baseline. Dit document wordt door alle partijen ondertekend en goedgekeurd als uitgangspunt dat beantwoord aan de in de scoping benoemde behoefte. Het reviewen van requirements wijzigingen en het bepalen van de impact van de wijziging op de overige functionaliteit, het budget en de planning. Het op een gecontroleerde wijze toevoegen van de geaccepteerde wijziging in het bestaande project. Hiervoor is diverse tooling beschikbaar. In hoofdstuk 3 wordt de door ondersteunende tooling voor Rational Unified Proces (RUP) benoemd. Het updaten van projectplannen (scoping documenten) op basis van de nieuw aangeleverde requirements. Onderhandelen van nieuwe afspraken gebaseerd op de voorspelde impact van de gewijzigde requirements. Het traceren van de individuele requirements naar corresponderende design, broncode en testgevallen. Het traceren van de requirements statussen en wijziging activiteiten gedurende het project. Deze activiteit valt samen met de in hoofdstuk 3 verder uitgeschreven verantwoordelijkheid van configuratie management binnen een project/systeem ontwikkel methodiek. In onderstaande figuur 3 is schematisch weergegeven wat het onderscheid is tussen requirements ontwikkeling en requirements management. 10
Figuur 3: Onderscheidt tussen requirement ontwikkeling en requirement management, (Wiegers, 2003) 2.5 Traceerbaarheid tussen requirements Een belangrijk element van requirements management is het administreren van traceability tussen de requirements. Dit wil zeggen het leggen van verbindingen tussen high level gebruikers requirements en ondergelegen requirements tot aan systeemspecificaties. Zodoende is de herkomst van iedere requirement te traceren. Echter het koppelen van requirements is arbeidsintensief proces en het leggen en onderhouden van traces vereist ervaring. 2.6 Samenvatting Op basis van de bestudeerde literatuur (zie literatuurlijst) wordt hieronder samenvattend weergegeven wat de succes factoren in een beheerst requirements ontwikkeling en requirementsmanagement proces zijn. Nummer Succesfactor S1 S2 Formuleer de acceptatiecriteria voor de requirements zo vroeg mogelijk in het project. Kwaliteit is voldoen aan de verwachtingen van de opdrachtgever. Om te voorkomen dat het eindresultaat afwijkt van de behoeften van de opdrachtgever (b.v. door scope creep) dienen de ontwikkelde requirements continue te worden vergeleken met de verwachtingen van de opdrachtgever. 11
S3 S4 S5 S6 S7 S8 S9 Om scope creep binnen het project te voorkomen dient bij het ontwikkelen van requirements continue worden afgevraagd of nieuwe functionaliteit nog behoord tot de initiële scope. Requirements dienen bij de oplevering te voldoen aan de in het visie of scope document benoemde behoefte. Maak voor de verschillende detailniveaus van requirements definiëring verschillende typen documentatie. Aan scoping documentatie (in bijvoorbeeld het project plan) wordt een ander detailleringniveau gesteld dan aan het vastleggen van de gebruikers behoeften (in bijvoorbeeld een use case). Kwaliteit zit vooral verankerd in de mensen. Zorg ervoor dat medewerkers die verantwoordelijk zijn voor het schrijven van de requirements voldoende ervaring hebben met de processen en de kwaliteitsrichtlijnen. De requirements dienen SMART (specifiek, meetbaar, acceptabel, realistisch en tijdgebonden) te zijn gedefinieerd. De opgeleverde requirements dienen te worden gebaselined en door de opdrachtgever te worden ondertekend en goedgekeurd. De baseline dient het uitgangspunt voor het verdere ontwikkelproces te zijn. Zodoende zijn heldere randvoorwaarden aan de op te leveren functionaliteit gecreëerd in termen van kosten, tijd en de kwaliteit. In de baseline schuilen tevens de acceptatiecriteria (mits ongewijzigd). Verbindingen tussen high level gebruikers requirements, ondergelegen requirements tot aan systeemspecificaties dienen traceerbaar te zijn. In het volgende hoofdstuk zal worden beschreven welke projectmanagement en systeem ontwikkel methodieken volgens onderzoek in de praktijk het meeste worden toegepast en hoe zij het requirementsmanagement proces ondersteunen. Hieruit zullen vervolgens specifiek geldende elementen als succesfactoren worden benoemd die in een beheerst requirements management proces te verwachten zijn. 12