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

Maat: px
Weergave met pagina beginnen:

Download "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

2.F.12 CHECKLIST REQUIREMENTS ENGINEERING DOEL

2.F.12 CHECKLIST REQUIREMENTS ENGINEERING DOEL 2.F.12 CHECKLIST REQUIREMENTS ENGINEERING DOEL Het doel van deze checklist is het bepalen van de sterke en zwakke punten van de huidige werkwijze ten aanzien van requirements engineering. Met behulp van

Nadere informatie

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

Requirements en testen. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Requirements en testen Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Unified Process... 4 3. Fasering... 5 3.1.

Nadere informatie

Vereenvoudigd sjabloon requirementsdocument. <>

Vereenvoudigd sjabloon requirementsdocument. <<Organisatie>> Vereenvoudigd sjabloon requirementsdocument SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van

Nadere informatie

Ontwikkelen en testen van e-business: beheerste dynamiek

Ontwikkelen en testen van e-business: beheerste dynamiek Ontwikkelen en testen van e-business: beheerste dynamiek Het ontwikkelen en gestructureerd testen van administratieve systemen is gebaseerd het watervalprincipe. Bij het ontwikkelen volgens het watervalprincipe

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

Outsourcing zorgt voor betere requirements

Outsourcing zorgt voor betere requirements outsourcing t We moeten wel! Outsourcing zorgt voor betere requirements In veel organisaties is sprake van gebrekkige requirements en requirementsprocessen. Outsourcing lijkt dan geen goed idee. Outsourcing

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

notitie Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen Definitief; vastgesteld Stuurgroep 4P

notitie Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen Definitief; vastgesteld Stuurgroep 4P notitie Van project onderwerp opgemaakt door Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen status datum opmaak 20-7-2012 bijlagen Definitief; vastgesteld Stuurgroep 4P

Nadere informatie

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen.

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. ERP, CRM, workflowmanagement en documentmanagement systemen, ze hebben één ding gemeen: Veel van de

Nadere informatie

Scrum. Een introductie

Scrum. Een introductie Organisatie SYSQA B.V. Pagina 1 van 10 Scrum Een introductie Almere 1999 Proud of it Pagina 1 van 10 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Inleiding... 3 2 Scrum... 4 3 Scrum rollen...

Nadere informatie

Risk & Requirements Based Testing

Risk & Requirements Based Testing Risk & Requirements Based Testing Tycho Schmidt PreSales Consultant, HP 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda Introductie

Nadere informatie

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept.

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. 1. 1.1. Inleiding Doel De Requirementdiscipline richt zich op het vaststellen en vastleggen van de eisen en wensen die aan een oplossing worden gesteld: de requirements. Rollen De keyrol binnen deze discipline

Nadere informatie

HERGEBRUIK VAN REQUIREMENTS

HERGEBRUIK VAN REQUIREMENTS HERGEBRUIK VAN REQUIREMENTS EEN PRAKTISCHE AANPAK BUSINESS ANALYSE CENTER OF EXCELLENCE - SYNERGIO Inhoudsopgave 1 HERGEBRUIK VAN REQUIREMENTS... 3 1.1 GEBRUIKEN VERSUS HERGEBRUIKEN... 4 2 STRATEGIE...

Nadere informatie

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RAD Rapid application development Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

Het W-model: de groei naar voren. Jan Jaap Cannegieter. Praktijk van ICT-projecten

Het W-model: de groei naar voren. Jan Jaap Cannegieter. Praktijk van ICT-projecten Het W-model: de groei naar voren Jan Jaap Cannegieter Adjunct Directeur SYSQA B.V. Praktijk van ICT-projecten Req Ontwerp Realisatie Testen Testen Testen 44% van de projecten overschrijdt budget of tijd

Nadere informatie

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

Nadere informatie

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol. Datum: dd-mm-jj

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol. Datum: dd-mm-jj BUSINESS CASE: Versie Naam opdrachtgever Naam opsteller Datum: dd-mm-jj Voor akkoord: Datum: LET OP: De bedragen in deze business case zijn schattingen op grond van de nu beschikbare kennis en feiten.

Nadere informatie

Informatiebeveiliging voor de requirementsanalist

Informatiebeveiliging voor de requirementsanalist voor de requirementsanalist SYSQA B.V. Almere Datum : 15 april 2013 Versie : 1.0 Status : Definitief Opgesteld door : Organisatie: SYSQA BV Pagina 2 van 11 Inhoudsopgave Inhoudsopgave... 2 1 Inleiding...

