Handboek Requirements

Handboek Requirements Brug tussen business en ICT Nicole de Swart .

opnamen. . mechanisch. zonder voorafgaande schriftelijke toestemming van de rechthebbende.ISBN 978 90 5972 406 8 (paperback) ISBN 978 90 5972 407 5 (ebook) Eburon Business Postbus 2867 2601 CW Delft tel. c/o Pictoright Amsterdam 2010. of openbaar gemaakt. Alle rechten voorbehouden. © 2010 Nicole de Swart. in enige vorm of op enige wijze. door fotokopieën.nl Omslagontwerp: Textcetera Afbeelding omslag: © UN Studio. Niets uit deze uitgave mag worden verveelvoudigd. opgeslagen in een geautomatiseerd gegevensbestand. Erasmusbrug. hetzij elektronisch.nl / www.: 015-2131484 / fax: 015-2146888 info@eburon. of op enig andere manier.eburonbusiness.

Inhoud Voorwoord Dankwoord Inleiding 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 Deel II Typen requirements Hoofdstuk 5 Requirementsmodel Introductie Systeemperspectief Businessperspectief ix xi xiii 1 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 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 49 50 51 51 53 54 56 58 59 59 61 64 65 67 67 70 77 79 81 81 84 86 89 91 91 92 94 97 99 101 101 104 107 110 112 115 115 116 vi .

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 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 118 122 123 125 125 131 132 135 136 137 137 143 146 147 147 149 149 155 159 160 161 161 163 166 167 169 171 171 172 173 175 177 179 179 180 182 183 185 186 vii .

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 219 221 223 229 231 237 245 251 265 279 283 Bedrijfsregels Typeringen van requirements ISO 9126 Kwaliteitseigenschappen Requirementsprocessen Modelleertechnieken Templates van requirementsproducten Hotelcasus Begrippenlijst Geraadpleegde literatuur Index viii .

zal de software die je uiteindelijk krijgt dat op zijn best ook zijn.vakgebied. Een kwaliteitsimpuls is hard nodig. Uiteindelijk is het aan uzelf om de keuze te maken welke aspecten op welke wijze het best bij u passen. Het is onmogelijk om. Het is bedoeld om alle facetten van requirements engineering te leren kennen en ermee om te leren gaan. En niet te vergeten … hoe om te gaan met veranderende requirements. Vanuit het software-project is er dan ook vaak de vraag om verduidelijking en betere uitwerking van de requirements. Dit soort requirements is helaas eerder regel dan uitzondering.” Als de wensen en eisen onduidelijk zijn. De auteur geeft met behulp van voorbeelden en tips. De wereld staat immers niet stil terwijl wij de software bouwen. Ik moet hierbij vaak denken aan de bekende uitspraak: “Pas op wat je wenst. Het beschrijft wat er allemaal bij komt kijken.Voorwoord Ik heb in de loop der jaren veel requirements voor vele projecten gezien. Daarmee kan de oplossing niet gevalideerd worden en worden eventuele betere en/of goedkopere oplossingen uitgesloten. gebaseerd op haar eigen uitgebreide ervaring. Het boek dat u voor u heeft is een uitgebreide introductie in het complete requirements. het is niet eenvoudig om te weten wat je wilt en dat ook nog eens helder op te schrijven. inconsistent of incompleet. Dit boek is niet bedoeld als kookboek. Jos Warmer Auteur 'Praktisch UML' Soest. 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. uitgaande van dit soort requirements. Nee. Maar hoe doe je dat? De noodzaak om op een betere manier om te gaan met requirements is evident. mei 2010 ix . Dit boek geeft u een solide basis om de juiste keuzes voor uw eigen situatie te maken. En als de requirements wel goed beschreven zijn.en nadelen van de besproken technieken en werkwijzen. software te bouwen die hieraan voldoet. blijft er de achterliggende vraag: “Is dit werkelijk wat je wilt?” Mensen beschrijven vaak een oplossing maar niet de achterliggende requirements. inzicht in de voor. het zou wel eens uit kunnen komen.

.

