• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Requirements
Requirements
Grip op requirements (boekentip)
Gepubliceerd in Requirements
E-mail Afdrukken

grip op requirements jan jaap cannegieter nicole de swart zandhuis

Grip op requirements
IREB foundation examenstof uitgelegd en praktisch gemaakt
Jan Jaap Cannegieter, Nicole de Swart, Johan Zandhuis

Bij Bol.com

 

Laatst aangepast op zaterdag, 20 februari 2016 19:33  
Requirements volgens Katarzyna Knot
Gepubliceerd in Requirements
E-mail Afdrukken

requirements boilerplate

Volgens Katarzyna Knot vormt een zgn. boilerplate een goede manier voor het duidelijk en eenduidig vastleggen van requirements. Een boilerplate is een semi-formele methode die je dwingt om requirements op een vaste, gestructureerde manier te beschrijven.

Het International Requirements Engineering Board (IREB) adviseert bovenstaande boilerplate voor het formuleren van requirements.  Een veel gebruikte boilerplate is het formuleren van een user story in termen van:

'Als een <type gebruiker> wil ik <iets doen> zodat ik <deze benefits haal>'

Bron: De manier om requirements goed te formuleren, Katarzyna Knot



Laatst aangepast op zondag, 28 januari 2018 09:06  
Business, user en system requirements
Gepubliceerd in Requirements
E-mail Afdrukken

requirements business user system oplossing

Bij het formuleren van een business requirement kan de onderstaande syntax worden gebruikt:

<bedrijf(sonderdeel)> heeft <doel>, daarvoor dient

<proces/systeem> de volgende <prestatie, eigenschappen> te leveren.

 

Bij het eliciteren van requirements is het zaak de behoeften van gebruikers te vertalen naar meetbare requirements:

 

requirements ctq needs drivers

Zie ook mijn slideshare-presentatie met de 2 bovenstaande afbeeldingen.

Laatst aangepast op zondag, 28 januari 2018 09:06  
Requirements volgens Aydinli, Hendriks & Zandvliet
Gepubliceerd in Requirements
E-mail Afdrukken

SMART requirements softwareontwikkeling

 

In het boek SMART Requirements 2.0 beschrijven Jasper Zandvliet, Ömer Aydinli en Edwin Hendriks hun visie waarmee ze vanuit hun SMART requirements-methode kijken naar softwareontwikkeling. :

De lussen in de bovenstaande afbeelding representeren de verschillende ontwikkelcycli van de softwareontwikeling. Volgens Aydinli, Hendriks & Zandvliet is het type softwareontwikkeling (waterval,iteratief, agile, enz.) is bepalend voor het aantal lussen dat doorlopen wordt en de 'omvang' van de lus(sen). De individuele stappen binnen de lussen zijn altijd hetzelfde, onafhankelijk van de gehanteerde aanpak. Hierbij kan de diepgang van de verschillende stapjes overigens wel variëren.

  1. Wens en elicitatie: softwareontwikkeling begint met de wens van de business. Je wilt software ontwikkelen die één op één overeenkomt met de wens van de business. Vaak is deze wens nog weinig concreet en zal deze tijdens 'elicitatie' tastbaar moeten worden gemaakt.

  2. Requirements: Aydinli, Hendriks & Zandvliet definiëren requirements als de eisen, wensen en voorwaarden waaraan een product of dienst (resultaat) of een proces of het te gebruiken systeem moeten voldoen. De requirements geven in de eerste plaats aan aan welke voorwaarden het te ontwikkelen resultaat moet voldoen. Naast de requirements voor het resultaat zijn er nog twee andere vormen van requirements: (i) requirements voor de manier waarop het proces om het resultaat te realiseren moet worden uitgevoerd, en (ii) requirements voor de (ICT-)systemen die gebruikt moeten worden.

  3. Specificaties: requirements worden verder gedetailleerd in specificaties. Deze beschrijven de manier waarop de requirements moeten worden vormgegeven en hoe zij worden doorgevoerd binnen de resultaten, processen en systemen.

  4. Proces: nadat de requirements helder zijn, is het zaak een proces te ontwerpen om het gewenste resultaat te bereiken. Dit proces is gebaseerd op zowel de specifaties van het resultaat als de aanvullende requirements die gaan over de manier waarop het proces moet worden uitgevoerd.

  5. Bouw/Test: wanneer de requirements en specificaties eenduidig zijn beschik je over alle benodigde informatie om aan de slag te gaan met het ontwikkelen en testen van de benodigde ICT-middelen.

  6. Acceptatie: de requirements zijn geëvalueerd en geaccordeerd door de business en vormen daarmee het 'contrat' op basis waarvan de oplossingen voor de business worden ontwikkeld. Acceptatie vindt plaats op basis van de door de business geaccordeerde requirements. Op deze manier fungeren de requirements als acceptatiecriteria.

  7. Software: na acceptatie van het resultaat, beschikt de business over software die gebruikt kan worden in de dagelijkse praktijk.

