Handboek Requirements
Brug tussen business en ICT
ISBN 978 90 5972 406 8 (paperback) ISBN 978 90 5972 407 5 (ebook) Eburon Business Postbus 2867 2601 CW Delft tel.: 015-2131484 / fax: 015-2146888 info@eburon.nl / www.eburonbusiness.nl Omslagontwerp: Textcetera
Afbeelding omslag: © UN Studio, Erasmusbrug, c/o Pictoright Amsterdam 2010.
© 2010 Nicole de Swart. Alle rechten voorbehouden. Niets uit deze uitgave mag worden ver-veelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in eni-ge vorm of op enieni-ge wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen, of op enig andere manier, zonder voorafgaande schriftelijke toestemming van de rechthebbende.
v
Inhoud
Voorwoord ix
Dankwoord xi
Inleiding xiii
Deel I Positionering requirements 1
Hoofdstuk 1
Belang van requirements 3
De brugfunctie van requirements 3
De belanghebbenden 5
Effect van foutieve requirements 6
Kritieke succesfactoren 8
Onderschatting vakgebied 10
Samenvatting 10
Hoofdstuk 2
Requirements 13
Wat is een requirement? 13
Wat is een requirement niet? 18
Samenvatting 22
Hoofdstuk 3
Requirements Engineering 23
Softwareontwikkeling 23
Het vakgebied Requirements Engineering 25
Requirements Development 27 Requirements Management 29 Samenvatting 30 Hoofdstuk 4 Requirementsanalist 33 Rol en verantwoordelijkheid 33 Competenties 35 Training 37 Samenvatting 38
Deel II Typen requirements 41
Hoofdstuk 5
Requirementsmodel 43
Introductie 43
Systeemperspectief 44
vi
Opkomst agile softwareontwikkeling 49
Samenvatting 50
Hoofdstuk 6
Businessrequirements 51
Toegevoegde waarde 51
Scope van het systeem 53
Businessdoelen 54 Businessrequirements in de praktijk 56 Samenvatting 58 Hoofdstuk 7 Gebruikersrequirements 59 Businessperspectief 59 Use cases 61 User stories 64 Samenvatting 65 Hoofdstuk 8 Softwarerequirements 67 Functionele softwarerequirements 67 Niet-functionele softwarerequirements 70 Samenvatting 77
Deel III Requirementsproces 79
Hoofdstuk 9
Requirementsproces 81
Generiek requirementsproces 81
Softwareontwikkelproces 84
Subgebieden van Requirements Development 86
Samenvatting 89
Hoofdstuk 10
Requirements Development 91
Processtappen 91
Positioneer het systeem binnen het businessdomein 92
Definieer de gewenste oplossing 94
Detailleer de requirements 97 Samenvatting 99 Hoofdstuk 11 Requirementstechnieken 101 Elicitatietechnieken 101 Analysetechnieken 104 Specificatietechnieken 107 Validatietechnieken 110 Samenvatting 112 Hoofdstuk 12 Requirements Management 115 Belang 115 Beheer de requirements 116
vii
Pijlers 118
Samenvatting 122
Deel IV Praktische uitvoering 123
Hoofdstuk 13 Elicitatietechnieken 125 Interviewen 125 Prototype maken 131 Workshops houden 132 Observeren 135 Samenvatting 136 Hoofdstuk 14 Analysetechnieken 137 Conceptueel modelleren 137 Prioriteren 143 Prototype maken 146 Categoriseren 147 Samenvatting 147 Hoofdstuk 15 Specificatietechnieken 149 Formuleren 149 Tekst structureren 155 Requirementspatronen toepassen 159 Samenvatting 160 Hoofdstuk 16 Validatietechnieken 161 Reviewen 161 Inspecteren 163 Doorspreken 166 Samenvatting 167 Deel V Verdieping 169 Hoofdstuk 17 Belanghebbenden 171 Belanghebbenden en requirements 171
Belanghebbenden bij het businessdoel 172
Belanghebbenden bij het systeem 173
Belanghebbenden bij het project 175
Samenvatting 177
Hoofdstuk 18
Gesprekspartners 179
Analyse naar belanghebbenden en gesprekspartners 179
Identificeren van belanghebbenden 180
Zoeken van vertegenwoordigers 182
Maken van samenwerkingsafspraken 183
Vastleggen belanghebbenden en afspraken 185
viii Hoofdstuk 19 Requirementsproducten 187 Doel 187 Kwaliteit 188 Requirementsproducten 191 Samenvatting 194 Hoofdstuk 20 Niet-functionele softwarerequirements 195 Onderbelicht 195 Tastbaar maken 198 Samenvatting 203 Hoofdstuk 21 Use cases 205 Voordelen 205
Use case model 206
Use case specificatie 211
Samenvatting 216
Bijlagen 219
Bijlage A Bedrijfsregels 221
Bijlage B Typeringen van requirements 223
Bijlage C ISO 9126 Kwaliteitseigenschappen 229
Bijlage D Requirementsprocessen 231
Bijlage E Modelleertechnieken 237
Bijlage F Templates van requirementsproducten 245
Bijlage G Hotelcasus 251
Begrippenlijst 265
Geraadpleegde literatuur 279
ix
Voorwoord
Ik heb in de loop der jaren veel requirements voor vele projecten gezien. Ik moet hier-bij vaak denken aan de bekende uitspraak: “Pas op wat je wenst, het zou wel eens uit kunnen komen.” Als de wensen en eisen onduidelijk zijn, inconsistent of incompleet, zal de software die je uiteindelijk krijgt dat op zijn best ook zijn. Dit soort requirements is he-laas eerder regel dan uitzondering. En als de requirements wel goed beschreven zijn, blijft er de achterliggende vraag: “Is dit werkelijk wat je wilt?” Mensen beschrijven vaak een oplossing maar niet de achterliggende requirements. Daarmee kan de oplossing niet gevalideerd worden en worden eventuele betere en/of goedkopere oplossingen uitgesloten. Nee, het is niet eenvoudig om te weten wat je wilt en dat ook nog eens helder op te schrijven.
Het is onmogelijk om, uitgaande van dit soort requirements, software te bouwen die hieraan voldoet. Vanuit het software-project is er dan ook vaak de vraag om ver-duidelijking en betere uitwerking van de requirements. Maar hoe doe je dat?
De noodzaak om op een betere manier om te gaan met requirements is evident. Een kwaliteitsimpuls is hard nodig. Het boek dat u voor u heeft is een uitgebreide in-troductie in het complete requirements- vakgebied. Het beschrijft wat er allemaal bij komt kijken, welke soorten requirements we kunnen onderscheiden en hoe we die op kunnen schrijven. Het gaat in op wie er vanuit welke verantwoordelijkheid betrokken is en hoe zij met zijn allen op de juiste manier de echte wensen van de business en ge-bruikers boven tafel kunnen krijgen. En niet te vergeten … hoe om te gaan met veran-derende requirements. De wereld staat immers niet stil terwijl wij de software bouwen. Dit boek is niet bedoeld als kookboek. Het is bedoeld om alle facetten van requi-rements engineering te leren kennen en ermee om te leren gaan. De auteur geeft met behulp van voorbeelden en tips, gebaseerd op haar eigen uitgebreide ervaring, inzicht in de voor- en nadelen van de besproken technieken en werkwijzen. Uiteindelijk is het aan uzelf om de keuze te maken welke aspecten op welke wijze het best bij u passen. Dit boek geeft u een solide basis om de juiste keuzes voor uw eigen situatie te maken.
Jos Warmer Auteur 'Praktisch UML'
xi
Dankwoord
Aan dit boek heb ik anderhalf jaar gewerkt. Dat heb ik met veel plezier gedaan, maar het was niet altijd gemakkelijk. Soms leek er geen einde aan te komen. Gelukkig heb-ben veel mensen me aangemoedigd en gesteund. Van collega's en andere vakgenoten heb ik geregeld belangstellende reacties, waardering en gevraagde en ongevraagde feedback mogen ontvangen. Jan Campschroer, Remi-Armand Collaris, Carel Daams, Eef Dekker, Rob van Kampen, Frans van Koppen, Jan Bart Laan, Rogier Lommers, Erik van Loon, Martin Muller, Anko Tijman en al die anderen: bedankt daarvoor.
Het schrijven van Handboek Requirements heeft meer tijd en energie gekost dan ik vooraf had ingeschat. Ik heb me er helemaal in vastgebeten. De mensen om me heen hebben dat gemerkt. Ik was altijd met dit boek bezig en had geen tijd meer voor andere dingen. Mijn familie, vrienden en in de eerste plaats mijn man hebben me vooral het laatste halfjaar vele uren moeten missen. Fijn dat jullie mij die ruimte hebben gegeven. Ik ben jullie dankbaar.
Ik heb het schrijven van dit boek aangepakt als een project. De agile-principes voor softwareontwikkeling blijken ook in andere typen projecten vruchten af te werpen (voor meer informatie zie www.Reaco.nl). Dit project bestond uit iteraties van zes dagen. Aan het einde van iedere iteratie leverde ik publiceerbare tekst op. Dit was me niet gelukt zonder de medewerking van mijn sparringpartner en mijn review-team. Barbara Wijnen, Chan Kerste, Lisenka Callenbach, Erwin Stelling, Bert Hoefslot en Rik Hendriks: super dat jullie mij iedere iteratie opnieuw van advies en kritisch commentaar wilden voorzien. Zonder jullie had dit boek er heel anders uitgezien. Len-nart, bedankt voor je verfrissende ideeën en kritische blik.
Verder wil ik bedanken: Peter Smulders, Bettina Logge, Jurriaan Fleijsman en Kit-ty Pettinga. De hulp die jullie me geboden hebben waardeer ik zeer. Tot slot, maar ze-ker niet in de laatste plaats, bedank ik Peter Janssen voor zijn geduld en scherpe feed-back.
Nicole de Swart Maurik, juni 2010
xiii
Inleiding
Requirements vervullen binnen de softwareontwikkeling een belangrijke rol; daar zijn de meeste ICT’ers het wel over eens. Ik heb veel ICT-projecten zien worstelen met het opstellen van requirements. De projecten waarin ik gedetacheerd werd bleken groten-deels met dezelfde problemen te kampen. Of het nu ging om een profit of non-profit organisatie, om een groot of een klein project, een intern uitgevoerd of een uitbesteed project. Er waren vaak problemen met de kwaliteit van de specificaties, de afstemming met de gebruikersorganisatie en met de alsmaar wijzigende requirements.
Bij het opleiden en coachen van vakgenoten heb ik gezien welke kennis en vaar-digheden essentieel zijn voor het opstellen en managen van requirements. Dezelfde valkuilen en misverstanden kwamen steeds opnieuw te voorschijn. De uitdaging zit hem niet in het kiezen van de juiste methoden en technieken, maar in de toepassing er-van in de praktijk. Dit handboek introduceert daarom geen nieuwe theorieën, maar plaatst de bestaande methoden en technieken in perspectief en geeft praktische hand-vatten voor de uitvoering ervan.
Handboek requirements is geschreven voor diegenen die zich willen verdiepen in het vakgebied Requirements Engineering. Het biedt overzicht, geeft inzicht in het vakge-bied en is bovenal toepasbaar in de praktijk. De opbouw van het boek maakt het mo-gelijk om snel informatie en praktische tips over een specifiek onderwerp te vinden. Bij integrale lezing neemt Handboek requirements de lezer mee door het vakgebeid. Van de kern van het vakgebied naar meer diepgang en de praktische toepassing ervan.
Het boek is opgebouwd uit vijf delen. Deel I positioneert het vakgebied Require-ments Engineering binnen de softwareontwikkeling en geeft de lezer snel inzicht in de kern van het vakgebied. Deel II gaat uitgebreid in op de diverse typen requirements. Het requirementsproces en alle activiteiten en technieken die daarin een rol spelen zijn in het derde deel opgenomen. Deel IV is een aaneenschakeling van praktische handvat-ten voor het uitvoeren van het requirementsproces. Het vijfde en laatste deel brengt verdieping aan in belangrijke onderwerpen als belanghebbenden, niet-functionele re-quirements en use cases.
Tenzij uitdrukkelijk anders vermeld wordt in dit boek met 'systeem' een 'geauto-matiseerd systeem' bedoeld. Omwille van de leesbaarheid spreekt dit boek over 'hij'. Hiervoor mag vanzelfsprekend ook 'zij' gelezen worden.
Deel I Positionering requirements
Dit eerste deel laat zien welke positie het vakgebeid requirements inneemt binnen softwareontwikkeling. Degenen die minder bekend zijn met requirements krijgen zo snel inzicht in de kern van het requirementsvakgebied. De andere delen brengen hier meer diepgang in. Deel I bestaat uit de volgende hoofdstukken.
Hoofdstuk 1 Belang van requirements Hoofdstuk 2 Requirements
Hoofdstuk 3 Requirements Engineering Hoofdstuk 4 Requirementsanalist
Het eerste hoofdstuk gaat over het belang van de requirements binnen softwareont-wikkeling. Requirements vervullen een brugfunctie tussen enerzijds de business die be-lang heeft bij de te ontwikkelen software en anderzijds de softwareontwikkeling zelf. Dit hoofdstuk sluit af met de kritieke succesfactoren voor softwareontwikkeling.
Hoofdstuk 2 gaat in op de requirements zelf. Requirement is een veelgebruikte term binnen de softwareontwikkeling, maar toch is de betekenis ervan niet altijd duide-lijk. Requirements komen in allerlei soorten en maten voor. Deze diversiteit blijkt in de praktijk tot verwarring en misverstanden te leiden. Dit hoofdstuk laat zien wat requi-rements zijn en wat requirequi-rements niet zijn.
Hoofdstuk 3 belicht het vakgebied Requirements Engineering en de relatie met andere vakgebieden binnen de softwareontwikkeling. Het geeft inzicht in het doel en de inhoud van dit vakgebied aan de hand van de veel gebruikte onderverdeling in Re-quirements Development en ReRe-quirements Management.
Dit deel sluit af met een hoofdstuk over de requirementsanalist. Het beschrijft de verantwoordelijkheid van de requirementsanalist en de kennis en competenties die hij nodig heeft om zijn vak goed te kunnen uitoefenen.
Hoofdstuk 1
Belang van requirements
Requirements spelen een belangrijke rol binnen softwareontwikkeling. Dit hoofdstuk laat zien waarom dat zo is en voor wie de requirements van belang zijn. Er is veel on-derzoek gedaan naar de invloed van requirements op het succes van softwareontwik-keltrajecten. Het effect van foutieve requirements en de kritieke succesfactoren voor softwareontwikkeling komen in dit hoofdstuk aan bod.
De brugfunctie van requirements
Requirements vertellen wat het te ontwikkelen systeem moet kunnen. Ze geven aan wat de eisen en de behoeften aan geautomatiseerde ondersteuning van de belangheb-benden uit de business zijn. Requirements vormen als het ware een brug tussen de be-langhebbenden uit de business en het softwareontwikkelteam. In Figuur 1 is dit sche-matisch weergegeven. Business … om ons optimaal te ondersteunen Business … om ons optimaal te ondersteunen Ontwikkelteam … en wij moe-ten realiseren. Ontwikkelteam … en wij moe-ten realiseren. Requirements
Wat het system moet kunnen …
Requirements
Wat het system moet kunnen …
Requirements
4
Deel I Positionering requirementsHet onderstaande praktijkvoorbeeld laat zien wat er mis kan gaan bij een haperende brug.
Het nieuwe personeels- en salarissysteem is alweer zeven maanden gele-den in gebruik genomen. Na een aantal opstartproblemen functioneert het systeem nu naar behoren. Totdat …
"ICT-afdeling, met Paul."
"Hallo Paul, je spreekt met Theo van personeelszaken. Ik moet je toch nog een keer lastig vallen over het personeels- en salarissysteem. We hebben namelijk een groot probleem. Eén van de medewerksters, Marieke Dombo, heeft haar achternaam veranderd in Klaassen en we kunnen die naams-wijziging niet doorvoeren in het systeem."
Paul: "Oh, dat zou geen probleem moeten zijn. Je bedoelt toch dat Marie-ke getrouwd is met ene meneer Klaassen?"
Theo: "Nee, ze is niet getrouwd. Ze heeft alleen een andere achternaam aangenomen omdat ze niet langer Dombo wilde heten, begrijpelijk toch. Kun je voor het eind van de maand deze fout herstellen?"
Paul, enigszins geïrriteerd: "Het is helemaal geen fout. Er is nooit aange-geven dat het mogelijk moet zijn om zomaar een achternaam te wijzigen." Theo vasthoudend: "Iedereen weet toch dat het wettelijk is toegestaan om een nieuwe achternaam aan te vragen. Als deze fout niet voor het eind van de maand is opgelost, kunnen we het salaris van Marieke niet uitbetalen. De bank accepteert de overmaking dan niet."
Paul geïrriteerd: "Het is geen fout. Je zult een 'change request' moeten in-dienen en dan kunnen we het in de volgende release meenemen. Die kan op z'n vroegst over drie maanden uitkomen.
Theo: "Maar wat moeten we dan met het salaris van Marieke?"
Voor gebruikers is het frustrerend als ze bepaalde taken niet of alleen met tijdrovende workarounds kunnen uitvoeren. In het uiterste geval weigeren de gebruikers het nieu-we systeem te gebruiken of komt de concurrentiepositie van het bedrijf onder druk te staan. Kennen we niet allemaal systemen waarover de gebruikers steen en been klagen omdat het zo onhandig werkt of omdat belangrijke functionaliteit mist?
Verwachtingen Gebruikers Gespecificeerd door analisten Daadwerkelijk gerealiseerd Figuur 2: Schommelkarikatuur
Hoofdstuk 1 Belang van requirements
5
Ook voor ontwikkelaars is het onbevredigend om er pas na de ingebruikname van het systeem achter te komen dat de gebruikers essentiële functionaliteit missen, terwijl ze het systeem wel volgens de gespecificeerde requirements hebben gebouwd.
Uit het voorgaande blijkt dat het bij requirements gaat om het afstemmen van verwachtingen. Dit wordt treffend weergegeven in de alom bekende schommelkarika-tuur in Figuur 2. Deze karikaschommelkarika-tuur maakt pijnlijk duidelijk hoe belangrijk de brugfunctie van requirements is. Het is van groot belang dat de analist de behoeften en verwach-tingen van de gebruikers specificeert en dat de requirements vervolgens goed begrepen worden door de ontwikkelaars.
De belanghebbenden
Voor vrijwel iedereen die betrokken is bij softwareontwikkeling zijn de requirements van belang. Ze zijn van belang voor de opdrachtgever, de opdrachtnemer, de ontwik-kelaars, de testers en de gebruikers van het systeem. Figuur 3 geeft de voornaamste be-langhebbenden bij de requirements weer.
Opdrachtgever
Opdrachtgever OpdrachtnemerOpdrachtnemer
Gebruikers Gebruikers Testers Testers Ontwikkelaars Requirements Figuur 3: De belanghebbenden
Hieronder is aangegeven welk belang de belanghebbenden uit Figuur 3 bij de require-ments hebben.
De opdrachtgever
Voor de opdrachtgever zijn de requirements belangrijk omdat hij het softwareontwik-keltraject niet zonder reden is gestart. Het nieuwe systeem moet hem helpen om be-paalde bedrijfsdoelen te halen of om een probleem op te lossen.
Voorbeelden van requirements van de opdrachtgever:
- de opdrachtgever wil dat de productiviteit van de afdeling orderver-werking met 25% stijgt;
- de opdrachtgever wil een verlaging van de administratiekosten met 20%.
De requirements van de andere belanghebbenden moeten bijdragen aan het behalen van de requirements van de opdrachtgever. Deze requirements geven aan wat het te ontwikkelen systeem moet kunnen om het beoogde bedrijfsdoel te halen.
6
Deel I Positionering requirementsDe opdrachtnemer
Voor de opdrachtnemer zijn requirements belangrijk omdat ze vertellen welk systeem gerealiseerd moet worden. Pas wanneer duidelijk is wat het te ontwikkelen systeem moet kunnen is het mogelijk om de kosten in te schatten, een planning te maken en de juiste medewerkers in te zetten. Hoe meer bekend is over de requirements, hoe be-trouwbaarder de inschattingen zijn.
De ontwikkelaars
Voor ontwikkelaars zijn requirements belangrijk omdat ze vertellen waaraan de te bou-wen software moet voldoen. De requirements vormen de basis van het systeemont-werp en de realisatie. Zonder requirements is het ontwikkelen van een systeem dat vol-doet aan de wensen van de business onmogelijk.
De testers
Voor testers zijn requirements belangrijk omdat ze vertellen waaraan de te testen soft-ware moet voldoen. De requirements zijn de norm waaraan de ontwikkelde softsoft-ware wordt getoetst. Zonder requirements is het onmogelijk om te testen of het systeem voldoet aan de eerder overeengekomen eisen en wensen van de business.
De gebruikers
Voor de toekomstige gebruikers van het systeem zijn de requirements belangrijk. Wat het nieuwe systeem kan - en wat het nieuwe systeem niet kan - beïnvloedt in hoge mate of de gebruiker zijn werk goed en op een prettige manier kan uitvoeren.
Effect van foutieve requirements
Requirements zijn buitengewoon belangrijk. Uit verschillende onderzoeken blijkt dat voor succesvolle softwareontwikkeling de requirements belangrijker zijn dan elk ander aspect. Dit komt omdat ze de basis vormen voor de softwareontwikkel- en projectma-nagementactiviteiten. Opdrachtverstrekking Projectplan Ontwerp Bouw Test Detailplanning Globaal Requirements Gedetailleerd
Figuur 4: Requirements als vertrekpunt
Het zijn immers de requirements waaraan de te ontwikkelen software moet voldoen. Ontwikkelactiviteiten zoals ontwerpen, bouwen en testen nemen daarom de te imple-menteren requirements als vertrekpunt. Ook aan de opdrachtverstrekking en het
Hoofdstuk 1 Belang van requirements
7
jectplan liggen requirements ten grondslag. Dit is schematisch afgebeeld in Figuur 4. Wiegers (2006) verwoordt het belang van requirements als volgt:
Als het niet lukt om de requirements te achterhalen, maakt het ook niet meer uit hoe goed je de overige activiteiten uitvoert.
Uit het voorgaande is te verklaren dat inconsistente, ontbrekende of anderszins foutie-ve requirements doorwerken in vrijwel alle softwareontwikkelactiviteiten. In 60% van de gevallen bevindt de oorsprong van een softwarefout zich in de requirements (Mc-Connell, 2004). Daarom loont het verlagen van het aantal fouten in de requirements zeker de moeite. De kosten om een requirementsfout te herstellen zijn laat in het tra-ject vele malen hoger dan aan het begin van het tratra-ject (Grady, 1999). Davis (1993) heeft de relatieve herstelkosten op een rij gezet. Deze zijn weergegeven in Figuur 5.
200 Onderhoud 50 Acceptatietest 20 Unit test 10 Realisatie 5 Technisch ontwerp 1 - 2 Requirements Relatieve herstelkosten Fase 200 Onderhoud 50 Acceptatietest 20 Unit test 10 Realisatie 5 Technisch ontwerp 1 - 2 Requirements Relatieve herstelkosten Fase
Figuur 5: De relatieve herstelkosten
Uit Figuur 5 is af te lezen dat een fout die tijdens het opstellen van de requirements wordt ontdekt en hersteld vijf tot tien keer minder kost dan dezelfde fout die tijdens de realisatie wordt ontdekt en hersteld. Wanneer die fout pas na de ingebruikname wordt ontdekt bedragen de herstelkosten maar liefst honderd à tweehonderd keer zoveel dan tijdens het opstellen van de requirements.
Op basis van de genoemde en ook andere onderzoeken concluderen Leffingwell & Widrig (2003):
Van het totale budget voor maatwerk softwareontwikkeling gaat 25 tot 40% op aan het herstellen van fouten in de requirements.
Onderzoeken bevestigen keer op keer dat het grootste deel van de problemen waarmee softwareontwikkeltrajecten kampen te maken hebben met de requirements. In Figuur 6 is een aantal van die onderzoeksresultaten verzameld.
De problemen die softwareontwikkelprojecten ondervinden met requirements blijken hoofdzakelijk betrekking te hebben op de kwaliteit van de specificaties van de requirements, op wijzigingen in de requirements en op gebrek aan gebruikersinbreng.
8
Deel I Positionering requirementsStandish Group CHAOS Report (2009)
De drie meest genoemde redenen waarom projecten niet succesvol waren: 19% Gebrek aan gebruikersinbreng
16% Commitment van het hoger management 15% Onduidelijke specificaties van de requirements
Forrester (2006)
Bij 71% van de softwareprojecten die falen ligt de oorzaak bij de requirements. De meest voorkomende problemen met de requirements zijn:
- Onvolledige of onnauwkeurige specificaties - Slecht beheren van de wijzigngen in de requirements - Ontbrekende requirements
Rodrigues (2001)
Top 3 van de risico's die het succes van een e-project bedreigen: 66% Niet stabiele, continue wijzigende requirements 55% Slechte specificatie van de requirements
42% Gedrag van de klant zoals vertraagde besluitvorming, veranderende requirements en slechte communicatie.
Jones (2000)
Requirementsfouten zijn de meest voorkomende fouten en bedragen ongeveer eenderde van het totaal aantal fouten in een project.
Standish Group CHAOS Report (1994)
De drie meest genoemde redenen waarom projecten niet succesvol waren: 12,8% Gebrek aan gebruikersinbreng
12,3% Onvolledige requirements en specificaties 11,8% Veranderende requirements en specificaties
Standish Group CHAOS Report (2009)
De drie meest genoemde redenen waarom projecten niet succesvol waren: 19% Gebrek aan gebruikersinbreng
16% Commitment van het hoger management 15% Onduidelijke specificaties van de requirements
Forrester (2006)
Bij 71% van de softwareprojecten die falen ligt de oorzaak bij de requirements. De meest voorkomende problemen met de requirements zijn:
- Onvolledige of onnauwkeurige specificaties - Slecht beheren van de wijzigngen in de requirements - Ontbrekende requirements
Rodrigues (2001)
Top 3 van de risico's die het succes van een e-project bedreigen: 66% Niet stabiele, continue wijzigende requirements 55% Slechte specificatie van de requirements
42% Gedrag van de klant zoals vertraagde besluitvorming, veranderende requirements en slechte communicatie.
Jones (2000)
Requirementsfouten zijn de meest voorkomende fouten en bedragen ongeveer eenderde van het totaal aantal fouten in een project.
Standish Group CHAOS Report (1994)
De drie meest genoemde redenen waarom projecten niet succesvol waren: 12,8% Gebrek aan gebruikersinbreng
12,3% Onvolledige requirements en specificaties 11,8% Veranderende requirements en specificaties
Figuur 6: Onderzoeken naar problemen waarmee projecten kampen
Kritieke succesfactoren
De problemen waarmee softwareontwikkelprojecten kampen zijn te vertalen naar kri-tieke succesfactoren. Deze krikri-tieke succesfactoren voor softwareontwikkeling zijn:
kwalitatief goede requirementsspecificaties; managen van wijzigingen in de requirements; voldoende gebruikersinbreng.
Hierna volgt een toelichting op deze kritieke succesfactoren. Bij iedere succesfactor is aangegeven in welk hoofdstuk het onderwerp uitgebreider aan bod komt.
Kwalitatief goede requirementsspecificaties
Een goede kwaliteit van de specificaties van de requirements blijkt cruciaal te zijn voor het succes van een softwareontwikkeltraject. Het gaat dan voornamelijk om kwaliteits-criteria zoals volledigheid, consistentie, eenduidigheid en validiteit.
Volledigheid
Specificaties die volledig zijn bevatten alle requirements waaraan het systeem moet vol-doen. Er ontbreken dus geen requirements. Het is helaas niet mogelijk om met zeker-heid vast te stellen dat er geen requirements ontbreken. Een ander aspect van volledig-heid is dat de specificatie van een requirement alle benodigde (detail)informatie bevat. De specificatie is volledig als de ontwikkelaars en de testers genoeg informatie hebben om het systeem te realiseren en testen.
Hoofdstuk 1 Belang van requirements
9
Consistentie
De specificaties zijn consistent als er geen conflicterende requirements in staan. Requi-rements conflicteren bijvoorbeeld als bepaalde belanghebbenden een verschil van me-ning hebben over de eisen die zij aan het systeem stellen. Wanneer zo'n verschil van mening onopgemerkt blijft, komen er conflicterende requirements in de specificaties terecht. Voor het verkrijgen van consistente specificaties is een zorgvuldige formule-ring van de requirements belangrijk. Zeker bij gedetailleerde specificaties kunnen er gemakkelijk inconsistenties insluipen.
Eenduidigheid
Eenduidige specificaties zijn specificaties die maar voor één uitleg vatbaar zijn. De re-quirements worden dan door alle belanghebbenden op dezelfde manier geïnterpre-teerd. Omdat de requirements met het oog op de leesbaarheid in een natuurlijke taal worden geschreven, is 100% eenduidigheid niet te bereiken. Dat is nu eenmaal inhe-rent aan een natuurlijke taal.
Validiteit
Requirements zijn valide als ieder requirement bijdraagt aan het beoogde bedrijfsdoel. Er hoeft dan geen tijd en energie gestoken te worden in overbodige functionaliteit. Uit onderzoek blijkt dat gemiddeld 45% van de ontwikkelde functionaliteit van een sys-teem nooit gebruikt wordt (The Standish Group, 2003).
Het is niet eenvoudig om kwalitatief goede requirementsspecificaties op te stellen. Hoofdstuk 15 Specificatietechnieken geeft praktische tips hiervoor.
Managen van wijzigingen in de requirements
Dat requirements tussentijds wijzigen is logisch en onvermijdelijk. Aan de waterval-aanpak ligt de veronderstelling ten grondslag dat eenmaal onderkende requirements voor de rest van het traject bevroren kunnen worden. Dit idee is inmiddels achter-haald. De business en de gewenste ondersteuning daarvan door het systeem staan niet stil tijdens de looptijd van het softwareontwikkeltraject. Daarnaast is het optreden van voortschrijdend inzicht bij de betrokken gebruikers een normaal verschijnsel. Het ma-nagen van de wijzigende requirements voorkomt het zo gevreesde verschijnsel scope creep waarbij de omvang van de te ontwikkelen software ongemerkt of ongecontro-leerd blijft toenemen. Hiervoor moet het ontwikkelteam inzicht hebben in de wijzigin-gen, de actuele versie en de status van de requirements. Meer informatie hierover is te vinden in Hoofdstuk 12 Requirements Management.
Voldoende gebruikersinbreng
Zoals gezegd vormen de requirements een brug tussen de business en de ICT. De ge-bruikers en andere belanghebbenden moeten aangeven wat het systeem moet kunnen om de bedrijfsvoering goed te ondersteunen. Dit geldt voor alle requirements op zowel hoog als laag detailniveau. Intensieve samenwerking tussen de gebruikersorganisatie en het ontwikkelteam is nodig om de requirements scherp te krijgen en te houden.
10
Deel I Positionering requirementsEen ontwikkelteam kan alleen rekenen op voldoende gebruikersinbreng gedurende het gehele traject als zowel de opdrachtgever als het team zelf nut en noodzaak daarvan in-zien. Aan de ene kant moet de business tijd vrijmaken voor enkele gebruikers om te participeren in het softwareontwikkeltraject. Hierdoor kunnen zij minder of geen tijd besteden aan hun dagelijkse werkzaamheden. Aan de andere kant mogen ontwikkel-teams niet vergeten dat ze continu moeten blijven afstemmen met de gebruikers. Hoe-wel dat soms lastig en tijdrovend kan zijn is het de enige manier om een systeem te ontwikkelen dat aan de behoeften van zijn gebruikers voldoet. Deel III Requirements-proces en Hoofdstuk 18 Gesprekspartners aan hier nader op in.
Onderschatting vakgebied
Gezien het feit dat zoveel softwareontwikkeltrajecten kampen met problemen op het terrein van de requirements is er veel te verbeteren. Is het requirementsvakgebied nog zo onvolwassen dat het ontbreekt aan afdoende methoden, technieken, tools en best practices of wordt het belang van kwalitatief goede requirements onderschat?
Op internet is een groot aanbod aan vakliteratuur op het gebied van requirements te vinden. Uiteenlopende methoden, technieken, tools en best practices komen daarin uitvoerig aan bod. De problemen die projecten in de praktijk ondervinden zijn niet te verklaren met een gebrek aan theoretische handvatten en best practices. Tenzij de vak-literatuur de plank volledig mis slaat door in de praktijk niet toepasbare handvatten aan te bieden.
Een onderschatting van het requirementsvak is een meer voor de hand liggende verklaring van de huidige problemen. Onderschatting van het vakgebied leidt ertoe dat in de meeste trajecten te weinig tijd en aandacht wordt besteed aan het specificeren en managen van de requirements. Ook komt het voor dat het werk wordt overgelaten aan onvoldoende gekwalificeerde medewerkers. Niet alleen het belang van de requirements voor het succes van een softwareontwikkeltraject wordt onderschat; onderschatting van de moeilijkheidsgraad om de requirements te achterhalen en te specificeren komt ook veelvuldig voor. In de paragraaf 'Effect van foutieve requirements' kwam het grote aantal fouten en de herstelkosten daarvan al aan bod.
Samenvatting
Kern: Requirements geven aan wat de te ontwikkelen software moet kunnen. Het softwareontwikkelteam moet een systeem opleveren dat aan de requirements van de business voldoet. Uit onderzoeken blijkt dat slechts een klein deel van de software-ontwikkeltrajecten daar succesvol in is. Dit komt niet door technische problemen maar door fouten in de requirements en de hoge herstelkosten daarvan.
Requirements vormen een brug tussen de belanghebbenden uit de business en het softwareontwikkelteam. Voor vrijwel iedereen die bij softwareontwikkeling is betrok-ken zijn de requirements van belang: voor de opdrachtgever, de opdrachtnemer, de gebruikers, de ontwikkelaars en de testers van het systeem.
Hoofdstuk 1 Belang van requirements
11
De belangrijkste succesfactoren voor een softwareontwikkeltraject zijn: kwalitatief goede requirementsspecificaties;
managen van wijzigingen in de requirements; voldoende gebruikersinbreng.
Een verklaring voor het feit dat zoveel projecten kampen met problemen is de onder-schatting van het belang van de requirements voor het succes van een softwareontwik-keltraject en tevens de onderschatting van de moeilijkheidsgraad van het requirements-vak.
Het volgende hoofdstuk gaat in op de verschillende vormen van requirements en de misverstanden die daaromtrent bestaan.
Hoofdstuk 2
Requirements
Requirement is een veelgebruikte term binnen softwareontwikkeling. Toch is de bete-kenis ervan niet altijd duidelijk. Requirements komen in allerlei soorten en maten voor. Deze diversiteit blijkt in de praktijk tot verwarring en misverstanden te leiden. Naast de diverse vormen van requirements worden allerlei andere zaken onder de noemer van requirements geschaard. Dit hoofdstuk beschrijft wat requirements zijn en wat requi-rements niet zijn.
Wat is een requirement?
De anekdote hieronder laat zien hoe over het algemeen op het begrip requirements ge-reageerd wordt.
Tijdens de kick-off van een project voor een internationale hotelketen vraagt de projectleider naar de requirements. Diverse reacties volgen: Hotelmanager: "Het nieuwe systeem moet heel het primaire proces onder-steunen."
Ontwikkelaar: "De belangrijkste requirement is toch dat de klant online een hotelkamer kan reserveren. Laten we ons daar eerst op concentreren." Receptioniste: "Als klanten de informatie maar in hun moedertaal kunnen lezen."
Technisch beheerder: "Het systeem moet in Java gebouwd worden anders kunnen we het niet in beheer nemen."
Directeur: "Vergeet niet dat het systeem absoluut eind volgend jaar opera-tioneel moet zijn."
Hotelmanager: "Ik heb positieve geluiden gehoord over de nieuwe agile-werkwijze bij ICT- projecten. Dat moeten we ook gaan doen want dan
14
Deel I Positionering requirementskunnen we tussentijds bijsturen als de opgeleverde software niet aan onze verwachtingen voldoet."
Requirementsanalist:"Laten we beginnen met de reden waarom het nieuwe systeem er moet komen, namelijk dat de bezettingsgraad van de hotelka-mers met 10% moet stijgen. De requirements moeten daaraan bijdragen."
Een vraag naar de requirements roept uiteenlopende reacties op. Sommige medewer-kers hanteren een hoog abstractieniveau en anderen noemen concrete zaken. Soms is het iets dat het systeem moet kunnen en soms is het een eis aan het project.
Deze paragraaf legt uit wat een requirement is en laat verschillende verschijnings-vormen zien.
Requirement als behoefte of als eis
De letterlijke betekenis van de term requirement is a) behoefte of b) eis. a) Een requirement is een behoefte aan geautomatiseerde ondersteuning. Het kan zijn:
Een behoefte van een belanghebbende uit de business om een nieuw of bestaand proces (of subproces, taak, activiteit) geautomatiseerd te ondersteunen.
Een behoefte van een belanghebbende uit de business om verbeteringen in een proces te realiseren met behulp van automatisering.
Voorbeelden van requirements als behoefte.
- De inkoper wil laten controleren of de voorraad het minimum bestel-niveau heeft bereikt (proces).
- De inkoper wil de prijs van een product opzoeken (proces).
- De systeembeheerder wil vastleggen welke medewerkers toegang tot het systeem mogen krijgen (proces).
- De manager wil de volledige orderverwerking geautomatiseerd laten ondersteunen (proces).
- De opdrachtgever wil dat de productiviteit op de afdeling orderaf-handeling met 20% stijgt (procesverbetering).
- De opdrachtgever wil de eentonige werkzaamheden bij de orderaf-handeling verminderen (procesverbetering).
- De klant (van het alarmsysteem) wil potentiële inbrekers afschrikken (procesverbetering).
b) Een requirement is een eis die gesteld wordt aan het systeem.
De eis geeft aan wat het gedrag of de kwaliteit van het systeem moet zijn. Een belang-hebbende uit de business stelt deze eis aan het systeem. De belangbelang-hebbende wil daar een bepaald doel mee bereiken, zodat hij een probleem oplost of een voordeel behaalt. Deze eisen komen dus voort uit een behoefte van een belanghebbende.
Voorbeelden van requirements als eis.
- Het systeem moet de orderafhandeling volledig ondersteunen (ge-drag).
- Het systeem moet tegelijkertijd door tienduizend wereldwijd versprei-de meversprei-dewerkers gebruikt kunnen worversprei-den (kwaliteit).
Hoofdstuk 2 Requirements
15
- Het systeem moet door alle medewerkers na een cursus van maximaal één dag zelfstandig gebruikt kunnen worden (kwaliteit).
- Het systeem moet controleren of de voorraad het minimum bestelni-veau heeft bereikt (gedrag).
- Het systeem moet continu actuele statusinformatie verschaffen (ge-drag).
- Het systeem moet informatie verschaffen over de prijs van het aange-geven product (gedrag).
- Het systeem moet vastleggen welke medewerkers toegang tot het sys-teem mogen krijgen (gedrag).
Uit de voorbeelden blijkt dat sommige requirements als behoefte en tevens als eis ge-zien kunnen worden. Dit geldt alleen voor de requirements die over het 'wat' gaan zo-als in Figuur 7: Betekenis van requirement is weergegeven.
Kwaliteitskenmerk van het systeem
Hoe goed
Gedrag van het systeem
Eis aan het systeem
Verbetering in een proces Proces of activiteit Behoefte aan geautomatiseerde ondersteuning Waarom Wat
Kwaliteitskenmerk van het systeem
Hoe goed
Gedrag van het systeem
Eis aan het systeem
Verbetering in een proces Proces of activiteit Behoefte aan geautomatiseerde ondersteuning Waarom Wat
Figuur 7: Betekenis van requirement
Het gaat bij deze requirements immers om acties die met behulp van het systeem uit-gevoerd moeten worden. Het is mogelijk om deze via het proces of via het systeem te benaderen.
Voorbeelden van requirements als eis en tevens als behoefte.
- De inkoper wil de prijs van een product opzoeken (behoefte).
- Het systeem moet informatie over de prijs van het product verschaffen (eis).
- De systeembeheerder wil vastleggen welke medewerkers toegang tot het systeem krijgen (behoefte).
- Het systeem moet opslaan welke medewerkers toegang tot het systeem krijgen (eis).
Definitie
Er bestaan meerdere definities van de term requirement. De bekendste en meest geci-teerde definitie komt van de IEEE (1990) en luidt als volgt:
16
Deel I Positionering requirementsA requirement is:
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
3. A documented representation of a condition or capability as in 1 or 2. Het eerste en tweede deel van de IEEE-definitie vat dit boek samen in 'gedrag (functi-onaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte te voorzien van een belanghebbende uit de business'. Hierbij is condition or capability niet letterlijk ver-taald maar concreter geformuleerd als gedrag of kwaliteit. Het oplossen van een pro-bleem of het bereiken van een doel en het voldoen aan een formeel document, is ge-combineerd in: het voorzien in een behoefte. Gebruikers is vervangen door belang-hebbenden omdat bijvoorbeeld ook de opdrachtgever, lijnmanagers en stafafdelingen requirements kunnen hebben.
Uit de definitie van IEEE is niet af te leiden of a condition or capability needed by a user bij onderdeel 1 betrekking heeft op een eigenschap van het systeem of juist niet. Bij onderdeel 2 is dat wel duidelijk aangegeven. De definitie in dit boek geeft expliciet aan dat naast een eigenschap van het systeem een requirement ook betrekking kan hebben op een proces of een verbetering daarin.
Om duidelijkheid te scheppen is het derde onderdeel van de definitie van IEEE niet overgenomen. In dit boek wordt de gedocumenteerde representatie aangeduid als gespecificeerde requirement of requirementsspecificatie, zodat het onderscheid duide-lijk is.
Dit boek hanteert de volgende definitie van een requirement. Een requirement is:
a. een behoefte aan geautomatiseerde ondersteuning: een proces of een verbetering daarin, die een belanghebbende uit de business (deels) met behulp van het systeem wil uitvoeren;
b. een eis aan een systeem: gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte te voorzien van een belanghebbende uit de business.
Functionele en niet-functionele requirements
Misschien wel de oudste en meest gebruikte wijze om requirements onder te verdelen is het onderscheid in functionele en niet-functionele requirements. Een functionele re-quirement geeft het gewenste gedrag van het systeem weer. Een niet-functionele requi-rement is een kwaliteitseis waaraan het systeem moet voldoen. Denk bijvoorbeeld aan hoe snel, hoe gemakkelijk bruikbaar, hoe veilig, hoe foutgevoelig en hoe lang beschik-baar het systeem moet zijn.
Bedankt voor het bekijken van deze preview!
Bestel het boek Bestel het ebook
