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

Requirements Een introductie

Algemene informatie voor medewerkers van: SYSQA B.V.

Organisatie Titel Onderwerp

SysQa BV Requirements Een introductie

Pagina Versie Datum

2 van 19 1.3 16-03-2011

Inhoudsopgave 1

INLEIDING............................................................................................................................... 3 1.1

2

WAT ZIJN REQUIREMENTS .................................................................................................. 4 2.1 2.2

3

GEVOLGEN VAN SLECHTE REQUIREMENTS .......................................................................... 8 VEEL VOORKOMENDE PROBLEEMSITUATIES VANUIT DE REQUIREMENTSFASE ......................... 9 EFFECTEN VAN GOEDE REQUIREMENTS ............................................................................ 10

REQUIREMENTSPROCESSEN ............................................................................................ 11 4.1 4.2 4.3

5

DEFINITIE VAN REQUIREMENTS ........................................................................................... 4 NIVEAUS VAN REQUIREMENTS ............................................................................................ 4

HET BELANG VAN REQUIREMENTS.................................................................................... 8 3.1 3.2 3.3

4

ALGEMEEN........................................................................................................................ 3

REQUIREMENTSONTWIKKELING ........................................................................................ 11 REQUIREMENTSMANAGEMENT.......................................................................................... 12 PRIORITEITSBEPALING VAN REQUIREMENTS ...................................................................... 13

LITERATUUROPGAVEN ...................................................................................................... 15

BIJLAGE 1 VOORBEELD REQUIREMENTSONTWIKKELPROCES .......................................... 16

Almere © 2011

Proud of it


1 1.1


Pagina Versie Datum

3 van 19 1.3 16-03-2011

Inleiding 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.

Almere © 2011

Proud of it


2


Pagina Versie Datum

4 van 19 1.3 16-03-2011

Wat zijn requirements

2.1

Definitie van requirements

In de literatuur is geen eenduidige definitie van requirements beschikbaar. IEEE standaard Glossary of 1 Software Engineering Terminology (lit.: 3) geeft de volgende definitie voor een requirement : 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 2.1.

1

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)

Almere © 2011

Proud of it



Pagina Versie Datum

Functioneel

5 van 19 1.3 16-03-2011

Nietfunctioneel

Business requirements Visie en scope document Bedrijfsdoelstellingen Business rules

Gebruikers requirements

Kwaliteitseisen

Use case specificatie

Beperkingen

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.

Almere © 2011

Proud of it



Pagina Versie Datum

6 van 19 1.3 16-03-2011

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

3 4

5

6

unieke identificatie business owner rationale prioriteit … zijn atomair Atomair = ondeelbaar: één statement definieert één eis. … zijn traceerbaar Systeem requirements zijn herleidbaar tot gebruikersrequirements, die herleidbaar zijn tot de business requirements, die gebaseerd zijn op de bedrijfsdoelstelling. … zijn grammaticaal correct De zinnen in de beschrijving: opgesteld zijn volledig; zijn bij voorkeur in de actieve vorm gesteld; hebben een onderwerp (bv. gebruiker, organisatie, systeem); hebben een gezegde. … bevatten geen verboden Gebruik geen constructies die: woorden een niet-gespecificeerd tijdsaspect definiëren: Almere © 2011

Proud of it


7

8 9 10


Pagina Versie Datum

7 van 19 1.3 16-03-2011

“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”. Specifiek: punten 2, 3, 5, 6 en 9; … zijn SMART vormgegeven 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. … bevatten geen ontwerpaspecten Het introduceren van een oplossingsrichting beperkt de overige alternatieven. … zijn uniform gedefinieerd Maak bv. gebruik van een verklarende woordenlijst (glossary). … 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).

Almere © 2011

Proud of it


3


Pagina Versie Datum

8 van 19 1.3 16-03-2011

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…….

120

Relatieve kosten voor correctie van een fout

100 80 60 40 20 0 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.

Almere © 2011

Proud of it



Pagina Versie Datum

9 van 19 1.3 16-03-2011

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. Almere © 2011

