Requirements. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Transcriptie

1 Requirements Een introductie Algemene informatie voor medewerkers van: SYSQA B.V.

2 Organisatie SysQa BV Pagina 2 van 19 Inhoudsopgave 1 INLEIDING ALGEMEEN WAT ZIJN REQUIREMENTS DEFINITIE VAN REQUIREMENTS NIVEAUS VAN REQUIREMENTS HET BELANG VAN REQUIREMENTS GEVOLGEN VAN SLECHTE REQUIREMENTS VEEL VOORKOMENDE PROBLEEMSITUATIES VANUIT DE REQUIREMENTSFASE EFFECTEN VAN GOEDE REQUIREMENTS REQUIREMENTSPROCESSEN REQUIREMENTSONTWIKKELING REQUIREMENTSMANAGEMENT PRIORITEITSBEPALING VAN REQUIREMENTS LITERATUUROPGAVEN BIJLAGE 1 VOORBEELD REQUIREMENTSONTWIKKELPROCES... 16

3 Organisatie SysQa BV Pagina 3 van 19 1 Inleiding 1.1 Algemeen In dit document is beschreven wat requirements zijn en wat in software ontwikkeling het belang is van requirements, die van kwalitatief voldoende niveau zijn. Tevens bevat dit document verwijzingen naar hulpmiddelen en sjablonen en een verwijzing naar literatuur voor verdere verdieping van in dit onderwerp. Het document staat ter beschikking van elke Sysqa-professional die rechtstreeks met deze materie te maken krijgt, of zich hierin wil verdiepen. Naast dit algemene document is er een aparte introductie gericht op requirements en testen. Deze is te vinden op de kennisbank. De introductie is mede gebaseerd en in lijn met het Nederlandstalige boek over requirements, Succes met de requirements! (lit.: 15). In het gehele document wordt de term requirements in plaats van eisen gebruikt, omdat: voor requirements engineering als overkoepelende term geen Nederlands equivalent beschikbaar is (mocht een Nederlandse term nodig zijn, dan kan eisenbeheer & -ontwikkeling worden gebruikt); veel bedrijven deze term hanteren; het aantal hits op internet (alleen Nederlandse sites) overwegend het gebruik van de term requirements voor eisen in ICT-trajecten weergeeft.

4 Organisatie SysQa BV Pagina 4 van 19 2 Wat zijn requirements 2.1 Definitie van requirements In de literatuur is geen eenduidige definitie van requirements beschikbaar. IEEE standaard Glossary of Software Engineering Terminology (lit.: 3) geeft de volgende definitie voor een requirement 1 : 1. Een voorwaarde aan of een mogelijkheid van een systeem die een gebruiker nodig heeft om een probleem op te lossen of om een doel te bereiken. 2. Een voorwaarde aan of een mogelijkheid waarover een systeem of deelsysteem moet beschikken om te voldoen aan de eisen voor een contract, standaard, specificatie of een ander formeel opgelegd document. 3. Een gedocumenteerde beschrijving van een conditie of vermogen zoals in 1 of 2 is verwoord. Deze definitie uit IEEE wordt ook gehanteerd door de ontwikkelmethodiek RUP en door het proces verbetermodel CMMI. De definitie voor requirements, die in dit document wordt gehanteerd, is door Sawyer (lit.: 7) als volgt beschreven: Het is een specificatie van eisen waaraan het systeem moet voldoen. Het zijn beschrijvingen van hoe een systeem zich moet gedragen, of van een systeemeigenschap of van een functionaliteit. Het kunnen ook grenzen of beperkingen zijn vanuit het ontwikkelproces. Deze definitie benadrukt de veelzijdigheid van requirements. Tevens maakt deze definitie duidelijk dat als iemand in een organisatie spreekt over de requirements voor een ICT-systeem er waarschijnlijk slechts requirements vanuit één bepaald gezichtspunt bij deze persoon op het netvlies staan. Welke requirements dit zijn is afhankelijk van de positie en rol van degene die deze requirements benoemt. Onderkennen en benoemen van deze kans op miscommunicatie voorkomt vaak al veel misvatting rondom het opstellen van requirements. 2.2 Niveaus van requirements Volgens Wiegers (lit.: 9) en Succes met de requirements! (lit.:15) kunnen voor requirements van software drie niveaus worden onderscheiden: 1. business requirements 2. gebruikersrequirements (user requirements) 3. systeem requirements (functional requirements) Deze 3 niveaus zijn weergegeven in figuur Letterlijke definitie uit de IEEE standard: 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)