Bron: SMART Requirements 2.0, Jasper Zandvliet, Ömer Aydinli en Edwin Hendriks

Laatst aangepast op zondag, 28 januari 2018 09:08  
Requirements prioriteren met het Bulk en Gedonder-kwadrant
Gepubliceerd in Requirements
E-mail Afdrukken

bulk gedonder kwadrant prioriteren requirements

Volgens Basile Lemaire is het vaak lastig binnen projecten requirements goed te prioriteren. "Bestaande methodieken zijn omslachtig of onnodig complex. Een ander probleem is dat prioriteiten vaak worden bepaald vanuit een it-perspectief in plaats vanuit de bedrijfsvoering. Helaas komt het ook vaak voor dat degene die het hardste roept, bepaalt wat een ‘must’ is." Lemaire ontwikkelde een instrument voor het prioriteren van requirements: het Bulk & Gedonder kwadrant.

Omdat binnen business analyse de MoSCow-methodiek vaak gebruik wordt voor het prioriteren van requirements, gaat Lemaire uitgebreid in op de nadelen van deze methode. Voor wie MoSCow nog niet kent, het is een acroniem van vier categorieën waarin - in dit geval - requirements worden ingedeeld:

  1. Must have: requirement is noodzakelijk voor projectsucces.

  2. Should have: requirement is belangrijk maar minder tijdkritisch als de must-have, of er is een ‘workaround’ om in de werkpraktijk toch aan het requirement te kunnen voldoen.

  3. Could have: requirement is niet belangrijk voor projectsucces; mee te nemen als het weinig kost en wel veel oplevert.

  4. Won’t have: requirement draagt weinig bij aan projectsucces of is weinig rendabel en wordt in ieder geval niet nu geïmplementeerd.

Lemaire beoordeelt MoSCoW als een prima methode (eenvoudig, prioriteren vanuit bedrijfsvoering), maar onderkent drie mogelijke nadelen:

  1. Het is lastig te bepalen te bepalen in hoeverre een requirement bijdraagt aan succes. In de praktijk bestaat daarbij het risico dat het aan grootste deel van de requirements een must-have wordt toegekend; iedereen wil zeker stellen dat zijn wens wordt meegenomen.

  2. Risico van ‘trade-offs’ of compromissen: ik ga mee met jouw must-have voor dit requirement als jij meegaat met mijn must-have voor dat requirement.

  3. Risico dat de stakeholder die het hardst roept of het meeste macht uitoefent, bepaalt wat de must-haves zijn. De vraag is dan in hoeverre het gaat om bedrijfsbelangen of om zijn belangen.

Deze nadelen pleiten - aldus Lemaire - voor "een methodiek die vanuit de bedrijfsvoering op een eenvoudige, transparante manier kan prioriteren terwijl eventueel ‘machtsmisbruik’ wordt tegengegaan": het Bulk & Gedonder-kwadrant.

prioriteren requirements

Het Kwadrant gaat uit van afbreukrisico: wat zijn de consequenties wanneer er niet aan een requirement wordt voldaan? Per requirement wordt de prioriteit
bepaald. Het prioriteren geschiedt met stakeholders vanuit de bedrijfsvoering zoals klanten, gebruikers, proceseigenaren en functioneel beheerders. It-risico’s worden in principe als irrelevant beschouwd. Een risico is namelijk pas een risico als een bedrijfsproces in gevaar komt. Dat daar mogelijk een it-probleem
aan ten grondslag ligt, is belangrijk voor je implementatie en oplossing maar niet voor je prioritering.

De prioritering vindt plaats aan de hand van twee assen, de Bulk-as en de Gedonder-as. De Bulk-as: als aan dit requirement niet wordt voldaan, hebben daar (onacceptabel) veel eindgebruikers last van. De Gedonder-as: als aan dit requirement niet wordt voldaan, volgt escalatie (‘komt er gedonder van’).