Proud of it



Pagina Versie Datum

10 van 19 1.3 16-03-2011

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.

Almere © 2011

Proud of it


4


Pagina Versie Datum

11 van 19 1.3 16-03-2011

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

verduidelijken

Validatie

Realisatie

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.

Almere © 2011

Proud of it



Pagina Versie Datum

12 van 19 1.3 16-03-2011

4.2 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 Almere © 2011

Proud of it



Pagina Versie Datum

13 van 19 1.3 16-03-2011

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.

Almere © 2011

Proud of it



Pagina Versie Datum

14 van 19 1.3 16-03-2011

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.

Almere © 2011

Proud of it


5


Pagina Versie Datum

15 van 19 1.3 16-03-2011

Literatuuropgaven 1. Cockburn A., Writing Effective Use Cases, Addison-Wesley, 2001. 2. Grady, Robert B. 1999. “An Economic Release Decision Model: Insights into Software Project Management.” 3. IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology -Description 4. Kotonya G. and I. Sommerville, Requirements Engineering – Processes and Techniques, John Wiley & Sons, 1998. 5. Robertson Suzanne and James, Mastering the Requirements Process, Addison-Wesley, 1999 6. Schneider G. and J. Winters, Applying Use Cases: A Practical Guide, Addison-Wesley, 1998. 7. Sawyer, P., Sommerville, I. and Viller, S. (1996). PREview: Tackling the Real Concerns of Requirements Engineering. Cooperative Systems Engineering Group, Technical Reports 1996 8. Sommerville I. and P. Sawyer, Requirements Engineering: A Good Practice Guide, John Wiley & Sons Ltd., 1997. 9. Wiegers Karl E., Software Requirements, Microsoft Press, 1999. 10. 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, 2002 12. CMMI® for Development CMMI-DEV, V1.2, Carnegie Mellon University, 2006 13. Barry W Boehm, Software Engineering Economics, Prentice-Hall, ISBN 0-13-822122-7, 1981 14. Cannegieter, Jan Jaap, Kwaliteitszorg in ICT projecten - de PROQA methode, Ten Hagen Stam, ISBN 90-440-0369-0, 2001 15. 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 9789012582056, 2010

Almere © 2011

Proud of it



Pagina Versie Datum

16 van 19 1.3 16-03-2011

Bijlage 1 Voorbeeld requirementsontwikkelproces De hieronder geschetste stappen hoeven niet per se in deze volgorde te worden uitgevoerd: het is een voorbeeld van mogelijke implementatie van het requirements ontwikkelproces. De daadwerkelijke implementatie is afhankelijk van de te hanteren systeemontwikkelmethodiek. Per project dient vooraf minimaal in een soortgelijk schema te zijn aangegeven volgens welke procedure er wordt gewerkt. Dit schema maakt het voor alle betrokkenen transparant op welke wijze requirements binnen het project tot stand komen en welke bijdrage zij hieraan kunnen en moeten leveren. Tevens is deze vastlegging van de spelregels vooraf een goede basis voor aanpassing waar nodig tijdens het project. Sleutelen aan requirements en aan het proces dat deze requirements oplevert, is een zaak van overleg, aangezien requirements een centrale rol spelen binnen het project en alle betrokkenen raakt.

1. Definieer visie en scope 2. Identificeer gebruikerscategorieën, vertegenwoordigers en beslissers 3. Selecteer technieken 4. Identificeer en prioriteer use cases

5. Ontwikkel use cases 6. Specificeer kwaliteitsattributen 7. Extraheer en documenteer functionele requirements 8. Modelleer de requirements 9. Review de requirementsspecificatie 10. Ontwikkel prototypes 11. Ontwikkel of verbeter architectuur 12. Koppel requirements aan componenten 13. Ontwikkel testgevallen 14. Valideer use cases, functionele requirements, analyse modellen en prototypen

Herhaal bij volgende incrementen