5 Organisatie SysQa BV Pagina 5 van 19 Functioneel Business requirements Business rules Nietfunctioneel Bedrijfsdoelstellingen Kwaliteitseisen Beperkingen Gebruikers requirements Visie en scope document Use case specificatie Systeem requirements Systeem requirements specificatie Figuur 2.1: Drie niveaus in requirements van software Business requirements komen voort uit de doelstellingen van een organisatie of een klant die een nieuw systeem wil. Business requirements worden bepaald op hoog niveau en de requirements die hieruit komen worden vastgelegd in een visie of scope document (zie sjabloon visie en scope). De Gebruikers requirements beschrijven voor een gebruiker doelen of taken die het systeem moet kunnen uitvoeren en worden afgeleid van de business requirements en business rules. Deze requirements worden veelal vastgelegd in een use-case document (zie sjabloon use case). Systeem requirements (door Wiegers functional requirements genoemd) beschrijven de functionaliteit van de software die gebouwd gaat worden, en komen voort uit gebruikers requirements, overkoepelende systeem requirements en kwaliteitsattributen. Indien een systeem uit meerdere deelsystemen bestaat, wordt ieder systeemrequirement toegewezen aan een of meer deelsystemen.

6 Organisatie SysQa BV Pagina 6 van 19 Deze requirements (business, gebruikers en systeem requirements) beschrijven de benodigde en gewenste functionaliteit van het systeem. Daarnaast moet ook rekening worden gehouden met requirements die voortkomen uit: bedrijfsdoelstellingen business rules kwaliteitseisen (op basis van ISO 9126) beperkingen. Bedrijfsdoelstelling geven aan wat de organisatie in de toekomst wil bereiken. De (algemene) bedrijfsdoelstellingen worden vertaald in specifieke projectdoelstellingen die weer input zijn voor het ontwikkeltraject voor het specifiek te ontwikkelen systeem. Business rules bevatten bedrijfsregels, wettelijke regelingen, industriële standaards etc. Kwaliteitseisen bevatten eisen op het gebied van bijvoorbeeld gebruikersvriendelijkheid, portabiliteit, integriteit, efficiëntie en robuustheid. Dit worden ook wel de niet-functionele requirements genoemd. Beperkingen ( constraints ) leggen beperkingen op aan de beschikbare keuzes die een ontwerper heeft. Uiteindelijk dienen alle requirements op enigerlei wijze dusdanig gestructureerd te zijn vastgelegd dat het voor het ontwerp en bouwproces voldoende input levert om met hoge zekerheid een bruikbaar systeem te kunnen bouwen. Het hanteren van een systeem requirementsspecificatie (SRS) is hierbij een best practice (zie bijlage SRS). Requirements dienen zelf ook aan een aantal eisen te voldoen. Requirements kunnen hieraan ook getoetst worden. De volgende eisen aan requirements kunnen in de praktijk worden toegepast. Het requirementsdocument # Eis Toelichting 1A is onderworpen aan beheer Het document heeft een datum, een versienummer en een opsteller. 1B beschrijft zowel functionele als Het document bevat ook kwaliteitsattributen zoals bv. niet-functionele requirements bruikbaarheid, performance, beschikbaarheid, degradeerbaarheid. (FURPS / ISO 9126) 1C is gebaseerd op een Als de stakeholdersanalyse ontbreekt, niet volledig of niet goedgekeurde stakeholdersanalyse goedgekeurd is, bestaat het risico dat de set requirements onvolledig is. De individuele statements # Naam Toelichting 2 hebben kenmerkende attributen unieke identificatie business owner rationale prioriteit 3 zijn atomair Atomair = ondeelbaar: één statement definieert één eis. 4 zijn traceerbaar Systeem requirements zijn herleidbaar tot gebruikersrequirements, die herleidbaar zijn tot de business requirements, die gebaseerd zijn op de bedrijfsdoelstelling. 5 zijn grammaticaal correct opgesteld 6 bevatten geen verboden woorden De zinnen in de beschrijving: zijn volledig; zijn bij voorkeur in de actieve vorm gesteld; hebben een onderwerp (bv. gebruiker, organisatie, systeem); hebben een gezegde. Gebruik geen constructies die: een niet-gespecificeerd tijdsaspect definiëren:

