Samenvatting Handboek Requirements
Hoofdstuk 1 t/m 12
Positionering requirements
Hs. 1 Belang van requirements
Requirements als brug: requirements vertellen wat het te ontwikkelen system moet kunnen. Vanuit
de business, om hen optimaal te ondersteunen en vanuit het ontwikkelteam, om het te realiseren.
Het gaat bij requirements om het afstemmen van verwachtingen.
Belanghebbende van requirements:
- De opdrachtgever: het nieuwe systeem moet hem helpen om bepaalde bedrijfsdoelen te halen
of om een probleem op te lossen.
- De opdrachtnemer: requirements vertellen welk systeem gerealiseerd moet worden, hierna
kunnen betrouwbare inschattingen gemaakt worden.
- De ontwikkelaars: requirements vertellen waaraan de te bouwen software aan moet voldoen. De
basis van het systeemontwerp en de realisatie.
- De testers: waar moet de software aan voldoen. Testen of de norm is behaald.
- De gebruikers: wat kan het nieuwe systeem en wat niet. Gebruiksvriendelijkheid.
Ontwikkelactiviteiten zoals ontwerpen, bouwen en testen nemen de te implementeren requirements
als vertrekpunt. Een fout die tijdens het opstellen van de requirements wordt ontdekt en hersteld
kost vijf tot tien keer minder dan dezelfde fout die tijdens de realisatie wordt ontdekt en hersteld. De
problemen die software ontwikkelprojecten ondervinden met requirements blijken hoofdzakelijk
betrekking te hebben op de kwaliteit van de specificaties van de requirements op wijzigingen in de
requirements en op gebrek aan gebruikersinbreng.
De kritische succesfactoren voor softwareontwikkeling:
- Kwalitatief goede requirementsspecificaties, criteria:
Volledigheid, niets ontbreekt.
Consistentie, geen conflicterende requirements.
Eenduidigheid, een uitleg nodig.
Validiteit, bijdragen aan het beoogde bedrijfsdoel.
- Managen van wijzigingen in de requirements.
- Voldoende gebruikersinbreng.
Hs. 2 Requirements
Een requirement is:
1. Een behoefte aan geautomatiseerde ondersteuning: een proces of een verbetering daarin, die
een belanghebbende uit de business (deels) met behulp van het systeem wil uitvoeren.
2. Een eis aan het systeem: gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in
een behoefte te voorzien van een belanghebbende uit de business.
, Verdeling in functioneel en niet-functioneel. Een functionele requirement geeft het gewenste gedrag
van het systeem weer. Een niet-functionele requirement is een kwaliteitseis waaraan het systeem
moet voldoen, bijvoorbeeld hoe snel, hoe gemakkelijk, hoe veilig, hoe foutgevoelig het systeem moet
zijn.
Een systeemfunctie zet de invoer van het systeem om in de uitvoer. Het verschil tussen een
gewenste systeemfunctie en een functionele requirement is dat een functionele requirement een eis
stelt aan het gedrag van het systeem, terwijl een systeemfunctie dat gedrag zelf representeert.
Gevolg: een functioneel ontwerp is vervangen door een requirementspecificatie. Het is niet mogelijk
om eisen te ontwerpen.
Een use case is een requirement en representeert de geautomatiseerde ondersteuning die een
gebruiker nodig heeft bij het uitvoeren van een procestaak. Een use case levert een resultaat dat
zelfstandig waarde heeft voor de gebruiker en geeft aan hoe de gebruiker en het systeem
samenwerken om dat resultaat te behalen.
Onjuist gebruik van requirement:
- Eis is geen synoniem van requirement.
- Een technische beperking is geen requirement, maar stelt wel eisen aan de implementatie van de
requirement.
- Een ontwerpbeslissing is een beslissing over de manier waarop de requirements
geïmplementeerd worden.
- Een bedrijfsregel is een regel die een bepaald aspect van de business definieert of beperkt.
Hs. 3 Requirements engineering
Voordat een organisatie besluit om een software ontwikkeltraject te starten is er behoefte aan extra
geautomatiseerde ondersteuning, bijvoorbeeld omdat er aanpassingen in de interne
bedrijfsprocessen nodig zijn.
Relatie tussen requirements engineering en andere vakgebieden:
- Projectleiding: ontwikkeling
- Systeemontwerp: ontwerp
- Realisatie: implementatie
- Test: specificaties
Het doel van requirements engineering is het tot stand brengen en in stand houden van
overeenstemming tussen de opdrachtgever, de medewerkers en het software ontwikkelteam over
de requirements. Requirements development resulteert in een baseline met daarin de
overeengekomen requirements.
Hoofdstuk 1 t/m 12
Positionering requirements
Hs. 1 Belang van requirements
Requirements als brug: requirements vertellen wat het te ontwikkelen system moet kunnen. Vanuit
de business, om hen optimaal te ondersteunen en vanuit het ontwikkelteam, om het te realiseren.
Het gaat bij requirements om het afstemmen van verwachtingen.
Belanghebbende van requirements:
- De opdrachtgever: het nieuwe systeem moet hem helpen om bepaalde bedrijfsdoelen te halen
of om een probleem op te lossen.
- De opdrachtnemer: requirements vertellen welk systeem gerealiseerd moet worden, hierna
kunnen betrouwbare inschattingen gemaakt worden.
- De ontwikkelaars: requirements vertellen waaraan de te bouwen software aan moet voldoen. De
basis van het systeemontwerp en de realisatie.
- De testers: waar moet de software aan voldoen. Testen of de norm is behaald.
- De gebruikers: wat kan het nieuwe systeem en wat niet. Gebruiksvriendelijkheid.
Ontwikkelactiviteiten zoals ontwerpen, bouwen en testen nemen de te implementeren requirements
als vertrekpunt. Een fout die tijdens het opstellen van de requirements wordt ontdekt en hersteld
kost vijf tot tien keer minder dan dezelfde fout die tijdens de realisatie wordt ontdekt en hersteld. De
problemen die software ontwikkelprojecten ondervinden met requirements blijken hoofdzakelijk
betrekking te hebben op de kwaliteit van de specificaties van de requirements op wijzigingen in de
requirements en op gebrek aan gebruikersinbreng.
De kritische succesfactoren voor softwareontwikkeling:
- Kwalitatief goede requirementsspecificaties, criteria:
Volledigheid, niets ontbreekt.
Consistentie, geen conflicterende requirements.
Eenduidigheid, een uitleg nodig.
Validiteit, bijdragen aan het beoogde bedrijfsdoel.
- Managen van wijzigingen in de requirements.
- Voldoende gebruikersinbreng.
Hs. 2 Requirements
Een requirement is:
1. Een behoefte aan geautomatiseerde ondersteuning: een proces of een verbetering daarin, die
een belanghebbende uit de business (deels) met behulp van het systeem wil uitvoeren.
2. Een eis aan het systeem: gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in
een behoefte te voorzien van een belanghebbende uit de business.
, Verdeling in functioneel en niet-functioneel. Een functionele requirement geeft het gewenste gedrag
van het systeem weer. Een niet-functionele requirement is een kwaliteitseis waaraan het systeem
moet voldoen, bijvoorbeeld hoe snel, hoe gemakkelijk, hoe veilig, hoe foutgevoelig het systeem moet
zijn.
Een systeemfunctie zet de invoer van het systeem om in de uitvoer. Het verschil tussen een
gewenste systeemfunctie en een functionele requirement is dat een functionele requirement een eis
stelt aan het gedrag van het systeem, terwijl een systeemfunctie dat gedrag zelf representeert.
Gevolg: een functioneel ontwerp is vervangen door een requirementspecificatie. Het is niet mogelijk
om eisen te ontwerpen.
Een use case is een requirement en representeert de geautomatiseerde ondersteuning die een
gebruiker nodig heeft bij het uitvoeren van een procestaak. Een use case levert een resultaat dat
zelfstandig waarde heeft voor de gebruiker en geeft aan hoe de gebruiker en het systeem
samenwerken om dat resultaat te behalen.
Onjuist gebruik van requirement:
- Eis is geen synoniem van requirement.
- Een technische beperking is geen requirement, maar stelt wel eisen aan de implementatie van de
requirement.
- Een ontwerpbeslissing is een beslissing over de manier waarop de requirements
geïmplementeerd worden.
- Een bedrijfsregel is een regel die een bepaald aspect van de business definieert of beperkt.
Hs. 3 Requirements engineering
Voordat een organisatie besluit om een software ontwikkeltraject te starten is er behoefte aan extra
geautomatiseerde ondersteuning, bijvoorbeeld omdat er aanpassingen in de interne
bedrijfsprocessen nodig zijn.
Relatie tussen requirements engineering en andere vakgebieden:
- Projectleiding: ontwikkeling
- Systeemontwerp: ontwerp
- Realisatie: implementatie
- Test: specificaties
Het doel van requirements engineering is het tot stand brengen en in stand houden van
overeenstemming tussen de opdrachtgever, de medewerkers en het software ontwikkelteam over
de requirements. Requirements development resulteert in een baseline met daarin de
overeengekomen requirements.