Carel Daams. De agileprincipes voor softwareontwikkeling blijken ook in andere typen projecten vruchten af te werpen (voor meer informatie zie www.Reaco. maar het was niet altijd gemakkelijk.nl). Remi-Armand Collaris. Soms leek er geen einde aan te komen. Fijn dat jullie mij die ruimte hebben gegeven. Gelukkig hebben veel mensen me aangemoedigd en gesteund. maar zeker niet in de laatste plaats. Tot slot. Anko Tijman en al die anderen: bedankt daarvoor. Jurriaan Fleijsman en Kitty Pettinga. Van collega's en andere vakgenoten heb ik geregeld belangstellende reacties. Lennart. Erik van Loon. waardering en gevraagde en ongevraagde feedback mogen ontvangen. Nicole de Swart Maurik. Ik heb me er helemaal in vastgebeten. Barbara Wijnen. Lisenka Callenbach. Eef Dekker. bedank ik Peter Janssen voor zijn geduld en scherpe feedback. vrienden en in de eerste plaats mijn man hebben me vooral het laatste halfjaar vele uren moeten missen. bedankt voor je verfrissende ideeën en kritische blik. Chan Kerste. Verder wil ik bedanken: Peter Smulders.Dankwoord Aan dit boek heb ik anderhalf jaar gewerkt. Mijn familie. Dit project bestond uit iteraties van zes dagen. Het schrijven van Handboek Requirements heeft meer tijd en energie gekost dan ik vooraf had ingeschat. Erwin Stelling. Aan het einde van iedere iteratie leverde ik publiceerbare tekst op. Jan Bart Laan. Zonder jullie had dit boek er heel anders uitgezien. Frans van Koppen. Jan Campschroer. Bert Hoefslot en Rik Hendriks: super dat jullie mij iedere iteratie opnieuw van advies en kritisch commentaar wilden voorzien. Ik ben jullie dankbaar. Martin Muller. De mensen om me heen hebben dat gemerkt. Ik was altijd met dit boek bezig en had geen tijd meer voor andere dingen. Dat heb ik met veel plezier gedaan. Rob van Kampen. Dit was me niet gelukt zonder de medewerking van mijn sparringpartner en mijn reviewteam. juni 2010 xi . De hulp die jullie me geboden hebben waardeer ik zeer. Rogier Lommers. Bettina Logge. Ik heb het schrijven van dit boek aangepakt als een agile-project.

.

de afstemming met de gebruikersorganisatie en met de alsmaar wijzigende requirements. Omwille van de leesbaarheid spreekt dit boek over 'hij'. maar in de toepassing ervan in de praktijk. Of het nu ging om een profit of non-profit organisatie. niet-functionele requirements en use cases. Hiervoor mag vanzelfsprekend ook 'zij' gelezen worden. maar plaatst de bestaande methoden en technieken in perspectief en geeft praktische handvatten voor de uitvoering ervan. Van de kern van het vakgebied naar meer diepgang en de praktische toepassing ervan. Tenzij uitdrukkelijk anders vermeld wordt in dit boek met 'systeem' een 'geautomatiseerd systeem' bedoeld. xiii .Inleiding Requirements vervullen binnen de softwareontwikkeling een belangrijke rol. Er waren vaak problemen met de kwaliteit van de specificaties. Deel II gaat uitgebreid in op de diverse typen requirements. Het biedt overzicht. Het boek is opgebouwd uit vijf delen. Bij integrale lezing neemt Handboek requirements de lezer mee door het vakgebeid. Bij het opleiden en coachen van vakgenoten heb ik gezien welke kennis en vaardigheden essentieel zijn voor het opstellen en managen van requirements. De uitdaging zit hem niet in het kiezen van de juiste methoden en technieken. Deel I positioneert het vakgebied Requirements Engineering binnen de softwareontwikkeling en geeft de lezer snel inzicht in de kern van het vakgebied. Dit handboek introduceert daarom geen nieuwe theorieën. geeft inzicht in het vakgebied en is bovenal toepasbaar in de praktijk. Het requirementsproces en alle activiteiten en technieken die daarin een rol spelen zijn in het derde deel opgenomen. De projecten waarin ik gedetacheerd werd bleken grotendeels met dezelfde problemen te kampen. daar zijn de meeste ICT’ers het wel over eens. Deel IV is een aaneenschakeling van praktische handvatten voor het uitvoeren van het requirementsproces. Dezelfde valkuilen en misverstanden kwamen steeds opnieuw te voorschijn. om een groot of een klein project. Het vijfde en laatste deel brengt verdieping aan in belangrijke onderwerpen als belanghebbenden. De opbouw van het boek maakt het mogelijk om snel informatie en praktische tips over een specifiek onderwerp te vinden. Handboek requirements is geschreven voor diegenen die zich willen verdiepen in het vakgebied Requirements Engineering. een intern uitgevoerd of een uitbesteed project. Ik heb veel ICT-projecten zien worstelen met het opstellen van requirements.