7 Organisatie SysQa BV Pagina 7 van 19 soms, langzaam, snel, binnenkort, periodiek ; een niet-gespecificeerde conditie bevatten: mogelijk, uiteindelijk, gewoonlijk, normaliter ; niet-gespecificeerde aantallen opgeven: veel, enkele, verscheidene, vaak ; niet nader gespecificeerde kwalificaties toekennen: goed, voldoende, passende. 7 zijn SMART vormgegeven Specifiek: punten 2, 3, 5, 6 en 9; Meetbaar: hoe stel je vast dat een requirement correct geïmplementeerd is; Acceptabel: teruggekoppeld aan en goedgekeurd door de business; Realistisch: het requirement heeft realiteitswaarde; bv. een availability van 100% is niet realistisch; Tijdgebonden: benoem tijdstip, release in relatie tot de prioriteit. 8 bevatten geen ontwerpaspecten Het introduceren van een oplossingsrichting beperkt de overige alternatieven. 9 zijn uniform gedefinieerd Maak bv. gebruik van een verklarende woordenlijst (glossary). 10 zijn onderling consistent Mogen elkaar niet tegenspreken of uitsluiten Het hanteren van deze eisen en het expliciet toetsen van requirementslijsten en requirementsdocumenten aan deze eisen leidt tot verheldering en verscherping van een requirementsset. Dit voorkomt vervolgens onterechte aannames, misvattingen en de daarmee gepaard gaande herstelwerkzaamheden (herontwerp, herbouw, hertest).

8 Relatieve kosten voor correctie van een fout Organisatie SysQa BV Pagina 8 van 19 3 Het belang van requirements 3.1 Gevolgen van slechte requirements Requirements leveren de input voor een software ontwikkeltraject. Zonder goede input is de kans op goede output nagenoeg nihil: garbage in is garbage out. Een groot risico van het niet voldoen aan alle voorwaarden die gesteld mogen worden aan requirements is dat werk moet worden overgedaan. In de grafiek van figuur 3.1 zijn de relatieve kosten om een fout te herstellen weergegeven per ontwikkelfase. Deze grafiek is het resultaat van onderzoek verricht door Barry Boehm (lit.: 13) en staat ook bekend als De wet van Boehm. Deze wet toont aan dat fouten die pas laat in het ontwikkelproces worden gevonden vele malen meer inspanning kosten om te herstellen dan diezelfde fouten gevonden in de requirementsfase. De wet toont tevens aan dat reviewinspanningen en expliciete beoordeling van requirementsdocumenten zeer lonende activiteiten zijn die het totale ontwikkeltraject niet vertragen maar juist versnellen. Ondanks het feit dat dit onderzoek verricht is in 1981 gaat deze wet nog steeds op binnen softwareontwikkeling. Nieuwe systeemontwikkelmethoden en tooling hebben op zich wel geholpen om in kortere tijd meer functionaliteit te kunnen bouwen. Gebrekkige requirements kunnen er echter voor zorgen dat systeemontwikkeling uiteindelijk ondanks alle technische vernuft toch niet sneller gaat: hooguit dat sneller onbruikbare software wordt gebouwd requirements ontwerp bouw test operation ontwikkelfase Figuur 3.1: Herstelkosten per ontwikkelfase Een andere motivatie om bij projecten kritisch te kijken naar requirements kan herleid worden uit de zogenaamde beheerparadox van Berghout.

