Handboek Requirements Deel 1

Handboek Requirements

Handboek Requirements Brug tussen business en ICT

Nicole de Swart

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 [email protected] / 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 verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen, of op enig andere manier, zonder voorafgaande schriftelijke toestemming van de rechthebbende.

Inhoud

Voorwoord Dankwoord Inleiding

ix xi xiii

Deel I Positionering requirements Hoofdstuk 1 Belang van requirements De brugfunctie van requirements De belanghebbenden Effect van foutieve requirements Kritieke succesfactoren Onderschatting vakgebied Samenvatting Hoofdstuk 2 Requirements Wat is een requirement? Wat is een requirement niet? Samenvatting Hoofdstuk 3 Requirements Engineering Softwareontwikkeling Het vakgebied Requirements Engineering Requirements Development Requirements Management Samenvatting Hoofdstuk 4 Requirementsanalist Rol en verantwoordelijkheid Competenties Training Samenvatting

1

Deel II Typen requirements Hoofdstuk 5 Requirementsmodel Introductie Systeemperspectief Businessperspectief

3 3 5 6 8 10 10 13 13 18 22 23 23 25 27 29 30 33 33 35 37 38 41 43 43 44 46

v

Opkomst agile softwareontwikkeling Samenvatting Hoofdstuk 6 Businessrequirements Toegevoegde waarde Scope van het systeem Businessdoelen Businessrequirements in de praktijk Samenvatting Hoofdstuk 7 Gebruikersrequirements Businessperspectief Use cases User stories Samenvatting Hoofdstuk 8 Softwarerequirements Functionele softwarerequirements Niet-functionele softwarerequirements Samenvatting

49 50

Deel III Requirementsproces Hoofdstuk 9 Requirementsproces Generiek requirementsproces Softwareontwikkelproces Subgebieden van Requirements Development Samenvatting Hoofdstuk 10 Requirements Development Processtappen Positioneer het systeem binnen het businessdomein Definieer de gewenste oplossing Detailleer de requirements Samenvatting Hoofdstuk 11 Requirementstechnieken Elicitatietechnieken Analysetechnieken Specificatietechnieken Validatietechnieken Samenvatting Hoofdstuk 12 Requirements Management Belang Beheer de requirements

79

vi

51 51 53 54 56 58 59 59 61 64 65 67 67 70 77

81 81 84 86 89 91 91 92 94 97 99 101 101 104 107 110 112 115 115 116

118 122

Pijlers Samenvatting Deel IV Praktische uitvoering Hoofdstuk 13 Elicitatietechnieken Interviewen Prototype maken Workshops houden Observeren Samenvatting Hoofdstuk 14 Analysetechnieken Conceptueel modelleren Prioriteren Prototype maken Categoriseren Samenvatting Hoofdstuk 15 Specificatietechnieken Formuleren Tekst structureren Requirementspatronen toepassen Samenvatting Hoofdstuk 16 Validatietechnieken Reviewen Inspecteren Doorspreken Samenvatting

123

Deel V Verdieping Hoofdstuk 17 Belanghebbenden Belanghebbenden en requirements Belanghebbenden bij het businessdoel Belanghebbenden bij het systeem Belanghebbenden bij het project Samenvatting Hoofdstuk 18 Gesprekspartners Analyse naar belanghebbenden en gesprekspartners Identificeren van belanghebbenden Zoeken van vertegenwoordigers Maken van samenwerkingsafspraken Vastleggen belanghebbenden en afspraken Samenvatting

169

125 125 131 132 135 136 137 137 143 146 147 147 149 149 155 159 160 161 161 163 166 167

vii

171 171 172 173 175 177 179 179 180 182 183 185 186

Hoofdstuk 19 Requirementsproducten Doel Kwaliteit Requirementsproducten Samenvatting Hoofdstuk 20 Niet-functionele softwarerequirements Onderbelicht Tastbaar maken Samenvatting Hoofdstuk 21 Use cases Voordelen Use case model Use case specificatie Samenvatting Bijlagen Bijlage A Bijlage B Bijlage C Bijlage D Bijlage E Bijlage F Bijlage G

187 187 188 191 194 195 195 198 203 205 205 206 211 216

Bedrijfsregels Typeringen van requirements ISO 9126 Kwaliteitseigenschappen Requirementsprocessen Modelleertechnieken Templates van requirementsproducten Hotelcasus

Begrippenlijst Geraadpleegde literatuur Index

219 221 223 229 231 237 245 251 265 279 283

viii

Voorwoord

Ik heb in de loop der jaren veel requirements voor vele projecten gezien. Ik moet hierbij 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 helaas 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 verduidelijking 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 introductie 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 gebruikers boven tafel kunnen krijgen. En niet te vergeten … hoe om te gaan met veranderende 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 requirements 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' Soest, mei 2010

ix

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 hebben 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 agile-project. De agileprincipes 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 reviewteam. 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. Lennart, bedankt voor je verfrissende ideeën en kritische blik. Verder wil ik bedanken: Peter Smulders, Bettina Logge, Jurriaan Fleijsman en Kitty Pettinga. De hulp die jullie me geboden hebben waardeer ik zeer. Tot slot, maar zeker niet in de laatste plaats, bedank ik Peter Janssen voor zijn geduld en scherpe feedback. Nicole de Swart Maurik, juni 2010