Op basis van de twee assen kunnen vier kwadranten worden onderkend, die staan voor een prioriteit 1, prioriteit 2 of prioriteit 3:

  1. Prio 1: requirement moet correct geïmplementeerd en grondig getest zijn. Indien het (nog) niet correct geïmplementeerd, is de consequentie dat de volgende projectfase, of de in productiename, moet worden uitgesteldust have: requirement is noodzakelijk voor projectsucces.

  2. Prio 2: requirement moet in principe correct geïmplementeerd zijn. De opdrachtgever kan er bij tijdsdruk echter voor kiezen dat pas in een volgende projectfase of release aan het requirement moet zijn voldaan.

  3. Prio 3: requirement mag onder tijdsdruk of bij budgetbeperkingen sneuvelen; hier gaat men vanuit de bedrijfsvoering geen (serieuze) last van hebben.

Prioriteren volgens het Bulk en Gedonder-kwadrant heeft twee belangrijke voordelen. Allereerst zal een stakeholder, wanneer hij graag wil dat een requirement een hogere prioriteit krijgt, moeten kunnen aantonen dat, door niet te voldoen aan dat requirement, de gebruikerspopulatie er last van kan hebben of dat de zaak gaat escaleren. Aangeven dat iets een must is op basis van machtspositie of hard roepen, gaat nu niet op.

"Een ander voordeel is dat er geen reden is om over prioriteiten te onderhandelen en compromissen te sluiten; het is nu duidelijk waar de werkelijke risico’s liggen als het gaat om het behalen van succes. De ervaring leert dat stakeholders met elkaar goed in staat zijn te bepalen wanneer er sprake is van onacceptabel veel gebruikers op de Bulk-as. Tevens zijn ze in staat een hele reële inschatting te maken wanneer er sprake is van escalatie. Door het groepsproces ontstaat een open discussie over consequenties, projectdoelstellingen en het behalen van de business case."

Lemaire geeft aan dat de verdeling van de requirements over de drie verschillende prioriteiten vaak als volgt is: 50% van de requirements heeft prioriteit 2, prioriteit 1 en 3 geldt voor elk 25% van de requirements.

Bron: Bulk en Gedonder-kwadrant kan uitkomst bieden, Basile Lemaire, in: Computable 07/10/2011

Laatst aangepast op donderdag, 11 januari 2018 19:32  
9 signalen van slechte requirements
Gepubliceerd in Requirements
E-mail Afdrukken

signalen slechte requirements mirjam van den berg

Volgens Mirjam van den berg herken je slechte requirements aan de onderstaande signalen:

  1. Klagende business en ICT (business klaagt dat ICT niet levert wat ze willen. ICT klaagt dat business niet weet wat ze wil).

  2. Requirements geformuleerd als oneliners.

  3. Veelvuldig gebruik van (onverklaarde) vaktermen.

  4. Beschrijving van oplossing in plaats van gewenst resultaat.

  5. Woordgebruik laat ruimte voor aannames/interpretatie.

  6. Vooral aandacht voor wat het systeem moet doen (functionaliteit) en minder naar hoe goed het systeem iets moet doen (kwaliteit).

  7. Requirements laten zich moeilijk vertalen naar goede en meetbare testgevallen.

  8. Meervoudige verwachtingen gebundeld in één requirement (geven problemen bij scoping en testen).

  9. Géén (duidelijke) rangorde tussen requirements.

Bron: 10 signalen dat je te maken hebt met slechte requirements, Mirjam van den Berg

 

Laatst aangepast op zondag, 28 januari 2018 09:06  
Requirements volgens Giuseppe Delena
Gepubliceerd in Requirements
E-mail Afdrukken

canyon bridge giuseppe delena requirements

Laatst aangepast op zondag, 28 januari 2018 09:07  
Requirements engineering volgens Gottesdiener
Gepubliceerd in Requirements
E-mail Afdrukken

requirements engineering ellen gottesdiener

Ellen Gottesdiener definieert requirements engineering als een discipline binnen system en software engineering die alle activiteiten en deliverables omvat die horen bij het definiëren van producteisen. Requirements engineering bestaat uit twee onderdelen:

  1. Requirements development: activiteiten voor het eliciteren (elicit), analyseren (analyse), specificeren (specify) en valideren (validate) van requirements.

  2. Requirements management: activiteiten voor het ondersteunen (support) en beheersen (control) van de informatie van/over de requirements bij het opstellen van de requirements, zoals het vaststellen van een baseline, wijzigingenbeheer en het borgen van de traceerbaarheid van de requirements.

Bron: The Software Requirements Memory Jogger, Ellen Gottesdiener

Laatst aangepast op zondag, 28 januari 2018 09:07  
Requirements volgens Ellen Gottesdiener
Gepubliceerd in Requirements
E-mail Afdrukken

ellen gottesdiener requirements levels