9 Organisatie SysQa BV Pagina 9 van 19 Figuur 3.2 Requirements en Levenscycluskosten (vrij naar Berghout) De beheerparadox maakt zichtbaar dat in het algemeen de totale kosten van een applicatie gedurende de gehele levenscyclus van deze applicatie hoofdzakelijk (ca. 80%) uit beheerkosten bestaan. De kosten gemaakt tijdens het ontwikkeltraject vertegenwoordigen slechts een klein deel (ca 20%) van de totale applicatiekosten. De omvang van de totale kosten evenals de opbrengsten van de applicatie (business benefits) worden echter voornamelijk bepaald tijdens de start van het project: tijdens het vaststellen van de requirements. Bij de start van een project kan namelijk alles nog veranderen; alles is beïnvloedbaar. De mate van beïnvloeding neemt gedurende het ontwikkelproces af; wijzigingen in functionaliteit of wijze van bouwen veroorzaken later in het traject telkens meer rework en worden op een gegeven moment onrendabel. Indien bij aanvang van de systeemontwikkeling onvoldoende aandacht en focus is voor gewenste businessdoelstellingen, de bijdrage die de applicatie voor de business dient te leveren, dan kan er een systeem ontstaan dat op zich prima werkt maar onvoldoende bespaart of onvoldoende extra business genereert. Daarnaast kunnen beoogde besparingen in het project om tijdslijnen nog te halen, lees weglaten van functionaliteit, wel eens tot zeer grote reductie van de meerwaarde van applicatie leiden. Tevens kan onvoldoende aandacht tijdens ontwikkeling voor de exploitatiekosten van de applicatie wel eens tot enorme kostenstijgingen tijdens exploitatie van de applicatie leiden. Het stellen van duidelijke requirements vanuit beheer tijdens de start van een project kan dit voorkomen. Beslissingen over het niet voldoen aan bepaalde beheerrequirements kan dan direct vertaald worden tot meer beheerbudget waar de opdrachtgever dan alvast rekening mee kan houden. De requirements die vanuit beheer aan het project worden opgelegd zorgen ervoor dat het project niet alleen op de projectkosten stuurt maar indirect ook op de exploitatiekosten. En die laatste zijn vanwege de veel grotere omvang veel belangrijker. 3.2 Veel voorkomende probleemsituaties vanuit de requirementsfase De volgende situaties komen in de praktijk regelmatig voor in de requirementsfase van een ontwikkeltraject. Weinig betrokkenheid van de eindgebruikers: wanneer eindgebruikers te weinig worden betrokken of betrokkenheid tonen bij het opstellen van requirements kan dit leiden tot het te laat en/of onvoldoende naar boven komen van gebruikersrequirements. Hierdoor kan de acceptatie in gevaar komen en/of worden in productie de beoogde doelstellingen niet bereikt. Weinig betrokkenheid van de ontwikkelaars: wanneer ontwikkelaars te weinig worden betrokken of betrokkenheid tonen bij het opstellen van requirements kan dit leiden tot het te laat en/of onvoldoende naar boven komen van technische onhaalbaarheden. Hierdoor kan de realisatie en acceptatie in gevaar komen en/of worden in productie de beoogde doelstellingen niet bereikt.