xi

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 grotendeels 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 vaardigheden 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 ervan in de praktijk. Dit handboek introduceert daarom geen nieuwe theorieën, maar plaatst de bestaande methoden en technieken in perspectief en geeft praktische handvatten 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 vakgebied en is bovenal toepasbaar in de praktijk. De opbouw van het boek maakt het mogelijk 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 Requirements 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 handvatten voor het uitvoeren van het requirementsproces. Het vijfde en laatste deel brengt verdieping aan in belangrijke onderwerpen als belanghebbenden, niet-functionele requirements en use cases. Tenzij uitdrukkelijk anders vermeld wordt in dit boek met 'systeem' een 'geautomatiseerd systeem' bedoeld. Omwille van de leesbaarheid spreekt dit boek over 'hij'. Hiervoor mag vanzelfsprekend ook 'zij' gelezen worden.

xiii

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 softwareontwikkeling. Requirements vervullen een brugfunctie tussen enerzijds de business die belang 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 duidelijk. 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 requirements zijn en wat requirements 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 Requirements Development en Requirements 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 onderzoek gedaan naar de invloed van requirements op het succes van softwareontwikkeltrajecten. 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 belanghebbenden uit de business zijn. Requirements vormen als het ware een brug tussen de belanghebbenden uit de business en het softwareontwikkelteam. In Figuur 1 is dit schematisch weergegeven. Requirements Wat het system moet kunnen …

Business

Ontwikkelteam

… om ons optimaal te ondersteunen

… en wij moeten realiseren.

Figuur 1: Requirements als brug

4

Deel I Positionering requirements

Het onderstaande praktijkvoorbeeld laat zien wat er mis kan gaan bij een haperende brug. Het nieuwe personeels- en salarissysteem is alweer zeven maanden geleden 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 naamswijziging niet doorvoeren in het systeem." Paul: "Oh, dat zou geen probleem moeten zijn. Je bedoelt toch dat Marieke 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 aangegeven 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 indienen 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 nieuwe 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

Figuur 2: Schommelkarikatuur

Daadwerkelijk gerealiseerd

Hoofdstuk 1 Belang van requirements

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 schommelkarikatuur in Figuur 2. Deze karikatuur maakt pijnlijk duidelijk hoe belangrijk de brugfunctie van requirements is. Het is van groot belang dat de analist de behoeften en verwachtingen 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 ontwikkelaars, de testers en de gebruikers van het systeem. Figuur 3 geeft de voornaamste belanghebbenden bij de requirements weer.

Opdrachtgever

Opdrachtnemer

Requirements Gebruikers

Ontwikkelaars

Testers

Figuur 3: De belanghebbenden

Hieronder is aangegeven welk belang de belanghebbenden uit Figuur 3 bij de requirements hebben. De opdrachtgever

Voor de opdrachtgever zijn de requirements belangrijk omdat hij het softwareontwikkeltraject niet zonder reden is gestart. Het nieuwe systeem moet hem helpen om bepaalde 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 orderverwerking 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.

5

6

Deel I Positionering requirements

De 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 betrouwbaarder de inschattingen zijn. De ontwikkelaars

Voor ontwikkelaars zijn requirements belangrijk omdat ze vertellen waaraan de te bouwen software moet voldoen. De requirements vormen de basis van het systeemontwerp en de realisatie. Zonder requirements is het ontwikkelen van een systeem dat voldoet aan de wensen van de business onmogelijk. De testers

Voor testers zijn requirements belangrijk omdat ze vertellen waaraan de te testen software moet voldoen. De requirements zijn de norm waaraan de ontwikkelde software 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 projectmanagementactiviteiten.

Opdrachtverstrekking

Globaal

Projectplan Requirements

Detailplanning Ontwerp

Gedetailleerd

Bouw Test

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 implementeren requirements als vertrekpunt. Ook aan de opdrachtverstrekking en het pro-