In The Software Requirements Memory Jogger stelt Ellen Gottesdiener dat requirements kritisch zijn voor het succes van het eindproduct. Ook al worden er tijdens het opstellen van de requirements nog geen software getest, het uitvoeren van conceptuele testen helpt bij het ontdekken van incomplete, foutieve en onduidelijke requirements.

Software requirements worden vaak verdeeld in twee categorieën:

  1. Functionele requirements: requirements die de 'vermogens' (capabilities) beschrijven van het product; dingen die het product moet doen voor de gebruikers of in staat stellen om te doen met de software. Gottesdiener noemt functionele requirements 'the doing part of software'..

  2. Niet-functionele requirements: eigenschappen die het product moet hebben die misschien niet duidelijk zijn voor de gebruikers, zoals bijvoorbeeld kwaliteitsattributen (quality attributes), beperkingen (constraints) en externe koppelingen (external interfaces). Gottesdiener noemt niet-functionele requirements 'the being part of the software - de kenmerken en beperkingen voor het gedrag van de software.

Kwaliteitsattributen: eigenschappen van de softwareontwikkeling en operationele omgeving, zoals performance, capaciteit, onderhoudbaarheid, portabiliteit, betrouwbaarheid en usability.

Ontwerp- en implementatiebeperkingen: beperken hoe de software kan worden ontworpen (bijv. maximaal aantal actieve gebruikers), de omgeving waarbinnen de software zal functioneren of een voorgeschreven programmeertaal.

Externe koppelingen: interfaces met andere systemen (hardware, software en menselijk).

Volgens Gottesdiener zijn er drie niveaus van requirements:

  1. Business requirements: de requirements die gerelateerd zijn aan de business (Waarom wordt het project ondernomen?). Verklaringen (statements) over de business rationale voor het autoriseren van het project. Ze geven aan wat men met de software wil bereiken in termen van (de bijdrage aan) bedrijfsdoelen en bedrijfsstrategie. Business requirements kunnen een hoog-niveau beschrijving omvatten van de software requirements waarbij gebruik gemaakt wordt van kenmerken (samenhangend verzameling van extern zichtbare functionaliteit) om de bedrijfsdoelen (deels) mee te realiseren.

  2. User requirements: requirements die gerelateerd zijn aan de gebruikers van het systeem (Wat kunnen de gebruikers met het systeem doen?). Definities van de eisen aan de software vanuit het perspectief van de gebruiker. User requirements beschrijven de taken die de gebruiker met de software moet kunnen uitvoeren en de benodigde kwaliteitskenmerken van de software. Volgens Gottesdiener zijn user requiremetns de brug tussen de bedrijfsdoelen (uitgedrukt in business termen) en de gedetailleerde software requirements (uitgedrukt in meer technische termen).

  3. Software requirements: requirements die de software zelf beschrijven (Wat moeten ontwikkelaars bouwen?). Gedetailleerde beschrijvingen van alle functionele en niet-functionele eisen waaraan de software moet voldoen om te voorzien in de behoeften van de business en de gebruikers (binnen de grenzen van de gestelde ontwerp- en implementatiebeperkingen). Door middel van de software requirements bereiken de techneuten en de business overeenstemming over wat het product moet doen.

Bron: The Software Requirements Memory Jogger, Ellen Gottesdiener

Laatst aangepast op zondag, 28 januari 2018 09:07  
Nut en noodzaak business requirements volgens Jan Hendrik Stam
Gepubliceerd in Requirements
E-mail Afdrukken

requirements nut noodzaak business requirements

Jan Hendrik Stam stelt in zijn artikel “Nut en noodzaak van business requirements” (Computable, 16/12/2012) dat door aandacht te besteden aan het vaststellen van business requirements veel hoofdpijnpunten voorkomen kunnen worden: “De toepassing van business requirements is daarmee bittere noodzaak. Groot voordeel: het is echt geen rocket science.”