10 Organisatie SysQa BV Pagina 10 van 19 Veranderende gebruikersrequirements: gedurende het ontwikkelingsproces veranderen (groeien) gebruikersrequirements. Meestal gebeurt dit op basis van voortschrijdend inzicht (gebruikers die gedurende het project wijzigingsverzoeken indienen). Dit kan ondervangen worden door aan het begin van het project duidelijke afspraken over de scope vast te leggen en het wijzigingsbeheer in te richten. Vervolgens moet de projectleider of degene die binnen het project verantwoordelijk is voor beheer van requirements tijdens het project er op toezien dat hier ook naar wordt gehandeld. Dubbelzinnige requirements: wanneer requirements op meerdere manieren uitgelegd kunnen worden, is het mogelijk dat verschillen ontstaan tussen de verwachting van belanghebbenden en de interpretatie van de ontwikkelaars. Dit kan worden voorkomen door vertegenwoordigers van belanghebbenden de requirements te laten inspecteren. Onbedoelde functionaliteit: in een systeem wordt functionaliteit toegevoegd die niet voortkomt uit de requirements. Dit kan vertragend en kostenverhogend werken op het project. Door ervoor te zorgen dat alle gemaakte functionaliteiten terug te voeren zijn naar een vastgestelde requirement kan dit worden voorkomen. Vage of onvolledige specificaties: soms wordt een globale schets gemaakt van het systeem en moeten de ontwerpers tijdens het project de specificaties boven water halen. Dit kan leiden tot een eigen interpretatie van ontwerpers, teleurstelling bij de gebruikers en uitloop van het hele project. Vergeten belanghebbenden: Het is belangrijk om tijdig alle belanghebbenden te identificeren. Wanneer een dergelijke persoon of groep wordt vergeten, kunnen ook noodzakelijke requirements worden vergeten. Voor het identificeren van belanghebbenden is binnen SYSQA een sjabloon aanwezig (de stakeholder analyse). Daarnaast vormt vastlegging van de resultaten van de stakeholdersanalyse onderdeel van het sjabloon visie en scope document. Onrealistische planning van de requirementsfase: requirements opstellen vergt tijd. Hoeveel tijd het vergt om uiteindelijk tot een set requirements te komen die volledig genoeg is om als input te dienen voor het ontwikkelproces is op voorhand niet te zeggen. Requirements opstellen is te vergelijken met een ontdekkingstocht: je weet onderweg pas wat je tegenkomt. Vaak is vanuit het project én de opdrachtgever veel druk om snel met ontwerpen of, nog liever, met bouwen te starten. Voor het reviewen van requirementsdocumenten is dan geen tijd. De paradox is echter (zie wet van Boehm) dat als een project onder tijdsdruk staat en er weinig ruimte is voor uitloop juist het reviewen van requirements zorgt voor voldoende tijd: het is nu eenmaal minder werk om in één keer het juiste te bouwen dan om dit in twee keer te doen. 3.3 Effecten van goede requirements Wanneer het requirementsproces goed is ingericht treden de volgende voordelen op: minder fouten in requirements en daardoor minder fouten tijdens exploitatie; minder herstelwerk gedurende het ontwikkeltraject; minder onnodige functionaliteit; minder extra kosten; sneller ontwikkeltraject; minder miscommunicatie; minder veranderende scope; ordelijker verlopend project; grotere nauwkeurigheid tijdens het testen; hogere tevredenheid van ontwikkelaars, gebruikers en overige belanghebbenden; betere beheersing van de ICT-exploitatiekosten.

11 Organisatie SysQa BV Pagina 11 van 19 4 Requirementsprocessen De processen requirementsontwikkeling en requirementsmanagement vormen samen de requirementsprocessen. Daarnaast wordt ook de term requirements engineering in de praktijk gebruikt als overkoepelende term voor alle requirementsprocessen. Figuur 4.1: Requirementsprocessen De processen Requirementsontwikkeling en Requirementsmanagement zijn in paragraaf 4.1 en 4.2 beknopt uitgewerkt. Paragraaf 4.3 gaat nog in op prioriteitsbepaling van requirements. 4.1 Requirementsontwikkeling Requirementsontwikkeling is een typisch iteratief proces, zelfs als bij de te hanteren ontwikkelmethodiek voor waterval is gekozen. Nadere uitwerking van requirements die in het begin zijn gesteld leiden over het algemeen tot nieuw inzicht, uitbreiding van requirements, nadere detaillering en vaak dus tot aanpassing van eerder geformuleerde requirements. In hoofdlijnen kan het proces als volgt worden geschetst (lit.: 9): opnieuw beoordelen elicitatie Analyse Specificatie Validatie Realisatie verduidelijken herschrijven gaten dichten Figuur 4.2: requirements ontwikkelproces Deze processtappen worden uitgewerkt in activiteiten. Een mogelijke uitwerking van de stappen is opgenomen in bijlage 1.