.

De andere delen brengen hier meer diepgang in. Hoofdstuk 2 gaat in op de requirements zelf. Dit hoofdstuk laat zien wat requirements zijn en wat requirements niet zijn. Dit deel sluit af met een hoofdstuk over de requirementsanalist. . Deze diversiteit blijkt in de praktijk tot verwarring en misverstanden te leiden. 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. 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. Het beschrijft de verantwoordelijkheid van de requirementsanalist en de kennis en competenties die hij nodig heeft om zijn vak goed te kunnen uitoefenen. Requirement is een veelgebruikte term binnen de softwareontwikkeling. Hoofdstuk 3 belicht het vakgebied Requirements Engineering en de relatie met andere vakgebieden binnen de softwareontwikkeling. Dit hoofdstuk sluit af met de kritieke succesfactoren voor softwareontwikkeling. Degenen die minder bekend zijn met requirements krijgen zo snel inzicht in de kern van het requirementsvakgebied.Deel I Positionering requirements Dit eerste deel laat zien welke positie het vakgebeid requirements inneemt binnen softwareontwikkeling. maar toch is de betekenis ervan niet altijd duidelijk. Requirements komen in allerlei soorten en maten voor. Requirements vervullen een brugfunctie tussen enerzijds de business die belang heeft bij de te ontwikkelen software en anderzijds de softwareontwikkeling zelf.

.

Figuur 1: Requirements als brug . 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.Hoofdstuk 1 Belang van requirements Requirements spelen een belangrijke rol binnen softwareontwikkeling. In Figuur 1 is dit schematisch weergegeven. Requirements vormen als het ware een brug tussen de belanghebbenden uit de business en het softwareontwikkelteam. Er is veel onderzoek gedaan naar de invloed van requirements op het succes van softwareontwikkeltrajecten. Requirements Wat het system moet kunnen … Business … om ons optimaal te ondersteunen Ontwikkelteam … en wij moeten realiseren. Dit hoofdstuk laat zien waarom dat zo is en voor wie de requirements van belang zijn. Het effect van foutieve requirements en de kritieke succesfactoren voor softwareontwikkeling komen in dit hoofdstuk aan bod.

Ik moet je toch nog een keer lastig vallen over het personeels. Je zult een 'change request' moeten indienen en dan kunnen we het in de volgende release meenemen. Je bedoelt toch dat Marieke getrouwd is met ene meneer Klaassen?" Theo: "Nee. Ze heeft alleen een andere achternaam aangenomen omdat ze niet langer Dombo wilde heten." "Hallo Paul. Na een aantal opstartproblemen functioneert het systeem nu naar behoren.en salarissysteem is alweer zeven maanden geleden in gebruik genomen. Totdat … "ICT-afdeling. Marieke Dombo. met Paul.4 Deel I Positionering requirements Het onderstaande praktijkvoorbeeld laat zien wat er mis kan gaan bij een haperende brug. Het nieuwe personeels." Paul geïrriteerd: "Het is geen fout. We hebben namelijk een groot probleem. Die kan op z'n vroegst over drie maanden uitkomen. Als deze fout niet voor het eind van de maand is opgelost. kunnen we het salaris van Marieke niet uitbetalen." Paul: "Oh. Eén van de medewerksters." Theo vasthoudend: "Iedereen weet toch dat het wettelijk is toegestaan om een nieuwe achternaam aan te vragen. 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.en salarissysteem. begrijpelijk toch. enigszins geïrriteerd: "Het is helemaal geen fout. dat zou geen probleem moeten zijn. De bank accepteert de overmaking dan niet. ze is niet getrouwd. In het uiterste geval weigeren de gebruikers het nieuwe systeem te gebruiken of komt de concurrentiepositie van het bedrijf onder druk te staan. Er is nooit aangegeven dat het mogelijk moet zijn om zomaar een achternaam te wijzigen. heeft haar achternaam veranderd in Klaassen en we kunnen die naamswijziging niet doorvoeren in het systeem. 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 . je spreekt met Theo van personeelszaken. Kun je voor het eind van de maand deze fout herstellen?" Paul.

