• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Requirements
Requirements
Requirements volgens IREB
Gepubliceerd in Requirements
E-mail Afdrukken

requirements ireb functioneel niet-functioneel beperkingen

In het boek Grip op requirements onderkennen Jan Jaap Cannegieter, Nicole de Swart & Johan Zandhuis twee indelingen van requirements. De eerste onderverdeling die vaak wordt gebruikt voor requirements is de splitsing in functionele requirements en niet-functionele requirements. De tweede indeling van requirements is het onderkennen van business requirements, gebruikers requirements en systeem- of softwarerequirements.

Functionele requirements vs. niet-functionele requirements

  1. Functionele requirements: requirement die het door een systeemfunctie gewenste gedrag beschrijft.

  2. Niet-functionele requirements: requirement die niet het gedrag van het systeem beschrijft maar andere systeemeisen definieert (kwaliteitseisen en/of beperkingen waaraan het systeem moet voldoen)

Functionaliteit definiëren Cannegieter, De Swart en Zandhuis als de mogelijkheden die het systeem moet bieden zoals gesteld in functionele requirements.

Kwaliteitsrequirements geven aan hoe goed het beoogde systeem haar functionaliteit moet aanbieden; het gaat om een kwaliteitseigenschap die niet door een functioneel requirement wordt afgedekt. Een beperking is een requirement dat de oplossingsruimte beperkt in aanvulling op de functionele en kwaliteitsrequirements. In tegenstelling tot functionele en kwaliteitsrequirements kun je een beperking niet implementeren; het gaat om eisen die de oplossingsruimte of het ontwikkelproces limiteren. Bijvoorbeeld, 'het systeem moet gebruik maken van een Oracle-database' en 'het systeem moet voor het eind van het jaar operationeel zijn'.

Business requirements, gebruikersrequirements & systeem- of softwarerequirements

  1. Business requirements: requirements die beschrijven wat de met het systeem te realiseren doelen zijn (welke toegevoegde waarde heeft het systeem voor de organisatie?).

  2. Gebruikersrequirements: requirements die de activiteiten, processen of taken beschrijven die een gebruiker met het systeem wil uitvoeren (op welke manier ga je de business requirements halen?).

  3. Systeem- of softwarerequirements: requirements die het gewenste gedrag of de gewenste kwaliteit van het systeem beschrijven (aan welke eisen moet het systeem voldoen?).

Business requirements zijn geformuleerd vanuit het perspectief van bedrijfsdoelstellingen. Gebruikersrequirements vanuit het perspectief van de bedrijfsvoering en de gebruikers. Systeemrequirements worden beschreven vanuit het perspectief van het systeem.

Bron: Grip op requirements, Jan Jaap Cannegieter, Nicole de Swart & Johan Zandhuis

Laatst aangepast op maandag, 08 januari 2018 14:57  
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  


JPAGE_CURRENT_OF_TOTAL

Results? Why, man, I have gotten lots of results! If I find 10,000 ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is often a step forward.

Thomas Edison

Banner
Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 204 gasten online
Artikelen

hamer champy broken business processes

Banner

work the system sam carpenter

Work the System
The Simple Mechanics of Making More & Working Less
Sam Carpenter

Bij Bol.com

Lean boekentips

Banner