12 Organisatie SysQa BV Pagina 12 van Requirementsmanagement Bij het ontwikkelen, aanpassen of vervangen van een informatiesysteem wordt de rode draad gevormd door het geheel aan requirements. Op hoofdlijnen kan onderscheid worden gemaakt tussen projectrequirements (met hoeveel geld, met wie, wanneer, waar en hoe gaan we het doen) en productrequirements (wat gaan we doen). De productrequirements omvatten naast de specifiek aan het product gestelde eisen ook alle productgerelateerde zaken als benodigde infrastructuur, de administratieve organisatie rondom het informatiesysteem en de beheer- en onderhoudseisen. Het proces dat zich bezig houdt met het specificeren van de requirements is requirementsontwikkeling met als belangrijkste resultaat de overeengekomen set van requirements, vastgelegd in de requirementsbaseline. Deze requirementsbaseline, ook wel eisendossier, vormt de brug van requirementsontwikkeling naar requirementsmanagement. Bij het ontwikkelen van de requirements ligt de nadruk op analyse, bewustwording en het helder formuleren van de requirements van de verschillende belanghebbenden. Bij requirementsmanagement ligt de nadruk op het beheersen en beheren van de overeengekomen set requirements, het voorkómen van ongewenste scope-uitbreidingen en misverstanden over de inhoud van requirements gedurende het project. Het betreft het managen van alle productrequirements, ontvangen door of ontstaan binnen het project. Het omvat in die zin ook requirementsontwikkeling, met name bij aanpassingen, uitbreidingen en verdere detaillering van de requirements. Het doel van requirementsmanagement is het beheren van de requirements van de producten en productcomponenten van het project en het identificeren van inconsistenties tussen die requirements en de projectplannen en werkproducten. De originele tekst uit 'CMMI for development' luidt: The purpose of Requirements Management (REQM) is to manage the requirements of the project s products and product components and to identify inconsistencies between those requirements and the project s plans and work products. Door toepassing van requirementsmanagement wordt zeker gesteld dat de set van overeengekomen requirements voor een informatiesysteem volledig en juist wordt geïmplementeerd. Een bijkomend (projectmanagement) voordeel van requirementsmanagement is dat de kans op het op tijd implementeren sterk toeneemt doordat ongewenste scope-fluctuaties en misverstanden bij acceptatie sterk worden verminderd. De voordelen van requirementsmanagement: de eisen voor een traject zijn beter te beheersen; de intake van eisen wordt verbeterd; de klanteisen zijn explicieter en vollediger beschreven in een vroegtijdig stadium; het changemanagement t.a.v. requirements van de klant is beter ingericht; minder kosten voor aanpassingen achteraf; een duidelijkere verwachting tussen klant en leverancier; minder onverwachte uitloop van projecten; verbetering van de traceerbaarheid van eisen tijdens het ontwikkeltraject en bij wijzigingen. Kortom: de product- én projectkwaliteit nemen toe én risico s op overschrijding van tijd en budget nemen af. Bij aanvang van het project kan de set van dan overeengekomen requirements, de requirementsbaseline, dienen als startpunt voor wat in de ontwikkelfase moet worden gemaakt. Vervolgens wordt deze set van requirements gedurende het verdere ontwikkelingstraject gemanaged op de volgende aspecten: Inhoud en samenhang: Middels baselinebeheer en wijzigingenbeheer wordt de impact van de overeengekomen of overeen te komen set requirements geanalyseerd en moet worden vastgesteld of deze wordt gehonoreerd. Een wijziging kan een nieuw, gewijzigd, samengevoegd, opgedeeld of vervallen (pakket van) requirements zijn. Prioriteit: Welk belang hebben de (gewijzigde) requirements binnen het geheel. Hoe snel dienen ze geïmplementeerd te worden of hoe belangrijk zijn ze op de langere termijn. Welk risico wordt gelopen bij wel of niet implementeren. Het kan verstandig zijn om bepaalde requirements niet mee te nemen om bijvoorbeeld eerst een stabiel draaiend basissysteem te hebben. Tijdens requirementsontwikkeling wordt de prioriteit vastgesteld. Bij wijzigingen ten gevolge van scopeverandering of voortschrijdend inzicht dient opnieuw de prioriteit te worden vastgesteld van de