Ze zijn van belang voor de opdrachtgever. . Voorbeelden van requirements van de opdrachtgever: .de opdrachtgever wil dat de productiviteit van de afdeling orderverwerking met 25% stijgt. terwijl ze het systeem wel volgens de gespecificeerde requirements hebben gebouwd. .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. de ontwikkelaars. 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 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. Dit wordt treffend weergegeven in de alom bekende schommelkarikatuur in Figuur 2. Deze karikatuur maakt pijnlijk duidelijk hoe belangrijk de brugfunctie van requirements is. De belanghebbenden Voor vrijwel iedereen die betrokken is bij softwareontwikkeling zijn de requirements van belang. 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 opdrachtnemer. Figuur 3 geeft de voornaamste belanghebbenden bij de requirements weer. De opdrachtgever Voor de opdrachtgever zijn de requirements belangrijk omdat hij het softwareontwikkeltraject niet zonder reden is gestart. de testers en de gebruikers van het systeem. Het nieuwe systeem moet hem helpen om bepaalde bedrijfsdoelen te halen of om een probleem op te lossen. Uit het voorgaande blijkt dat het bij requirements gaat om het afstemmen van verwachtingen.

De gebruikers Voor de toekomstige gebruikers van het systeem zijn de requirements belangrijk. De testers Voor testers zijn requirements belangrijk omdat ze vertellen waaraan de te testen software moet voldoen. Ook aan de opdrachtverstrekking en het pro- .en wat het nieuwe systeem niet kan . De ontwikkelaars Voor ontwikkelaars zijn requirements belangrijk omdat ze vertellen waaraan de te bouwen software moet voldoen. Ontwikkelactiviteiten zoals ontwerpen. De requirements zijn de norm waaraan de ontwikkelde software wordt getoetst. Globaal Opdrachtverstrekking Projectplan Requirements Detailplanning Ontwerp Bouw Test Gedetailleerd Figuur 4: Requirements als vertrekpunt Het zijn immers de requirements waaraan de te ontwikkelen software moet voldoen. Hoe meer bekend is over de requirements. De requirements vormen de basis van het systeemontwerp en de realisatie. Zonder requirements is het onmogelijk om te testen of het systeem voldoet aan de eerder overeengekomen eisen en wensen van de business. Effect van foutieve requirements Requirements zijn buitengewoon belangrijk. Uit verschillende onderzoeken blijkt dat voor succesvolle softwareontwikkeling de requirements belangrijker zijn dan elk ander aspect.en projectmanagementactiviteiten. bouwen en testen nemen daarom de te implementeren requirements als vertrekpunt. Dit komt omdat ze de basis vormen voor de softwareontwikkel. Wat het nieuwe systeem kan . hoe betrouwbaarder de inschattingen zijn.6 Deel I Positionering requirements De opdrachtnemer Voor de opdrachtnemer zijn requirements belangrijk omdat ze vertellen welk systeem gerealiseerd moet worden. een planning te maken en de juiste medewerkers in te zetten.beïnvloedt in hoge mate of de gebruiker zijn werk goed en op een prettige manier kan uitvoeren. Zonder requirements is het ontwikkelen van een systeem dat voldoet aan de wensen van de business onmogelijk. Pas wanneer duidelijk is wat het te ontwikkelen systeem moet kunnen is het mogelijk om de kosten in te schatten.