Figuur B1.1: Activiteiten in het requirements ontwikkelproces De eerste 4 stappen worden bij aanvang van het project eenmalig uitgevoerd. De verschillende stappen zijn ook te koppelen aan een bepaald niveau van requirements. Stap 1 legt typisch de focus op business requirements. De stappen 2 tot en met 5 richten zich vooral op het compleet in beeld brengen van alle gebruikers en de relevante eisen voor het kunnen uitvoeren van hun taken, oftewel de gebruikersrequirements. Stap 6 richt zich op niet-functionele requirements en requirements voortkomend uit business rules. Stap 7 vertaalt de gebruikersrequirements naar functionele requirements. Stap 8, 11 en 12 richten zich voornamelijk op het vaststellen van systeem requirements, externe interfaces en specifieke voorwaarden. Stap 1, definieer visie en scope, brengt het „waarom‟ van het te ontwikkelen systeem in beeld, ook wel uitgedrukt als DAT (datgene dat we met het systeem willen bereiken).

Almere © 2011

Proud of it



Pagina Versie Datum

17 van 19 1.3 16-03-2011

Stap 2, identificeer gebruikerscategorieën, vertegenwoordigers en beslissers, is erop gericht alle belanghebbenden van het systeem in beeld te brengen. Naast directe eindgebruikers bestaan bij vrijwel alle systemen ook andere systemen en de beheerrol als gebruikerscategorieën, die in de praktijk wel eens over het hoofd worden gezien. Denk bij „andere systemen‟ aan systemen waaraan het te ontwikkelen systeem informatie ontleent of aanlevert. Daarnaast maakt deze stap duidelijk op welke manier gebruikerscategorieën binnen het project vertegenwoordigd worden. Het is bij deze stap van belang alle gebruikerscategorieën aan een vertegenwoordiger te koppelen én bij de vertegenwoordiger duidelijk in beeld te brengen welke gebruikerscategorieën hij vertegenwoordigt. Daarnaast maakt stap 2 duidelijk wie met welke beslissingsbevoegdheid aan tafel zit. Dit is tevens het moment waarop voldoende beslissingsbevoegdheid van gebruikersvertegenwoordigers bewerkstelligd moet worden om de mogelijkheid tot snelle besluitvorming binnen het project te creëren. In stap 3, selecteer technieken, wordt bepaald met welke technieken requirements in beeld worden gebracht. Gangbare technieken hiervoor zijn: prototyping, het houden van interviews, het opstellen van scenario‟s, observeren en het organiseren van requirements workshops (ook wel „facilitated meetings‟ genoemd). Stap 4, identificeer en prioriteer use cases, geeft aan welke high level use cases voor het systeem bestaan. Afhankelijk van de te volgen ontwikkelmethodiek vindt daarna nog een prioriteitsbepaling van use cases plaats. Slechts weinig systemen van enige omvang kunnen in de praktijk „in één keer goed‟ en compleet worden ontworpen en gebouwd. Door middel van prioriteitsbepaling van use cases hoeven niet alle use cases in de zelfde mate van detail te zijn uitgewerkt op enig moment in het ontwikkeltraject. Het bepalen van prioriteiten helpt om de belangrijkste use cases als eerste uit te werken. De prioriteit hoeft hierbij niet alleen door organisatorisch of functioneel belang bepaald te zijn, maar kan ook worden beïnvloed door de mate waarin de uitwerking van een bepaalde use case voor het systeem technisch of qua architectuur bepalend is. Dit is meestal het geval als een nieuwe technische oplossingsrichting of architectuur wordt toegepast waarvoor nog geen „proof of concept‟ voorhanden is. Juist dan is het zaak deze onzekerheid in een vroegtijdig stadium binnen het project weg te nemen, óf te concluderen dat aan gestelde requirements (nog) niet kan worden voldaan. Stap 4 levert gewoonlijk het visie- of scopedocument, waarin de resultaten van alle voorgaande stappen transparant en eenduidig zijn vastgelegd. De eerste 4 beschreven stappen zijn vrijwel onafhankelijk van de organisatie, toegepaste ontwikkelmethodiek en gebruikte tools. De volgende stappen zijn qua invulling en volgorde niet uniform: de daadwerkelijke invulling kan sterk verschillen en de invulling zoals hieronder gegeven is een mogelijke invulling maar zeker niet de enige en enig goede. Stap 5, ontwikkel use cases, levert beschrijvingen van het systeem, vanuit het perspectief van de gebruiker(s) om een taak te kunnen uitvoeren: ”Wat doet het systeem voor mij, zodat ik mijn werk kan uitvoeren”. Voor het gemak is in deze stap de term use case als generieke term gebruikt voor iedere vorm van beschrijvingen van wisselwerking tussen gebruikers en het softwaresysteem. Een use case bestaat hoofdzakelijk uit een tekstuele specificatie met een stap voor stap beschrijving (stroomdiagram) van interactie tussen gebruikers en het systeem. De beschrijving bevat ook precondities en postcondities en scenario‟s die in de praktijk zullen voorkomen. Eventueel kunnen use cases vastgelegd worden in standaard modelleer talen (UML: Unified Modeling Language) of tools. Naast het geven van een stap voor stap beschrijving hoe volgens de normale manier gewerkt zou moeten worden (ook wel betiteld als „happy cases‟) dient ook te worden bekeken op welke manier het softwaresysteem en gebruiker samen moeten werken als stappen niet gaan zoals idealiter voorgesteld (ook wel de „unhappy cases‟ genaamd). Van belang is vooraf goed te bepalen tot in welke mate van detail use cases worden uitgewerkt. Besloten kan worden bepaalde use cases pas in een latere projectfase of zelfs in het geheel niet in detail uit te werken. Dit is vooral afhankelijk van omvang en risico‟s van het project, de impact van het ontwerpen en ontwikkelen van een specifieke use case op het totale ontwerp, de impact van de specifieke use case binnen het straks operationele systeem, beschikbare kennis en eventueel beschikbare tooling.