Nadere informatie

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. ISO 9000:2000 en ISO 9001:2000 Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 11 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

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

Balanced Scorecard. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Balanced Scorecard Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DE

Nadere informatie

Software Engineering (I00094) College 3:

Software Engineering (I00094) College 3: Software Engineering (I00094) College 3: Kwaliteit, organisatie en documentatie Marko van Eekelen marko@cs.ru.nl kamer HG02.074 1 Huidige planning 1. 6 feb: Het systeemontwikkelproces 2. 13 feb: Requirements-analyse

Nadere informatie

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

Nadere informatie

ISACA round-table 7 december 2009 Rik Marselis

ISACA round-table 7 december 2009 Rik Marselis ISACA round-table 7 december 2009 Rik Marselis Senior Testconsultant bij Sogeti Penningmeester van BNTQB, de member board voor België en Nederland van de International Software Testing Qualifications Board

Nadere informatie

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA.

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven Johan Zandhuis SYSQA Start: 1999 Onafhankelijk Quality Assurance in IT 150 medewerkers (en groeiend) 2 SYSQA Operationeel

Nadere informatie

Software Engineering (I00094) College 2: Requirements-engineering. Marko van Eekelen marko@cs.ru.nl kamer HG02.074

Software Engineering (I00094) College 2: Requirements-engineering. Marko van Eekelen marko@cs.ru.nl kamer HG02.074 Software Engineering (I00094) College 2: Requirements-engineering Marko van Eekelen marko@cs.ru.nl kamer HG02.074 1 Inhoud 1. 6 feb: Het systeemontwikkelproces 2. 13 feb: Requirements-analyse 3. 6 mar:

Nadere informatie

Testen en Requirements lifecycle management 1 + 1 = 3

Testen en Requirements lifecycle management 1 + 1 = 3 Teste e Requiremets lifecycle maagemet 1 + 1 = 3 Mark Paap TestNet, 9 jui 2004 Ageda Aaleidig Itro Requiremets lifecycle maagemet RLcM e (Busiess drive) Teste 1+1=3 Sogeti Nederlad B.V. Pagia 1 Aaleidig

Nadere informatie

Ontwikkelaar ICT. Context. Doel

Ontwikkelaar ICT. Context. Doel Ontwikkelaar ICT Doel Ontwikkelen en ontwerpen van ICT-producten, binnen overeen te komen dan wel in een projectplan vastgelegde afspraken ten aanzien van tijd, budget en kwaliteit, opdat overeenkomstig

Nadere informatie

Oplossingsvrij specificeren

Oplossingsvrij specificeren Oplossingsvrij specificeren ir. J.P. Eelants, projectmanager Infrabouwproces CROW Samenvatting De methodiek van oplossingsvrij specificeren richt zich niet alleen op het formuleren van functionele eisen.

Nadere informatie

Reviewtypen en reviewplanning. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Reviewtypen en reviewplanning. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Reviewtypen en reviewplanning Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 INLEIDING ALGEMEEN... 3 1.2 INTRODUCTIE

Nadere informatie

Het BiSL-model. Een whitepaper van The Lifecycle Company

Het BiSL-model. Een whitepaper van The Lifecycle Company Het BiSL-model Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht op hooflijnen van het BiSL-model. U vindt een overzicht van de processen en per proces een beknopte

Nadere informatie

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter 2 Opdrachtgever : Opdrachtnemers : Ing. P. van den Berg Michel van Reenen Thijs Mommen GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

Nadere informatie

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V.

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V. Regressietesten De aanpak en aandachtspunten Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING...3 1.1 ALGEMEEN...3 1.2 VERSIEBEHEER...3

Nadere informatie

Ant: B Dit is het doel van het proces.

Ant: B Dit is het doel van het proces. In welk proces vormt het voor aanpassingen in de informatievoorziening beschikbaar gestelde budget een mandaat voor besluitvorming? A: Contractmanagement B: Financieel management C: Transitie D: Wijzigingenbeheer

Nadere informatie

Methodiek. Versie: 16/05/2012 13:42:35

Methodiek. Versie: 16/05/2012 13:42:35 Methodiek Versie: 16/05/2012 13:42:35 Inhoudsopgave Methodiek... 2 Onze visie op het functioneel ontwerp... 2 Stappen in het ontwerpproces... 3 Methodiek Inleiding In dit deel van de encyclopedie wordt