Deze zijn weergegeven in Figuur 5. Fase Requirements Technisch ontwerp Realisatie Unit test Acceptatietest Onderhoud Relatieve herstelkosten 1-2 5 10 20 50 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. De kosten om een requirementsfout te herstellen zijn laat in het traject vele malen hoger dan aan het begin van het traject (Grady.Hoofdstuk 1 Belang van requirements 7 jectplan liggen requirements ten grondslag. op wijzigingen in de requirements en op gebrek aan gebruikersinbreng. In Figuur 6 is een aantal van die onderzoeksresultaten verzameld. . Davis (1993) heeft de relatieve herstelkosten op een rij gezet. maakt het ook niet meer uit hoe goed je de overige activiteiten uitvoert. Wiegers (2006) verwoordt het belang van requirements als volgt: Als het niet lukt om de requirements te achterhalen. 2004). 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. Uit het voorgaande is te verklaren dat inconsistente. Dit is schematisch afgebeeld in Figuur 4. 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. 1999). Onderzoeken bevestigen keer op keer dat het grootste deel van de problemen waarmee softwareontwikkeltrajecten kampen te maken hebben met de requirements. Daarom loont het verlagen van het aantal fouten in de requirements zeker de moeite. In 60% van de gevallen bevindt de oorsprong van een softwarefout zich in de requirements (McConnell. ontbrekende of anderszins foutieve requirements doorwerken in vrijwel alle softwareontwikkelactiviteiten. De problemen die softwareontwikkelprojecten ondervinden met requirements blijken hoofdzakelijk betrekking te hebben op de kwaliteit van de specificaties van de requirements.

Deze kritieke succesfactoren voor softwareontwikkeling zijn: kwalitatief goede requirementsspecificaties. Forrester (2006) Bij 71% van de softwareprojecten die falen ligt de oorzaak bij de requirements.Onvolledige of onnauwkeurige specificaties . Bij iedere succesfactor is aangegeven in welk hoofdstuk het onderwerp uitgebreider aan bod komt. Hierna volgt een toelichting op deze kritieke succesfactoren.Slecht beheren van de wijzigngen in de requirements . continue wijzigende requirements 55% Slechte specificatie van de requirements 42% Gedrag van de klant zoals vertraagde besluitvorming.8 Deel I Positionering requirements Standish Group CHAOS Report (1994) De drie meest genoemde redenen waarom projecten niet succesvol waren: 12. Volledigheid Specificaties die volledig zijn bevatten alle requirements waaraan het systeem moet voldoen.3% Onvolledige requirements en specificaties 11. Een ander aspect van volledigheid is dat de specificatie van een requirement alle benodigde (detail)informatie bevat. managen van wijzigingen 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.8% Gebrek aan gebruikersinbreng 12. consistentie. De meest voorkomende problemen met de requirements zijn: . Het gaat dan voornamelijk om kwaliteitscriteria zoals volledigheid. Het is helaas niet mogelijk om met zekerheid vast te stellen dat er geen requirements ontbreken.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. De specificatie is volledig als de ontwikkelaars en de testers genoeg informatie hebben om het systeem te realiseren en testen. eenduidigheid en validiteit. Er ontbreken dus geen requirements. . Kwalitatief goede requirementsspecificaties Een goede kwaliteit van de specificaties van de requirements blijkt cruciaal te zijn voor het succes van een softwareontwikkeltraject. voldoende gebruikersinbreng. veranderende requirements en slechte communicatie.

de actuele versie en de status van de requirements. komen er conflicterende requirements in de specificaties terecht. De gebruikers en andere belanghebbenden moeten aangeven wat het systeem moet kunnen om de bedrijfsvoering goed te ondersteunen. Intensieve samenwerking tussen de gebruikersorganisatie en het ontwikkelteam is nodig om de requirements scherp te krijgen en te houden. Eenduidigheid Eenduidige specificaties zijn specificaties die maar voor één uitleg vatbaar zijn. Requirements conflicteren bijvoorbeeld als bepaalde belanghebbenden een verschil van mening hebben over de eisen die zij aan het systeem stellen. .Hoofdstuk 1 Belang van requirements 9 Consistentie De specificaties zijn consistent als er geen conflicterende requirements in staan. Managen van wijzigingen in de requirements Dat requirements tussentijds wijzigen is logisch en onvermijdelijk. Hoofdstuk 15 Specificatietechnieken geeft praktische tips hiervoor. Dit idee is inmiddels achterhaald. Omdat de requirements met het oog op de leesbaarheid in een natuurlijke taal worden geschreven. Dat is nu eenmaal inherent aan een natuurlijke taal. Validiteit Requirements zijn valide als ieder requirement bijdraagt aan het beoogde bedrijfsdoel. Zeker bij gedetailleerde specificaties kunnen er gemakkelijk inconsistenties insluipen. Meer informatie hierover is te vinden in Hoofdstuk 12 Requirements Management. Voor het verkrijgen van consistente specificaties is een zorgvuldige formulering van de requirements belangrijk. De requirements worden dan door alle belanghebbenden op dezelfde manier geïnterpreteerd. Hiervoor moet het ontwikkelteam inzicht hebben in de wijzigingen. is 100% eenduidigheid niet te bereiken. Voldoende gebruikersinbreng Zoals gezegd vormen de requirements een brug tussen de business en de ICT. Aan de watervalaanpak ligt de veronderstelling ten grondslag dat eenmaal onderkende requirements voor de rest van het traject bevroren kunnen worden. Dit geldt voor alle requirements op zowel hoog als laag detailniveau. De business en de gewenste ondersteuning daarvan door het systeem staan niet stil tijdens de looptijd van het softwareontwikkeltraject. Uit onderzoek blijkt dat gemiddeld 45% van de ontwikkelde functionaliteit van een systeem nooit gebruikt wordt (The Standish Group. 2003). Daarnaast is het optreden van voortschrijdend inzicht bij de betrokken gebruikers een normaal verschijnsel. Wanneer zo'n verschil van mening onopgemerkt blijft. Het is niet eenvoudig om kwalitatief goede requirementsspecificaties op te stellen. 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. Er hoeft dan geen tijd en energie gestoken te worden in overbodige functionaliteit.

tools en best practices komen daarin uitvoerig aan bod. Aan de andere kant mogen ontwikkelteams niet vergeten dat ze continu moeten blijven afstemmen met de gebruikers. Het softwareontwikkelteam moet een systeem opleveren dat aan de requirements van de business voldoet. Samenvatting Kern: Requirements geven aan wat de te ontwikkelen software moet kunnen. In de paragraaf 'Effect van foutieve requirements' kwam het grote aantal fouten en de herstelkosten daarvan al aan bod. 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. onderschatting van de moeilijkheidsgraad om de requirements te achterhalen en te specificeren komt ook veelvuldig voor. Dit komt niet door technische problemen maar door fouten in de requirements en de hoge herstelkosten daarvan. 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. Is het requirementsvakgebied nog zo onvolwassen dat het ontbreekt aan afdoende methoden. . Voor vrijwel iedereen die bij softwareontwikkeling is betrokken zijn de requirements van belang: voor de opdrachtgever. Niet alleen het belang van de requirements voor het succes van een softwareontwikkeltraject wordt onderschat. Aan de ene kant moet de business tijd vrijmaken voor enkele gebruikers om te participeren in het softwareontwikkeltraject. Uit onderzoeken blijkt dat slechts een klein deel van de softwareontwikkeltrajecten daar succesvol in is. Hierdoor kunnen zij minder of geen tijd besteden aan hun dagelijkse werkzaamheden. technieken. 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. Uiteenlopende methoden. Een onderschatting van het requirementsvak is een meer voor de hand liggende verklaring van de huidige problemen. Tenzij de vakliteratuur de plank volledig mis slaat door in de praktijk niet toepasbare handvatten aan te bieden. de opdrachtnemer. de ontwikkelaars en de testers van het systeem. Onderschatting vakgebied Gezien het feit dat zoveel softwareontwikkeltrajecten kampen met problemen op het terrein van de requirements is er veel te verbeteren. De problemen die projecten in de praktijk ondervinden zijn niet te verklaren met een gebrek aan theoretische handvatten en best practices. technieken. de gebruikers. Ook komt het voor dat het werk wordt overgelaten aan onvoldoende gekwalificeerde medewerkers. Requirements vormen een brug tussen de belanghebbenden uit de business en het softwareontwikkelteam. Deel III Requirementsproces en Hoofdstuk 18 Gesprekspartners aan hier nader op in.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.

Hoofdstuk 1 Belang van requirements 11 De belangrijkste succesfactoren voor een softwareontwikkeltraject zijn: kwalitatief goede requirementsspecificaties. voldoende gebruikersinbreng. . managen van wijzigingen in de requirements. 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.

.

Requirements komen in allerlei soorten en maten voor." Directeur: "Vergeet niet dat het systeem absoluut eind volgend jaar operationeel moet zijn. Wat is een requirement? De anekdote hieronder laat zien hoe over het algemeen op het begrip requirements gereageerd wordt. Deze diversiteit blijkt in de praktijk tot verwarring en misverstanden te leiden. Diverse reacties volgen: Hotelmanager: "Het nieuwe systeem moet heel het primaire proces ondersteunen. Dit hoofdstuk beschrijft wat requirements zijn en wat requirements niet zijn. Tijdens de kick-off van een project voor een internationale hotelketen vraagt de projectleider naar de requirements. Naast de diverse vormen van requirements worden allerlei andere zaken onder de noemer van requirements geschaard. Dat moeten we ook gaan doen want dan . Laten we ons daar eerst op concentreren.projecten." Ontwikkelaar: "De belangrijkste requirement is toch dat de klant online een hotelkamer kan reserveren." Receptioniste: "Als klanten de informatie maar in hun moedertaal kunnen lezen.Hoofdstuk 2 Requirements Requirement is een veelgebruikte term binnen softwareontwikkeling. Toch is de betekenis ervan niet altijd duidelijk." Hotelmanager: "Ik heb positieve geluiden gehoord over de nieuwe agilewerkwijze bij ICT." Technisch beheerder: "Het systeem moet in Java gebouwd worden anders kunnen we het niet in beheer nemen.

Een behoefte van een belanghebbende uit de business om verbeteringen in een proces te realiseren met behulp van automatisering. De requirements moeten daaraan bijdragen.De opdrachtgever wil dat de productiviteit op de afdeling orderafhandeling met 20% stijgt (procesverbetering).De inkoper wil laten controleren of de voorraad het minimum bestelniveau heeft bereikt (proces). Requirement als behoefte of als eis De letterlijke betekenis van de term requirement is a) behoefte of b) eis.De klant (van het alarmsysteem) wil potentiële inbrekers afschrikken (procesverbetering).Het systeem moet de orderafhandeling volledig ondersteunen (gedrag).Het systeem moet tegelijkertijd door tienduizend wereldwijd verspreide medewerkers gebruikt kunnen worden (kwaliteit).De manager wil de volledige orderverwerking geautomatiseerd laten ondersteunen (proces). .De systeembeheerder wil vastleggen welke medewerkers toegang tot het systeem mogen krijgen (proces). . namelijk dat de bezettingsgraad van de hotelkamers met 10% moet stijgen. . . Sommige medewerkers hanteren een hoog abstractieniveau en anderen noemen concrete zaken. Het kan zijn: Een behoefte van een belanghebbende uit de business om een nieuw of bestaand proces (of subproces. zodat hij een probleem oplost of een voordeel behaalt.14 Deel I Positionering requirements kunnen we tussentijds bijsturen als de opgeleverde software niet aan onze verwachtingen voldoet. . taak. a) Een requirement is een behoefte aan geautomatiseerde ondersteuning.De opdrachtgever wil de eentonige werkzaamheden bij de orderafhandeling verminderen (procesverbetering). Deze paragraaf legt uit wat een requirement is en laat verschillende verschijningsvormen zien. Voorbeelden van requirements als eis. Voorbeelden van requirements als behoefte. . Een belanghebbende uit de business stelt deze eis aan het systeem. .De inkoper wil de prijs van een product opzoeken (proces). b) Een requirement is een eis die gesteld wordt aan het systeem. De belanghebbende wil daar een bepaald doel mee bereiken. De eis geeft aan wat het gedrag of de kwaliteit van het systeem moet zijn. Soms is het iets dat het systeem moet kunnen en soms is het een eis aan het project." Requirementsanalist:"Laten we beginnen met de reden waarom het nieuwe systeem er moet komen. Deze eisen komen dus voort uit een behoefte van een belanghebbende. ." Een vraag naar de requirements roept uiteenlopende reacties op. . . activiteit) geautomatiseerd te ondersteunen.