Almere © 2011

Proud of it



Pagina Versie Datum

18 van 19 1.3 16-03-2011

Stap 6, specificeer kwaliteitsattributen, zorgt ervoor dat naast de functionele requirements ook aan de belangrijkste niet-functionele requirements wordt gedacht en dat eisen meetbaar zijn vastgelegd. Een goed hulpmiddel voor het onderkennen en selecteren van de voor het project specifiek van toepassing zijnde kwaliteitsattributen vormt de ISO 9126. Hierin zijn onder meer zaken als performance, onderhoudbaarheid, beveiligbaarheid, aanpasbaarheid en analyseerbaarheid benoemd. Stap 7, extraheer en documenteer functionele requirements, omvat het vertalen van use cases naar concreet functioneel gedrag van het softwaresysteem. Stap 8, modelleer de requirements, is het rangschikken van requirements naar type requirement en het aanbrengen van onderlinge relaties en het overzichtelijk en gestructureerd vastleggen ervan voor verder gebruik in het project. Stap 9, review de requirementsspecificatie, kan bijvoorbeeld door middel van een structured walkthrough, een collegiale review of een inspectie. Doel van de review is herstelwerkzaamheden te minimaliseren door fouten zo vroeg mogelijk in het software ontwikkeltraject te verwijderen. Stap 10, ontwikkel prototypes, is vooral van toepassing op dié onderdelen van het systeem waar (technisch) nog weinig praktijkkennis of ervaring mee is, of waar de gebruiker zich moeilijk een voorstelling van kan maken. In het bijzonder schermprototypes zijn vaak eenvoudig te maken en helpen toekomstige gebruikers een betere voorstelling te maken van de uiteindelijke interactie met en werking van het systeem. Op basis van prototypes kunnen toekomstige gebruikers input leveren en de requirements bijstellen en detailleren. Tijdens deze stap dient de focus op het verkrijgen van de juiste requirements te zijn; het daadwerkelijke ontwerpproces vindt pas na vaststelling van de requirements plaats. Hetzelfde geldt voor de bouw van prototypes of van een „proof of concept‟. Het lijkt voor de hand liggend en efficiënt om prototypes direct al in de praktijk bruikbaar te maken zodat hergebruik tijdens bouw kan plaatsvinden. Echter, in de praktijk veranderen eisen en ontwerpen tussen de start van requirementsontwikkeling en daadwerkelijke realisatie van het systeemdeel nog zo dat de kans op daadwerkelijk kunnen hergebruiken van onderdelen vanuit prototypes minimaal is. Accepteren van het feit dat prototypes per definitie niet worden hergebruikt tijdens het bouwtraject draagt bij tot efficiënt en snel opleveren van prototypes. De focus van het maken van het prototype ligt daarbij op het te verkrijgen of te verhelderen requirement. Stap 11, ontwikkel of verbeter architectuur, kan al onderdeel zijn van de review. De stap is vooral genoemd voor nieuwe systemen of grote aanpassingen, omdat ontwikkelen onder architectuur enerzijds het voldoen aan kwaliteitseisen in het kader van beveiligbaarheid, portabiliteit, aanpasbaarheid en onderhoudbaarheid kan bevorderen maar vaak een negatieve impact heeft op bijvoorbeeld performance. Door de architectuur, het fundament van het te ontwikkelen systeem, nu met alle requirements in beeld wederom tegen het licht te houden zijn essentiële architectuuraanpassingen nog met relatief weinig inspanning door te voeren. Stap 12, koppel requirements aan componenten, bevindt zich op het snijvlak tussen requirementsontwikkeling en ontwerpen. In deze stap wordt het systeem waar nodig verder verdeeld in subsystemen en componenten. Vervolgens worden requirements gekoppeld aan de componenten zodat helder is aan welke eisen ieder individueel component moet voldoen. Vanuit de requirements beredeneerd is te zien welke componenten gaan zorgdragen voor implementatie van het betreffende requirement. Ieder functioneel requirement dient aan minimaal één component te zijn gekoppeld: functionele requirements die niet te koppelen zijn duiden op ontwikkeling van een incompleet systeem. Componenten die echter niet te koppelen zijn aan een requirement duiden op het zogenaamd „gold plating‟ of meer ontwikkelen dan de klant vraagt. Tijdens deze stap dient de focus nog op de requirements te zijn; het daadwerkelijke ontwerpproces vindt pas na de requirements ontwikkelfase plaats. Stap 13, ontwikkel testgevallen, lijkt wellicht te vroeg. Het ontwikkelen van testgevallen leidt juist tot het meer concreet en meetbaar maken van de requirements. In de praktijk blijkt dat daarvoor vaak een grondiger verdieping vereist is van datgene waartoe het requirement eigenlijk zou moeten leiden. Ten gevolge hiervan worden requirements dikwijls nog in deze fase scherper gesteld en herzien.

Almere © 2011

Proud of it



Pagina Versie Datum

19 van 19 1.3 16-03-2011

Stap 14, valideer use cases, functionele requirements, analysemodellen en prototypen, zorgt ervoor dat alle requirements en alle vastlegging ervan wordt beoordeeld op „fit for use‟, oftewel gaat een systeem dat op basis van deze requirements wordt ontwikkeld straks in de praktijk ook werken. Gedurende alle voorliggende stappen zijn de requirements SMART gemaakt. Met name de prototypes en de beschreven testgevallen dragen ertoe bij dat deze beoordeling op „fit for use‟ goed kan plaatsvinden. Expliciete uitvoering van een validatiestap verhoogt de kans op succes van het project enorm en kan de exploitatiekosten van het opgeleverde systeem drastisch verlagen. Pas als de validatiestap is uitgevoerd voor enig deel van de requirements kan worden gestart met het ontwerp en de daadwerkelijke bouw van dat betreffende systeemdeel. Bij toepassing van de watervalmethode als ontwikkelmethodiek dient validatie van requirements eerst in zijn geheel te zijn afgerond, voordat kan worden gestart met de ontwerpfase.

Almere © 2011

Proud of it

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

Recommend Documents