Nadere informatie

ORGANISATORISCHE IMPLENTATIE BEST VALUE

ORGANISATORISCHE IMPLENTATIE BEST VALUE ORGANISATORISCHE IMPLENTATIE BEST VALUE EEN ONDERZOEK NAAR DE IMPLEMENTATIE VAN BEST VALUE BINNEN EEN SYSTEMS ENGINEERING OMGEVING STEPHANIE SAMSON BEST VALUE KENNIS SESSIE WESTRAVEN 17 JUNI 09.00 12.00

Nadere informatie

De juiste requirements juist

De juiste requirements juist De juiste requirements juist Een voorwaarde voor succesvolle applicatie ontwikkeling Arno van Herk Managing partner Synergio B.V. a.van.herk@synergio.nl 2011 Een brug naar onze presentatie Uniface is Compuware's

Nadere informatie

Portal Planning Process

Portal Planning Process BROCHURE Portal Planning Process SAMENWERKEN AAN EEN WAARDEVOL PORTAAL BROCHURE PORTAL PLANNING PROCESS 2 Axians PORTAL PLANNING PROCESS BROCHURE Inhoud Introductie 4 3 Portal Planning Process 5 4 Uitdagingen

Nadere informatie

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Extended ISO 9126: 2001 Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technisch systemen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Systeem categoriën Technische op computer gesteunde systemen Systemen die HW en SW bevatten, maar waar

Nadere informatie

Ordening van processen in een ziekenhuis

Ordening van processen in een ziekenhuis 4 Ordening van processen in een ziekenhuis Inhoudsopgave Inhoud 4 1. Inleiding 6 2. Verantwoording 8 3. Ordening principes 10 3.0 Inleiding 10 3.1 Patiëntproces 11 3.2 Patiënt subproces 13 3.3 Orderproces

Nadere informatie

SDM II - System Development Methodology II. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

SDM II - System Development Methodology II. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. SDM II - System Development Methodology II Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 12 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

PROJECT INITIATION DOCUMENT

PROJECT INITIATION DOCUMENT PROJECT INITIATION DOCUMENT Versie: Datum: x.x dd-mm-jj DOCUMENTATIE Versie Naam opdrachtgever Naam opsteller Datum: dd-mm-jj Voor akkoord: Datum:. INHOUDSOPGAVE 1. Managementsamenvatting

Nadere informatie

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman Requirements Traceability Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman 22 Mei 2008 Werkgroep Traceability Doel van de werkgroep: Aanbieden van hulpmiddelen

Nadere informatie

Wij testen..maar....wat test jij?

Wij testen..maar....wat test jij? Wij testen..maar....wat test jij? Wij testen maar wat test jij? Harm Pul, Busineslinemanager Functioneel Beheer TMAP dag 2015, 29 september 2015 Bussum 2 Herkent u dit? De gebruikers testen dit straks

Nadere informatie

Professionalisering van Levensduurverlenging

Professionalisering van Levensduurverlenging Professionalisering van Levensduurverlenging De toegevoegde waarde van VITALE Rob van Dongen 9 februari 2012 Agenda 1 2 3 4 Levensduurverlenging volgens VITALE Het referentiemodel Toepasbaarheid VITALE

Nadere informatie

ABN AMRO Verzekeringen Project: Documentbeheer Verzekeringen

ABN AMRO Verzekeringen Project: Documentbeheer Verzekeringen Opdrachtformulering Het in kaart brengen van de structuur achter verzekeringsdocumenten met het doel deze op een efficiënte manier productief te maken in een daarvoor te realiseren tool. De applicatie

Nadere informatie

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld.

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld. 1. 1.1. Inleiding Doel In de discipline vindt de validatie van datgene wat binnen het project is gerealiseerd plaats. Dit bestrijkt het gebied van unittest tot en met acceptatie door gebruikers en beheerorganisatie.

Nadere informatie

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Martin van Leeuwen Happy Testing

Martin van Leeuwen Happy Testing Titel, samenvatting en biografie Samenvatting: Deze presentatie beschrijft een aantal test maatregelen die in een RUP nieuwbouw project zijn genomen, om ervoor te zorgen dat het testen aan het eind van

Nadere informatie

READ: de informatiestrategieaanpak van Steenwinkel Kruithof Associates (SKA)