Stam maakt onderscheid tussen twee niveaus van requirements: (1) ‘gedetailleerde requirements’ en de ‘requirements van een hoger niveau’ (2). Het eerste niveau omvat de functional requirements (Wat moet het product kunnen?) en non-functional-requirements  (Welke eisen stellen we aan de werking?), terwijl het bij het ‘hogere’ niveau gaat om de business requirements (‘Waarom doen we dit?').

Volgens Stam richten organisaties zich bij het ontwikkelen van software vaak vooral op de functionele en niet-functionele requirements en wordt er minder tot geen aandacht besteed aan de business requirements. Dit terwijl de business requirements juist van belang zijn om vooraf helder te krijgen wat de business eigenlijk wil bereiken. Bezinnen vóór het beginnen lijkt logisch, maar volgens Stam blijven organisatie vaak het antwoord schuldig op deze vraag en wordt desondanks de ontwikkeling toch voortgezet. Het verwaarlozen van de business requirements is niet zonder risico: dure of uitlopende projecten, oplossingen die duur zijn in het gebruik of oplossingen die überhaupt niet wordt gebruikt.

De nieuwe software moet – als het goed is – een oplossing bieden voor een probleem. Business requirement zijn noodzakelijk om vooraf helder te maken waaraan de nieuwe oplossing moet bijdragen. Stam spreekt in dit verband over een ‘continue heroverweging’, waarbij twee afwegingen noodzakelijk zijn: (a) hoe verhouden de kosten van de oplossing zich tot de baten, (b) zin er omstandigheden en/of ontwikkelingen in de buitenwereld die reden zijn om de business requirements bij te stellen. Stam ziet business requirements als hulpmiddel om het bestaansrecht van een project doorlopend te blijven toetsen.

“Als gevolg van die continue heroverweging kan blijken dat het niet zinvol is om met de ontwikkeling door te gaan. Het voordeel is dat je dat dan in een vroeg stadium kunt signaleren. Het alternatief is bovendien onwenselijk: als je je tijdens de ontwikkeling niet stoort aan wat er in de buitenwereld gebeurt kan het gebeuren dat de uiteindelijke oplossing bij voltooiing volledig obsoleet blijkt te zijn.”

Volgens Stam hebben bij het opstellen van requirements de verschillende belanghebbenden (stakeholders) vaak verschillende, zelfs conflicterende belangen hebben. Het is zaak te kom tot een set aan requirements “die voor alle stakeholders acceptabel is, waarbij ook meteen gezegd is dat niet iedere stakeholder helemaal gekregen heeft wat hij van origine wenste”. Stam stelt dan ook: “Goede communicatie met stakeholders, maar ook tussen stakeholders onderling is een voorwaarde voor een complex aan requirements waarmee iedereen kan leven en dat een oplossing oplevert die echt bijdraagt aan de business.”

“De vertaling van business requirements naar een werkbare oplossing zal onherroepelijk betekenen dat niet iedereen krijgt wat hij wilde. (…) Sommige requirements zullen organisatiebreed gedeeld worden, maar andere zullen conflicteren. Stakeholders moeten daarom in staat zijn het belang van hun eigen onderdeel voor de business goed in te schatten, vooral ook in verhouding tot de organisatie als geheel. Dat betekent dat het eigen belang niet overschat moet worden, maar zeker ook niet onderschat. (…) De stakeholders moeten … verder kunnen kijken dan hun neus lang is en the big picture voor ogen houden.”

Naast het belang van goede requirements en welwillende stakeholders, is het – aldus Stam – ook nodig om op managementniveau weloverwogen requirements bij te stellen bij veranderende omstandigheden. “Elke verandering heeft meestal ook een financiële dimensie. Met andere woorden: er moet vaak geld bij. Het management moet in principe bereid zijn die investering te doen. Voordeel daarbij is wel dat die financiële injectie - middels business requirements - valt te verantwoorden en niet, zoals in veel gevallen, in een zwart gat wordt gekieperd.”

Tot slot, bepleit Stam ("Om te borgen dat het eindproduct maximaal bijdraagt aan de business") de requirements van alle stakeholders vast te leggen in een zgn. requirements traceability matrix. Met deze matrix is het niet alleen mogelijk inzichtelijk te maken welke requiremetns voor welke belanghebbenden belangrijk zijn, maar kan ook worden aangegeven hoe requirements zich tot elkaar verhouden.

Bron: Nut en noodzaak van business requirements, Jan Hendrik Stam (Capgemini) in Computable, 16/12/2012

Laatst aangepast op donderdag, 11 januari 2018 19:31  


JPAGE_CURRENT_OF_TOTAL

Als je geen tijd hebt om iets goed te doen, waar haal je dan de tijd vandaan om je fouten te corrigeren?

Banner
Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 185 gasten online
Artikelen

management job improve system quote taiichi ohno

Bewaren

Banner

understanding how we learn visual guide weinstein sumeracki caviglioli

Understanding How We Learn
A Visual Guide
Yana Weinstein, Megan Sumeracki, Oliver Caviglioli

Bij Bol.com



Lean boekentips

The Hoshin Kanri Forest
Lean Strategic Organizational Design
Javier Villalba-Diez

Bij Bol.com


Banner