13 Organisatie SysQa BV Pagina 13 van 19 relevante requirements. Blijft de releasestructuur ongewijzigd of heeft de requirementswijziging hier impact op? Bij een significante wijziging kan het verstandig zijn om voor het wijzigingsgebied opnieuw de requirements ontwikkelprocessen te doorlopen. Versie: Middels configuratiebeheer worden de wijzigingen verwerkt in (onderdelen van) een nieuwe versie van de gehele set en de individuele requirements. Status: Een gewijzigd requirement doorloopt een aantal logisch opeenvolgende statussen. Bijvoorbeeld concept, te analyseren, overeengekomen, gerealiseerd, getest, in productie, vervallen. Traceerbaarheid: Een goedgekeurd, gewijzigd requirement gaat het ontwikkelproces in waar bijvoorbeeld ontwerpen, programma s, testen en handleidingen worden aangemaakt. Voor een juiste borging van de consistentie, volledigheid en onderhoudbaarheid wordt de relatie tussen de requirements en deze (tussen) producten bijgehouden. Om goed te kunnen managen op bovenstaande aspecten wordt bij aanvang van requirementsmanagement vastgesteld hoe dit vorm wordt gegeven. Bijvoorbeeld welke procedures worden gehanteerd, hoe liggen de verantwoordelijkheden, welke organisatieonderdelen zijn betrokken, welke methoden, technieken en tools worden gebruikt en wat zijn eventuele eerdere ervaringen hiermee. Dit is al van belang bij het ontstaan van de eerste requirements; hoe eerder dit is geregeld hoe beter. Hetzij door al eerder op organisatieniveau vastgestelde standaarden te hanteren, hetzij door in het requirementsdossier een aparte beschrijving hiervoor op te nemen. In ieder geval dient dit eenduidig vastgesteld en overeengekomen te zijn tussen opdrachtgever en opdrachtnemer. 4.3 Prioriteitsbepaling van requirements Het toekennen van de juiste prioriteiten aan requirements zorgt ervoor dat het systeem zo snel mogelijk en zoveel mogelijk waarde oplevert voor de betreffende organisatie Om deze voordelen te borgen zal aan de belangrijkste requirements de hoogste prioriteit worden toegekend, zodat hieraan ook de eerste en meeste ontwikkelinspanning wordt besteed. Hoe logisch dit ook klinkt: duidelijke sturing hierop blijkt in de praktijk noodzakelijk, om te voorkomen dat een te groot deel van ontwikkelcapaciteit wordt besteed aan relatief onbelangrijke eisen. Ter borging dient projectbreed en duidelijk het belang van ieder specifiek requirement vastgesteld te worden. Voorafgaand aan het vaststellen van het belang van requirements vanuit businessperspectief dient eerst nog te worden gekeken naar risico s met betrekking tot het daadwerkelijk kunnen realiseren van een requirement. Uitwerking van deze requirements moet zo vroeg mogelijk in het project gerealiseerd worden en heeft de hoogste urgentie, omdat bij het niet voldoen aan deze requirements mogelijk de gehele business case voor het project in gevaar komt. Om de prioriteit voor realisatie van requirements te kunnen bepalen spelen twee aspecten een rol, namelijk belang en urgentie. Belang is iets anders dan urgentie. Belang geeft de mate van waarde voor de organisatie aan. Belang is te koppelen aan de business case: in welke mate draagt een requirement bij aan realisatie van de business case? Voorwaarde voor het kunnen bepalen van het belang van ieder requirement is dat er initieel een business case is geformuleerd. Urgentie heeft te maken met planning. Soms wordt realisatie van een minder belangrijke eis vanwege beperkte beschikbaarheid van mensen of middelen toch eerder gepland; op een later tijdstip kan aan de eis eenvoudigweg niet meer of tegen veel hogere kosten worden voldaan. Het vaststellen van het belang is typisch een aangelegenheid van alle belanghebbenden. Verschillende technieken bestaan voor het vaststellen van het belang van requirements. Een eenvoudige techniek is stikkeren. Iedere deelnemer ontvangt een beperkt aantal stikkers en plakt deze op een requirement. Het is zelfs toegestaan alle stikkers op één specifieke requirement te plakken. Deze techniek zorgt ervoor dat volgens vooraf gestelde spelregels door alle belanghebbenden tot een rechtvaardige waarde van het belang van requirements kan worden gekomen. Door de spelregels los te koppelen van de discussie over de requirements zelf, wordt voorkomen dat de hardste schreeuwer of degene met de grootste overredingskracht zonder meer de belangrijkheid vaststelt. De toe te passen techniek en spelregels kunnen per organisatie verschillen. Bij een organisatie met een sterk hiërarchische structuur en cultuur zullen spelregels ontstaan waarbij een hoog niveau in de hiërarchie gelijk staat aan veel invloed op belangrijkheid van requirements.