READ: de informatiestrategieaanpak van Steenwinkel Kruithof Associates (SKA) READ: de informatiestrategieaanpak van (SKA) INLEIDING HET SPANNINGSVELD TUSSEN KORTETERMIJNVERWACHTINGEN EN LANGETERMIJNBEHOEFTEN In veel bedrijven volgen businessgerelateerde veranderingen elkaar snel

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

CMMI voor acquisitie

CMMI voor acquisitie softwareontwikkeling CMMI i CMMI voor acquisitie Volwassen heidsmodel garandeert goed opdrachtgeverschap Tot voor kort was er geen methodische aanpak om outsourcingprocessen in de praktijk op een gestructureerde

Nadere informatie

Projectmanagement De rol van een stuurgroep

Projectmanagement De rol van een stuurgroep Projectmanagement De rol van een stuurgroep Inleiding Projecten worden veelal gekenmerkt door een relatief standaard projectstructuur van een stuurgroep, projectgroep en enkele werkgroepen. De stuurgroep

Nadere informatie

Procesvalidatie voor een veiliger ketentest

Procesvalidatie voor een veiliger ketentest Procesvalidatie voor een veiliger ketentest Johan Vink TestNet Voorjaarsevenement 2010 Agenda Inleiding Typering project & testaanpak Werkwijze business proces Probleem De opdracht voor het testteam Probleemanalyse

Nadere informatie

Functioneel ontwerp. Een introductie. Algemene informative voor medewerkers van SYSQA B.V. Almere

Functioneel ontwerp. Een introductie. Algemene informative voor medewerkers van SYSQA B.V. Almere Functioneel ontwerp Een introductie Algemene informative voor medewerkers van SYSQA B.V. Almere Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding... 3 1.1 Algemeen... 3 2 Inleiding... 4 2.1

Nadere informatie

Testen kost te veel tijd

Testen kost te veel tijd Testen kost te veel tijd De oplevering van een nieuwe ICT applicatie betekent in de praktijk voor de opdrachtgever nog geen reden voor een feest. Vaak blijkt het product in onvoldoende mate te voldoen

Nadere informatie

5 Opstellen businesscase

5 Opstellen businesscase 5 Opstellen In de voorgaande stappen is een duidelijk beeld verkregen van het beoogde project en de te realiseren baten. De batenboom geeft de beoogde baten in samenhang weer en laat in één oogopslag zien

Nadere informatie

ISO 20000 @ CTG Europe

ISO 20000 @ CTG Europe ISO 20000 @ CTG Europe 31/10/2007 mieke.roelens@ctg.com +32 496266725 1 Agenda 31 oktober 2007 Voorstelling Project Business Case: Doel & Scope Projectorganisatie Resultaten assessments en conclusies De

Nadere informatie

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

CMMI voor ontwikkeling. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. CMMI voor ontwikkeling Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 12 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

Rapport over het werkprofiel van Software engineer (sr)

Rapport over het werkprofiel van Software engineer (sr) Rapport over het werkprofiel van Software engineer (sr) Identificatienummer: Publicatiedatum: 19 november 2015 Leeswijzer Dit rapport omschrijft het werkprofiel van 'Software engineer (sr)' zoals die door

Nadere informatie

PRINCE2 2009 is overzichtelijker

PRINCE2 2009 is overzichtelijker PRINCE2 2009 is overzichtelijker 29 mei 2009 door: Lia de Zoete en Reinier de Koning Half juni presenteert het Office of Government Commerce in Londen PRINCE2 2009. Het grote voordeel van de nieuwe versie

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

PRINCE2 Symposium: Zin en Onzin van een Methode. PRINCE 2 versus CMMI; raakvlakken, overlap en aanvullingen SYSQA B.V.

PRINCE2 Symposium: Zin en Onzin van een Methode. PRINCE 2 versus CMMI; raakvlakken, overlap en aanvullingen SYSQA B.V. PRINCE2 Symposium: PRINCE 2 versus CMMI; raakvlakken, overlap en aanvullingen Jan Jaap Cannegieter SYSQA B.V. SYSQA B.V. Operationeel Tactisch Strategisch Testen Requirements Quality assurance Auditing

Nadere informatie

Checklist risicofactoren IT-projecten

Checklist risicofactoren IT-projecten Organisatie SYSQA B.V. Pagina 1 van 5 Checklist risicofactoren IT-projecten In onderstaande checklists zijn de factoren die het slagen van een project beïnvloeden opgenomen. Projectomvang Hoe groot is