Wat Behoefte aan geautomatiseerde ondersteuning Hoe goed Waarom Proces of activiteit Verbetering in een proces Eis aan het systeem Gedrag van het systeem 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.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 bestelniveau heeft bereikt (gedrag). Het systeem moet vastleggen welke medewerkers toegang tot het systeem mogen krijgen (gedrag). Dit geldt alleen voor de requirements die over het 'wat' gaan zoals in Figuur 7: Betekenis van requirement is weergegeven. . De bekendste en meest geciteerde definitie komt van de IEEE (1990) en luidt als volgt: . Het is mogelijk om deze via het proces of via het systeem te benaderen.De inkoper wil de prijs van een product opzoeken (behoefte). . Het systeem moet informatie verschaffen over de prijs van het aangegeven product (gedrag).Het systeem moet opslaan welke medewerkers toegang tot het systeem krijgen (eis). Het systeem moet continu actuele statusinformatie verschaffen (gedrag).De systeembeheerder wil vastleggen welke medewerkers toegang tot het systeem krijgen (behoefte). Definitie Er bestaan meerdere definities van de term requirement. Uit de voorbeelden blijkt dat sommige requirements als behoefte en tevens als eis gezien kunnen worden.Het systeem moet informatie over de prijs van het product verschaffen (eis). Voorbeelden van requirements als eis en tevens als behoefte. . .