Hoofdstuk 1 Belang van requirements

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 foutieve requirements doorwerken in vrijwel alle softwareontwikkelactiviteiten. In 60% van de gevallen bevindt de oorsprong van een softwarefout zich in de requirements (McConnell, 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 traject vele malen hoger dan aan het begin van het traject (Grady, 1999). Davis (1993) heeft de relatieve herstelkosten op een rij gezet. Deze zijn weergegeven in Figuur 5. Fase Requirements

Relatieve herstelkosten 1-2

Technisch ontwerp

5

Realisatie

10

Unit test

20

Acceptatietest

50

Onderhoud

200

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.

7

8

Deel I Positionering requirements 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 Jones (2000) Requirementsfouten zijn de meest voorkomende fouten en bedragen ongeveer eenderde van het totaal aantal fouten in een project. 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. 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 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

Figuur 6: Onderzoeken naar problemen waarmee projecten kampen

Kritieke succesfactoren De problemen waarmee softwareontwikkelprojecten kampen zijn te vertalen naar kritieke succesfactoren. Deze kritieke 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 kwaliteitscriteria zoals volledigheid, consistentie, eenduidigheid en validiteit. Volledigheid

Specificaties die volledig zijn bevatten alle requirements waaraan het systeem moet voldoen. Er ontbreken dus geen requirements. Het is helaas niet mogelijk om met zekerheid vast te stellen dat er geen requirements ontbreken. Een ander aspect van volledigheid 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

Consistentie

De specificaties zijn consistent als er geen conflicterende requirements in staan. Requirements conflicteren bijvoorbeeld als bepaalde belanghebbenden een verschil van mening 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 formulering 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 requirements worden dan door alle belanghebbenden op dezelfde manier geïnterpreteerd. 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 inherent 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 systeem 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 watervalaanpak ligt de veronderstelling ten grondslag dat eenmaal onderkende requirements voor de rest van het traject bevroren kunnen worden. Dit idee is inmiddels achterhaald. 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 managen van de wijzigende requirements voorkomt het zo gevreesde verschijnsel scope creep waarbij de omvang van de te ontwikkelen software ongemerkt of ongecontroleerd blijft toenemen. Hiervoor moet het ontwikkelteam inzicht hebben in de wijzigingen, 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 gebruikers 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.

9

10

Deel I Positionering requirements

Een ontwikkelteam kan alleen rekenen op voldoende gebruikersinbreng gedurende het gehele traject als zowel de opdrachtgever als het team zelf nut en noodzaak daarvan inzien. 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 ontwikkelteams niet vergeten dat ze continu moeten blijven afstemmen met de gebruikers. Hoewel 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 Requirementsproces 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 vakliteratuur 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 softwareontwikkeltrajecten 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 betrokken 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

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 onderschatting van het belang van de requirements voor het succes van een softwareontwikkeltraject en tevens de onderschatting van de moeilijkheidsgraad van het requirementsvak. Het volgende hoofdstuk gaat in op de verschillende vormen van requirements en de misverstanden die daaromtrent bestaan.

11

Hoofdstuk 2

Requirements

Requirement is een veelgebruikte term binnen softwareontwikkeling. Toch is de betekenis 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 requirements niet zijn.

Wat is een requirement? De anekdote hieronder laat zien hoe over het algemeen op het begrip requirements gereageerd 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 ondersteunen." 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 operationeel moet zijn." Hotelmanager: "Ik heb positieve geluiden gehoord over de nieuwe agilewerkwijze bij ICT- projecten. Dat moeten we ook gaan doen want dan

14

Deel I Positionering requirements

kunnen 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 hotelkamers met 10% moet stijgen. De requirements moeten daaraan bijdragen."

Een vraag naar de requirements roept uiteenlopende reacties op. Sommige medewerkers 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 verschijningsvormen 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 bestelniveau 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 orderafhandeling met 20% stijgt (procesverbetering). - De opdrachtgever wil de eentonige werkzaamheden bij de orderafhandeling 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 belanghebbende uit de business stelt deze eis aan het systeem. De belanghebbende 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 (gedrag). - Het systeem moet tegelijkertijd door tienduizend wereldwijd verspreide medewerkers gebruikt kunnen worden (kwaliteit).

Hoofdstuk 2 Requirements

-

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 bestelniveau heeft bereikt (gedrag). Het systeem moet continu actuele statusinformatie verschaffen (gedrag). Het systeem moet informatie verschaffen over de prijs van het aangegeven product (gedrag). Het systeem moet vastleggen welke medewerkers toegang tot het systeem mogen krijgen (gedrag).

Uit de voorbeelden blijkt dat sommige requirements als behoefte en tevens als eis gezien kunnen worden. Dit geldt alleen voor de requirements die over het 'wat' gaan zoals in Figuur 7: Betekenis van requirement is weergegeven. Wat Behoefte aan geautomatiseerde ondersteuning

Proces of activiteit

Eis aan het systeem

Gedrag van het systeem

Hoe goed

Waarom

Verbetering in een proces

Kwaliteitskenmerk van het systeem

Figuur 7: Betekenis van requirement

Het gaat bij deze requirements immers om acties die met behulp van het systeem uitgevoerd 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 geciteerde definitie komt van de IEEE (1990) en luidt als volgt:

15

16

Deel I Positionering requirements

A 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 (functionaliteit) 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 vertaald maar concreter geformuleerd als gedrag of kwaliteit. Het oplossen van een probleem of het bereiken van een doel en het voldoen aan een formeel document, is gecombineerd in: het voorzien in een behoefte. Gebruikers is vervangen door belanghebbenden 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 duidelijk 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 requirement geeft het gewenste gedrag van het systeem weer. Een niet-functionele requirement is een kwaliteitseis waaraan het systeem moet voldoen. Denk bijvoorbeeld aan hoe snel, hoe gemakkelijk bruikbaar, hoe veilig, hoe foutgevoelig en hoe lang beschikbaar het systeem moet zijn.

Bedankt voor het bekijken van deze preview! Bestel het boek Bestel het ebook