Nadere informatie

Titel, samenvatting en biografie

Titel, samenvatting en biografie Titel, samenvatting en biografie \ Peter Wanders De Black Box Dialog methode Voorjaarsevent Testnet: 22 juni 2009 Samenvatting Nog nooit heb ik heb een klant horen zeggen: Enorm vervelend dat het IT project

Nadere informatie

QSM Benchmark Project ABC

QSM Benchmark Project ABC QSM Benchmark De intelligentie Voor u ligt de QSM benchmarkrapportage over. Deze rapportage geeft antwoord op de vraag of dit project marktconform is uitgevoerd in vergelijking met projecten in bedrijfsomgevingen

Nadere informatie

Goed functioneel beheer noodzaak voor effectievere SPI

Goed functioneel beheer noodzaak voor effectievere SPI getronicspinkroccade.nl Goed functioneel beheer noodzaak voor effectievere SPI Machteld Meijer Zeist, 3 oktober 2006 Inhoud Domeinen en modellen Functioneel beheer en BiSL Rol van BiSL in SPI 1 Goed functioneel

Nadere informatie

Agile in Projecten minimalisme of strak pak? Richard Weber PMP

Agile in Projecten minimalisme of strak pak? Richard Weber PMP Agile in Projecten minimalisme of strak pak? Richard Weber PMP De Spreker Richard Weber Directeur & oprichter Adviseur & coach Projectmanagement Profile Dynamics ICT & Bedrijfskundige achtergrond Trainer

Nadere informatie

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Data Warehouse Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DOEL VAN

Nadere informatie

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

Nadere informatie

Benefits Management. Continue verbetering van bedrijfsprestaties

Benefits Management. Continue verbetering van bedrijfsprestaties Benefits Management Continue verbetering van bedrijfsprestaties Agenda Logica 2010. All rights reserved No. 2 Mind mapping Logica 2010. All rights reserved No. 3 Opdracht Maak een Mindmap voor Kennis Management

Nadere informatie

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International Succes = x Visie x Draagvlak 2 Case: Implementatie Requirements Lifecycle management bij Rabobank International dinsdag 3 oktober 2006 Spider Congres Agenda Inventarisatie SPI-knelpunten Implementatie

Nadere informatie

Procesmanagement. Waarom processen beschrijven. Algra Consult

Procesmanagement. Waarom processen beschrijven. Algra Consult Procesmanagement Waarom processen beschrijven Algra Consult Datum: 22 oktober 2009 Inhoudsopgave 1. INLEIDING... 3 2. WAAROM PROCESMANAGEMENT?... 3 3. WAAROM PROCESSEN BESCHRIJVEN?... 3 4. PROCESASPECTEN...

Nadere informatie

Business Case. <>

Business Case. <<Naam project>> Business Case SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Pagina 2 van 8 Inhoudsopgave 1 Inleiding... 1.1 Doel van dit document...

Nadere informatie

14-9-2015. Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling

14-9-2015. Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling Je kunt hier (optioneel) ook een gratis tool downloaden

Nadere informatie

BDD/Gherkin. Een introductie

BDD/Gherkin. Een introductie BDD/Gherkin Een introductie Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. BDD... 4 3. Gherkin... 5 4. BDD-Tools... 6 5. Voordelen... 7 6. Benodigde kennis en vaardigheden...

Nadere informatie

Checklist basisontwerp SDM II

Checklist basisontwerp SDM II Organisatie SYSQA B.V. Pagina 1 van 5 Checklist basisontwerp SDM II Documentatie. Zijn de uitgangspunten voor het basisontwerp Is een plan van aanpak Zijn er wijzigingen op het Software Quality Assurance

Nadere informatie

Trefdag ZORG. Meer resultaten. door strategische inzet. van middelen

Trefdag ZORG. Meer resultaten. door strategische inzet. van middelen Trefdag ZORG Meer resultaten door strategische inzet van middelen September 2013 Francis Manas fm@amelior.be Herkenbaar? Aantal projecten neemt toe Projecten zonder link met doelen organisatie: geen fit

Nadere informatie

Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten

Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten SYSQA B.V. Almere Datum : 06 mei 2013 Status : definitief Versie : 2.0 Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 5 Overzicht

Nadere informatie

V-model is anno 20NU

V-model is anno 20NU Het V-model is een modellering van een voortbrengingsproces, van wens tot en met een oplossing. Het wordt veel toegepast in de IT maar is niet alleen toepasbaar op IT projecten. Het V-model helpt inzicht