14 Organisatie SysQa BV Pagina 14 van 19 Een voorbeeld van een werkwijze om te komen tot specifieke, geprioriteerde en meetbare requirements is opgenomen in de bijlage Workshop Verkrijgen (Draaiboek RD-sessie). Het vaststellen van de urgentie is een typisch projectinterne aangelegenheid. In principe vindt realisatie van requirements plaats in volgorde van belangrijkheid. Daar waar wordt afgeweken levert de betreffende verantwoordelijke een duidelijke motivatie waaruit noodzaak tot afwijking blijkt. Deze afwijking wordt vervolgens ook duidelijk in planningen opgenomen. Daarmee is de volgorde voor het afhandelen van requirements voor alle betrokkenen duidelijk bepaald en is dit voor alle betrokkenen inzichtelijk. De eerste belang- en urgentiebepaling vindt plaats tijdens de fase van requirementsontwikkeling. Gedurende het project kan belang en urgentie wijzigingen. Het requirementsmanagementproces dient dusdanig te zijn gericht dat het voorziet in het snel en adequaat kunnen doorvoeren van wijzigingen.

15 Organisatie SysQa BV Pagina 15 van 19 5 Literatuuropgaven 1. Cockburn A., Writing Effective Use Cases, Addison-Wesley, Grady, Robert B An Economic Release Decision Model: Insights into Software Project Management. 3. IEEE Std IEEE Standard Glossary of Software Engineering Terminology -Description 4. Kotonya G. and I. Sommerville, Requirements Engineering Processes and Techniques, John Wiley & Sons, Robertson Suzanne and James, Mastering the Requirements Process, Addison-Wesley, Schneider G. and J. Winters, Applying Use Cases: A Practical Guide, Addison-Wesley, Sawyer, P., Sommerville, I. and Viller, S. (1996). PREview: Tackling the Real Concerns of Requirements Engineering. Cooperative Systems Engineering Group, Technical Reports Sommerville I. and P. Sawyer, Requirements Engineering: A Good Practice Guide, John Wiley & Sons Ltd., Wiegers Karl E., Software Requirements, Microsoft Press, Jos Warmer en Anneke Kleppe, Praktisch UML 3 de editie, Pearson Education Uitgeverij, 2004, 11. Sassenburg, ir. Hans, Software Engineering: Van ambacht naar professie, Tutein Nolthenius, CMMI for Development CMMI-DEV, V1.2, Carnegie Mellon University, Barry W Boehm, Software Engineering Economics, Prentice-Hall, ISBN , Cannegieter, Jan Jaap, Kwaliteitszorg in ICT projecten - de PROQA methode, Ten Hagen Stam, ISBN , M. Arendsen, H.J.J. Cannegieter, A. Grund, P. Heck, S. de Klerk en J. Zandhuis, Succes met de requirements!, tweede herziene druk, SDU, ISBN , 2010