1. Hoe stel je een requirement op?
1.1. Om een requirement goed te beschrijven, zodat iedereen dezelfde interpretatie heeft, kun je gebruik maken van SMART: Specifiek, Meetbaar, Acceptabel, Realiseerbaar en Tijdsgebonden.
1.2. Hier een lijstje waar je aan moet denken bij het maken van een requirement (Swart, 2012)
1.2.1. 1. Actieve zinnen: Het is dan duidelijk wie wat uitvoert
1.2.2. 2. Geen vage woorden: Die geven onvoldoende informatie
1.2.3. 3. Atomair: Zo kunnen requirements niet verder worden opgesplitst
1.2.4. 4. Kernpunt als eerste: Het is dan duidelijk wat er bedoeld wordt en de zin is makkelijker te lezen
1.2.5. 5. Kwantificeer waar mogelijk, maak de requirements meetbaar. Zo kun je makkelijker controleren of de requirement is voldaan
1.2.6. Gebruik geen woorden die op elkaar lijken want dat kan lijden tot dubbelzinnigheid.
2. Wat is het doel van een requirement?
2.1. Het doel van een requirement is om ervoor te zorgen dat het de het bedrijf (en eventuele stakeholders) weten wat er gemaakt gaat worden en wat het allemaal in gaat houden. Het is erg belangrijk dat requirements goed worden gevalideerd bij de organisatie (en eventuele stakeholders) omdat er anders aan projecten en functionaliteiten worden begonnen waar de klant helemaal niet om heeft gevraagd.
3. Welke verschillende soorten requirements zijn er?
3.1. sidenote:
3.1.1. Eisen komen voor uit behoefte. Zijn beide requirements.
3.1.1.1. een behoefte is een requirement als een belanghebbende er iets aan heeft. (procesverbetering) meer beschreven vanuit de klant
3.1.1.2. (systeen)eis
3.1.1.3. meeste gevallen worden requirements beschreven als behoefte
3.1.1.4. user storie is nog 'onduidelijker'.
3.2. Business perspectief
3.2.1. bepalen welke software- en/of gebruikersrequirements van belang zijn.
3.2.2. business requirements
3.2.2.1. Komen vanuit een opdrachtgever en worden uitgedrukt in businessdoelen > een klant wil bedrijfsproces verbeteren of de klanttevredenheid verbeteren. Er wordt ook rekening gehouden met de wensen van een klant, als deze geen nut zien in een applicatie dan wordt deze ook niet gebruikt. Wensen van de klant mogen dus niet vergeten worden bij business requirements. Gaat over het waarom.
3.2.3. gebruikersrequirements
3.2.3.1. Vanuit de klant geformuleerd en gaat over het wat. Welke functie wil de gebruiker hebben in een applicatie.
3.3. systeem perspectief
3.3.1. Functionele software requirements
3.3.1.1. Deze requirements beschrijven een functionele functie van het systeem; hoe een systeem zich moet gedragen
3.3.2. Niet-functionele software beschrijven de requirements waarop het systeem de functies moet aanbieden.
4. Wie zijn er betrokken bij requirements?
4.1. Opdrachtgever
4.2. Opdrachtnemer
4.3. Ontwikkelaars
4.4. Gebruikers
4.5. Testers
5. Wat zijn requirements?
5.1. Eisen systeem
5.2. Behoefte systeem
5.3. Brug tussen ICT & Business
6. Hoe weet je wanneer je requirement goed is?
6.1. Compleet
6.1.1. Moet een geheel systeem beschrijven inclusief het gewenste gedrag
6.2. Correct
6.3. Realiseer
6.4. Waardevol
6.5. Geprioriteerd
6.5.1. Functionaliteit systeem meestal als eerste, minder belangrijke als laatste