Nadere informatie

Ontwikkelmethoden en technieken DSDM POMT HC3

Ontwikkelmethoden en technieken DSDM POMT HC3 DSDM Ontwikkelmethoden en technieken DSDM POMT HC3 HC WG rollenspel praktijktoets 1 praktijktoets 2 praktijktoets 3 Mei week 1 week 2 week 3 Week 4 vakantie Inleiding Ontwikkel methodiek DSDM Technieken

Nadere informatie

Geef de titel van het wijzigingsverzoek zo kort mogelijk weer.

Geef de titel van het wijzigingsverzoek zo kort mogelijk weer. Naam indiener WIJZIGINGSVOORSTEL Nummer: xxx Datum: dd-mm-jj Status: stap 1, 2, 3, 4 of 5 Bedrijfsonderdeel/afdeling/ functie Naam projectmanager Naam wijzigingsbehandelaar (indien van toepassing) Het

Nadere informatie

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com Use-Case 2.0 Requirements Kenniscentrum 15 November 2012 Eric Lopes Cardozo elcardozo@ivarjacobson.com Agenda Use cases: Een korte geschiedenis Waarom nog steeds use cases gebruiken? Waarom Use-Case 2.0?

Nadere informatie

Competenties met indicatoren bachelor Civiele Techniek.

Competenties met indicatoren bachelor Civiele Techniek. Competenties met indicatoren bachelor Civiele Techniek. In de BEROEPSCOMPETENTIES CIVIELE TECHNIEK 1 2, zijn de specifieke beroepscompetenties geformuleerd overeenkomstig de indeling van het beroepenveld.

Nadere informatie

Het stuurmodel voor een opdrachtgever

Het stuurmodel voor een opdrachtgever Het stuurmodel voor een opdrachtgever Ir. Derk K. Kremer 1. Inleiding In één van mijn eerdere artikelen heb ik al aangegeven dat de rol van opdrachtgever op zich geen moeilijke rol is. Voor een ervaren

Nadere informatie

Agile bij grote administratieve systemen. Omgaan met requirements

Agile bij grote administratieve systemen. Omgaan met requirements Agile bij grote administratieve systemen Omgaan met requirements 1 Agenda Wat is een groot systeem? Aanpak van een groot systeem Agile alignment Agile en requirements (en architectuur) Agile en governance

Nadere informatie

Succes met de requirements!

Succes met de requirements! Succes met de requirements! derde herziene druk Ontwikkeling, validatie en beheer van requirements voor informatiesystemen Martin Arendsen, Jan Jaap Cannegieter, Arno Grund, Petra Heck, Serge de Klerk

Nadere informatie

Ontwikkeling informatiesysteem

Ontwikkeling informatiesysteem Ontwikkeling informatiesysteem Voorletters en naam: xxx Studentnummer: xxx Datum: 23 december 2013 Onderwijsinstelling: NCOI Opleidingsgroep Naam opleiding: Bachelor Bedrijfskundige Informatica Naam module:

Nadere informatie

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval.

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval. TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE Kwaliteit zonder gestructureerd testen is toeval Inhoudsopgave 1. Inleiding 2. De TMap methode 3. De fase Planning & Beheer 4. De fase testspecificatie 5. De

Nadere informatie

Optimaliseren afsluiten rapportage proces: juist nu!

Optimaliseren afsluiten rapportage proces: juist nu! 18 Optimaliseren afsluiten rapportage proces: juist nu! Belang van snelle en betrouwbare informatie groter dan ooit Drs. Wim Kouwenhoven en drs. Maarten van Delft Westerhof Drs. W.P. Kouwenhoven is manager

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn

Nadere informatie

Requirements Management

Requirements Management Requirements Management Grip op veranderingen Fotografie: Fons Brasser Accedis B.V. Bezoekadres Planetenweg 91 2132 HL Hoofddorp Postadres Postbus 175 2130 AD Hoofddorp Telefoon 023 562 75 55 Fax 023 557

Nadere informatie

Duurzaam Product. Ecodesign methode van Tischner

Duurzaam Product. Ecodesign methode van Tischner Ecodesign methode van Tischner Omschrijving Stappenplan voor het ontwerpen van milieuvriendelijke producten. Het stappenplan is gebaseerd op gangbare methoden voor productontwerpen. Gebruik Het stappenplan

Nadere informatie