Requirements. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.
|
|
- Petra Jansen
- 2 jaren geleden
- Aantal bezoeken:
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
Handout. Hoe testers de kwaliteit van requirements kunnen beïnvloeden. Slechte requirements zijn overal. Testnet thema-avond Requirements.
Hoe testers de kwaliteit van requirements kunnen beïnvloeden Testnet thema-avond Slechte requirements zijn overal 2 Pagina 1 En dan heb je goede requirements 3 proces proces ontwikkeling validatie management
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
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;
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
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
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...
Johan Zandhuis Boek: Succes met de requirements! Voorjaarsevent Testnet: 22 juni 2009
Titel, samenvatting en biografie Samenvatting: Boek: Succes met de! Voorjaarsevent Testnet: 22 juni 2009 Waarom nog een boek over, ik heb al een boek. In het boektrack Succes met de! gaat een van de auteurs
Vereenvoudigd sjabloon requirementsdocument. <>
Vereenvoudigd sjabloon requirementsdocument SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van
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
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.
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
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
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
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
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
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
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...
Checklist Slimme vragenlijst regievoering
Checklist Slimme vragenlijst regievoering versie 2.0 Slimme vragenlijst Leveranciersselectie Hoe stel ik vast dat dit beste leverancier is? Welke criteria hanteer ik daarbij? Wat als het selectieproces
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
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...
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...
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
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
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...
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...
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
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
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
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.
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Een duivelse samenwerking (Projectmanagement vs. Testmanagement) Albrie Beemer & Erik Bits 18 april 2012
Een duivelse samenwerking (Projectmanagement vs. Testmanagement) Albrie Beemer & Erik Bits 18 april 2012 Het duivelsvierkant Agenda Introductie 19.00u 19.10u Klassiek Projectmanagement: Prince 2 Testmanagement:
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
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.
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
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
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.
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
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
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
Business Case. <>
Business Case SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Pagina 2 van 8 Inhoudsopgave 1 Inleiding... 1.1 Doel van dit document...
Review op uitgevoerde risico-inventarisatie implementatie resultaatgerichte bekostiging
Review op uitgevoerde risico-inventarisatie implementatie resultaatgerichte bekostiging mr. drs. E.P.J. de Boer Rotterdam, Aanleiding en opzet van de review In opdracht van de GR Jeugdhulp Rijnmond is
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
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
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
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
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
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
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
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
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
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
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.
1. Work Breakdown Structure en WBS Dictionary
1. Work Breakdown Structure en WBS Dictionary CUSTOMER migratie Management Technische Transitie Meetings Status Reporting Administratie Technisch Upgegrade Systemen (3-tier) Delta Analyse & Functioneel
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
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
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
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
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...
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
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
De goede requirements goed bij Philips Handheld Diagnostics Venture
De goede requirements goed bij Philips Handheld Diagnostics Venture Een groeipad voor het professionaliseren van werken met requirements Edwin Schumacher Managing partner Synergio B.V. e.schumacher@synergio.nl
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
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
SPC360: specificeren, programmeren en contracteren. SPC360 en AT Osborne 2016 Q1
SPC360: specificeren, programmeren en contracteren Andere contractvormen In de utiliteitsbouw worden steeds vaker andere contractvormen toegepast. Het zijn tools die hun oorsprong vinden in de wereld van
Functiepuntanalyse. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.
Functiepuntanalyse 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 2 WAT
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
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
Testrisicoanalyse. Introductie
7 Testrisicoanalyse 7.1 Introductie Veel testtrajecten zijn tegenwoordig gebaseerd op risico s. Bij risicogebaseerd testen (RBT) bepaalt het risico dat de organisatie loopt als het systeem in gebruik wordt
Project Portfolio Management. Doing enough of the right things
Project Portfolio Management Doing enough of the right things BPUG, Hilversum, 24 juni, 2015 Inhoud 1 2 3 4 Introductie Het belang van portfolio management Project portfolio management volgens MoP 3a 3b
Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting
xvii Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting Samenvatting IT uitbesteding doet er niet toe vanuit het perspectief aansluiting tussen bedrijfsvoering en IT Dit proefschrift is het
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
Business Impact Anlayses worden in de meeste organisaties eens per jaar of eens per halfjaar geactualiseerd en bevatten meestal beschrijvingen van:
(BIA s) Veel organisaties beschikken over BIA s ofwel Business Impact Analyses per Business Unit of per Afdeling. Hierna gaan we verder uit van Business Impact Analyses op Business Unit niveau. Dit artikel
Praktijkervaring met een business rules aanpak: impact op de organisatie
Praktijkervaring met een business rules aanpak: impact op de organisatie Tim Verwaart, 22 september 2010 Het LEI Onderdeel van Wageningen UR Gevestigd in den Haag ontwikkelt voor overheid en bedrijfsleven
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
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
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
KIM. Slimme acties ondernemen
KIM Slimme acties ondernemen CONTROLE KWIJT? Herkent u dit soort ervaringen ook? Uw organisatie heeft allerlei systemen in huis, maar Niemand weet echt meer hoe het systeem exact werkt Voor kleine wijzigingen
De brug tussen requirement engineer en gebruiker
De brug tussen requirement engineer en gebruiker Gerlof Hoekstra Even kennismaken Senior testconsultant / product manager In de ICT sinds 1985 Sinds 1993 testen/kwaliteitszorg Opdrachtgevers Postbank KPN
Medical device software
Medical device software Medical device software Software ontwikkeling voor de medische wereld Nspyre Herculesplein 24 3584 AA Utrecht T 088-827 50 00 F 088-827 50 99 www.nspyre.nl Medical devices zijn
Project methodiek. Auxilium BV Oude Delft 48 2611 CD Delft. T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl
Project methodiek Auxilium BV Oude Delft 48 2611 CD Delft T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl Inhoud 1 PROJECTMETHODIEK... 3 1.1 TIME-BOXING... 3 1.2 USER-STORIES EN STORY-POINTS... 3
De controller met ICT competenties
De controller met ICT competenties Whitepaper door Rob Berkhof Aangeboden door NIVE Opleidingen De controller met ICT competenties De huidige samenleving is nauwelijks meer voor te stellen zonder informatisering.
Bijlage 3: Master testplan
Bijlage 3: Master testplan KIS Testplan Inaxion Lelystad Adres: Jol -20 Postbus : 609 Postcode Plaats 8483 ED Lelystad I www.inaxion.nl Plaats Lelystad Datum 22 maart 200 Auteur Saidou Diallo Status Finaal.0
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...
Standaard Plan van Aanpak
Standaard Plan van Aanpak ZBC Consultants bv 27 september 2000 Inhoudsopgave 0. Management samenvatting... 4 1. Introductie... 4 1.1 Aanleiding... 4 1.2 Accordering en bijstelling... 4 1.3 Toelichting
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