Hoofdstuk 1 – vakgebied in beweging
Requirement engineering is een discipline binnen de softwareontwikkeling
Requirements engineering gaat over het concretiseren van de behoefte van de business en de
gewenste geautomatiseerde ondersteuning daarbij.
Het doel van requirements engineering is het tot stand brengen en in stand houden van
overeenstemming tussen de opdrachtgever, de overige belanghebbenden uit de business en het
softwareontwikkelteam over de requirements
De baseline zijn de goedgekeurde requirements en vormt de basis voor de softwareontwikkeling
Requirement management richt zich op het gecontroleerd doorvoeren van wijzigingen in de
requirements
Met de komst van het businessperspectief verschoof het accent van de functionaliteit van het
systeem naar de bedrijfs- en klantprocessen die het ondersteunt.
Bij het businessperspectief staan de behoeften van de business aan geautomatiseerde ondersteuning
centraal.
Twee typen requirements: business- en gebruikersrequirements
Een use case geeft aan hoe het systeem en de gebruiker samenwerken om een eindresultaat te halen
dat waarde heeft voor de gebruiker.
De agile aanpak brengt softwareontwikkeling terug tot de kern, namelijk het ontwikkelen van voor de
business waardevolle software.
Een product backlog is een geprioriteerde opsomming van nog uit te werken en te implementeren
requirements.
De requirementsanalist is verantwoordelijk voor het vullen van de baseline met eenduidig
gespecificeerde en goedgekeurde requirements.
Requirement engineering is opgebouwd uit requirement development en requirements
management.
Bij requirements development draait het om het achterhalen, analyseren, specificeren en valideren
van de requirements.
Het streven is niet om meteen de juiste requirements te vinden, maar om gaandeweg het traject
steeds beter zicht te krijgen op de werkelijke behoefte van de business.
Agile team -> nog niet weten welke requirements het uiteindelijk systeem moet voldoen
Requirements engineering -> requirementsanalist probeert in één keer de juiste requirements in
kaart te brengen.
De requirementsanalist vervult een brugfunctie tussen de business en het softwareontwikkelteam
De requirementsanalist legt de overeengekomen requirements vast in requirementsproducten. Het
softwareontwikkelteam implementeert vervolgens de vastgelegde requirements.
Een agile team bestaat gewoonlijk uit een multidisciplinair ontwikkelteam, een product owner en een
scrum master.
De product owner is verantwoordelijk voor het maximaliseren van de businesswaarde van het te
ontwikkelen systeem en van het werk van het ontwikkelteam.
, De scrum master zorgt er als dienend leider voor dat iedereen binnen en buiten het scrum team de
agile principes en regels begrijpt en daarnaar handelt.
Hoofdstuk 2 – Requirementsperspectieven
De letterlijke betekenis van de term requirement is a) behoefte of b) eis
a) Een requirement is een behoefte aan geautomatiseerde ondersteuning
b) Een requirement is een eis die gesteld wordt aan het systeem
Behoefte aan geautomatiseerde ondersteuning – proces of activiteit – waarom = verbetering in een
proces
Eis aan het systeem – gedrag van het systeem – hoe goed = kwaliteitskenmerk van het systeem
Requirement = gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte
te voorzien van een belanghebbende uit de business.
Naast een eigenschap van het systeem kan een requirement ook betrekking hebben op een proces of
een verbetering daarin.
Een requirement is:
a) 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;
b) Een eis aan het systeem = gedrag (functionaliteit) of een kwaliteit die het systeem moet bezitten
om in een behoefte te voorzien van een belanghebbende uit de business.
Niet alle eisen zijn requirements, slechts een deelverzameling.
Het zijn alleen die eisen die gesteld worden aan het gedrag of de kwaliteit van het systeem om in een
behoefte van een belanghebbende uit de business te voorzien.
Vakgebieden eisen = projectmanagement, testen, ICT beleid / enterprise, architectuur,
systeemontwerp en software architectuur.
Vakgebied requirements = requirements engineering
Requirements moeten in principe oplossingsvrij zijn.
Anders bestaat de kans dat op voorhand andere, misschien wel betere, oplossing worden
uitgesloten.
Requirements zijn dus in principe vrij van oplossingen tenzij door ontwerpbeslissingen en technische
voorschriften extra requirements zijn ontstaan.
Bij het systeemperspectief staan het systeem en de eisen die de business daaraan stelt centraal.
Softwarerequirements zijn systeemeisen die voortkomen uit de behoeften van de business.
Een softwarerequirement is gedrag (functionaliteit) of een kwaliteit die het systeem moet bezitten
om in een behoefte te voorzien van een belanghebbende uit de business.
Softwarerequirements zijn onder te verdelen in functionele en niet-functionele requirements.
Functionele requirements -> geven aan wat de gewenste functionaliteit ofwel het gewenste gedrag
van het systeem is. Gaat om van buitenaf waarneembare gedrag en niet om de interne werking van
het systeem.
Functionele requirements beschrijven de invoer die het systeem nodig heeft, de uitvoer die het
systeem vervaardigt en wat er nodig is om van invoer tot uitvoer te komen, kortweg de
systeemfunctie genoemd.
Requirement engineering is een discipline binnen de softwareontwikkeling
Requirements engineering gaat over het concretiseren van de behoefte van de business en de
gewenste geautomatiseerde ondersteuning daarbij.
Het doel van requirements engineering is het tot stand brengen en in stand houden van
overeenstemming tussen de opdrachtgever, de overige belanghebbenden uit de business en het
softwareontwikkelteam over de requirements
De baseline zijn de goedgekeurde requirements en vormt de basis voor de softwareontwikkeling
Requirement management richt zich op het gecontroleerd doorvoeren van wijzigingen in de
requirements
Met de komst van het businessperspectief verschoof het accent van de functionaliteit van het
systeem naar de bedrijfs- en klantprocessen die het ondersteunt.
Bij het businessperspectief staan de behoeften van de business aan geautomatiseerde ondersteuning
centraal.
Twee typen requirements: business- en gebruikersrequirements
Een use case geeft aan hoe het systeem en de gebruiker samenwerken om een eindresultaat te halen
dat waarde heeft voor de gebruiker.
De agile aanpak brengt softwareontwikkeling terug tot de kern, namelijk het ontwikkelen van voor de
business waardevolle software.
Een product backlog is een geprioriteerde opsomming van nog uit te werken en te implementeren
requirements.
De requirementsanalist is verantwoordelijk voor het vullen van de baseline met eenduidig
gespecificeerde en goedgekeurde requirements.
Requirement engineering is opgebouwd uit requirement development en requirements
management.
Bij requirements development draait het om het achterhalen, analyseren, specificeren en valideren
van de requirements.
Het streven is niet om meteen de juiste requirements te vinden, maar om gaandeweg het traject
steeds beter zicht te krijgen op de werkelijke behoefte van de business.
Agile team -> nog niet weten welke requirements het uiteindelijk systeem moet voldoen
Requirements engineering -> requirementsanalist probeert in één keer de juiste requirements in
kaart te brengen.
De requirementsanalist vervult een brugfunctie tussen de business en het softwareontwikkelteam
De requirementsanalist legt de overeengekomen requirements vast in requirementsproducten. Het
softwareontwikkelteam implementeert vervolgens de vastgelegde requirements.
Een agile team bestaat gewoonlijk uit een multidisciplinair ontwikkelteam, een product owner en een
scrum master.
De product owner is verantwoordelijk voor het maximaliseren van de businesswaarde van het te
ontwikkelen systeem en van het werk van het ontwikkelteam.
, De scrum master zorgt er als dienend leider voor dat iedereen binnen en buiten het scrum team de
agile principes en regels begrijpt en daarnaar handelt.
Hoofdstuk 2 – Requirementsperspectieven
De letterlijke betekenis van de term requirement is a) behoefte of b) eis
a) Een requirement is een behoefte aan geautomatiseerde ondersteuning
b) Een requirement is een eis die gesteld wordt aan het systeem
Behoefte aan geautomatiseerde ondersteuning – proces of activiteit – waarom = verbetering in een
proces
Eis aan het systeem – gedrag van het systeem – hoe goed = kwaliteitskenmerk van het systeem
Requirement = gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte
te voorzien van een belanghebbende uit de business.
Naast een eigenschap van het systeem kan een requirement ook betrekking hebben op een proces of
een verbetering daarin.
Een requirement is:
a) 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;
b) Een eis aan het systeem = gedrag (functionaliteit) of een kwaliteit die het systeem moet bezitten
om in een behoefte te voorzien van een belanghebbende uit de business.
Niet alle eisen zijn requirements, slechts een deelverzameling.
Het zijn alleen die eisen die gesteld worden aan het gedrag of de kwaliteit van het systeem om in een
behoefte van een belanghebbende uit de business te voorzien.
Vakgebieden eisen = projectmanagement, testen, ICT beleid / enterprise, architectuur,
systeemontwerp en software architectuur.
Vakgebied requirements = requirements engineering
Requirements moeten in principe oplossingsvrij zijn.
Anders bestaat de kans dat op voorhand andere, misschien wel betere, oplossing worden
uitgesloten.
Requirements zijn dus in principe vrij van oplossingen tenzij door ontwerpbeslissingen en technische
voorschriften extra requirements zijn ontstaan.
Bij het systeemperspectief staan het systeem en de eisen die de business daaraan stelt centraal.
Softwarerequirements zijn systeemeisen die voortkomen uit de behoeften van de business.
Een softwarerequirement is gedrag (functionaliteit) of een kwaliteit die het systeem moet bezitten
om in een behoefte te voorzien van een belanghebbende uit de business.
Softwarerequirements zijn onder te verdelen in functionele en niet-functionele requirements.
Functionele requirements -> geven aan wat de gewenste functionaliteit ofwel het gewenste gedrag
van het systeem is. Gaat om van buitenaf waarneembare gedrag en niet om de interne werking van
het systeem.
Functionele requirements beschrijven de invoer die het systeem nodig heeft, de uitvoer die het
systeem vervaardigt en wat er nodig is om van invoer tot uitvoer te komen, kortweg de
systeemfunctie genoemd.