specification. Een requirement is: a. Dit boek hanteert de volgende definitie van een requirement. A condition or capability that must be met or possessed by a system or system component to satisfy a contract. is gecombineerd in: het voorzien in een behoefte. hoe veilig. die een belanghebbende uit de business (deels) met behulp van het systeem wil uitvoeren. 3. Het oplossen van een probleem of het bereiken van een doel en het voldoen aan een formeel document. Gebruikers is vervangen door belanghebbenden omdat bijvoorbeeld ook de opdrachtgever. zodat het onderscheid duidelijk is. Bij onderdeel 2 is dat wel duidelijk aangegeven.16 Deel I Positionering requirements A requirement is: 1. 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 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. een behoefte aan geautomatiseerde ondersteuning: een proces of een verbetering daarin. hoe gemakkelijk bruikbaar. lijnmanagers en stafafdelingen requirements kunnen hebben. or other formally imposed document. 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. 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. 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'. In dit boek wordt de gedocumenteerde representatie aangeduid als gespecificeerde requirement of requirementsspecificatie. b. Om duidelijkheid te scheppen is het derde onderdeel van de definitie van IEEE niet overgenomen. hoe foutgevoelig en hoe lang beschikbaar het systeem moet zijn. A documented representation of a condition or capability as in 1 or 2. Denk bijvoorbeeld aan hoe snel. Een niet-functionele requirement is een kwaliteitseis waaraan het systeem moet voldoen. standard. . Hierbij is condition or capability niet letterlijk vertaald maar concreter geformuleerd als gedrag of kwaliteit. Een functionele requirement geeft het gewenste gedrag van het systeem weer. A condition or capability needed by a user to solve a problem or achieve an objective. 2.

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

Sign up to vote on this title
UsefulNot useful