SAMENVATTING HANDBOEK
REQUIREMENTS
BRUG TUSSEN BUSINESS EN ICT
1
,INHOUD
H1 – Belang van de requirements ................................................................................................................................... 3
H2 – Requirements .......................................................................................................................................................... 5
H5 – Requirementsmodel ................................................................................................................................................ 7
H6 (50-54) – Businessrequirements ................................................................................................................................ 9
H7 – Gebruikersrequirements ....................................................................................................................................... 10
H8 – Softwarerequirements .......................................................................................................................................... 12
Functionele softwarerequirements ........................................................................................................................... 12
Niet-functionele softwarerequirements ................................................................................................................... 13
Functionaliteit ........................................................................................................................................................ 13
Betrouwbaarheid ................................................................................................................................................... 14
Bruikbaarheid ........................................................................................................................................................ 14
Efficiency ................................................................................................................................................................ 14
Onderhoudbaarheid .............................................................................................................................................. 15
Overdraagbaarheid ................................................................................................................................................ 15
H9 (86-89) – Requirementsproces (sub gebieden, requirements development) ......................................................... 16
H11 – Requirementstechnieken .................................................................................................................................... 17
Elicitatietechnieken ............................................................................................................................................... 17
Analysetechnieken................................................................................................................................................. 18
Specificatietechnieken ........................................................................................................................................... 19
Validatietechnieken ............................................................................................................................................... 20
H12 (120-121) – Requirement management (TRACEERBAARHEID) ............................................................................. 21
H13 – Elicitatietechnieken ............................................................................................................................................. 22
H14 – Analysetechnieken .............................................................................................................................................. 23
H15 – Specificatietechnieken ........................................................................................................................................ 24
H16................................................................................................................................................................................. 25
H17 – Belanghebbenden ............................................................................................................................................... 26
H19 (187-191) – Requirementsproducten .................................................................................................................... 28
H20 – Niet-functionele softwarerequirements ............................................................................................................. 30
H21 – Use cases ............................................................................................................................................................. 31
2
,H1 – BELANG VAN DE REQUIREMENTS
Requirements zijn er enerzijds om de business optimaal te kunnen ondersteunen en anderzijds om het software-
ontwikkelteam het project te kunnen laten realiseren. Het gaat dan voornamelijk om het afstemmen van de
requirements. De requirements vormen een brug tussen de business en de ICT
Schommelkarikatuur: afstemmen van requirements.
De vijf belanghebbenden van een systeem + waarom zij de betreffende requirements nodig hebben:
1) Opdrachtgever: softwareontwikkeltraject niet zonder reden gestart bepaalde bedrijfsdoelen
halen/problemen op te lossen.
2) Opdrachtnemer: Hij weet hierdoor wat er ontwikkeld moet worden en kan inschattingen gaan maken betreft de
kosten, de planning en het personeel. Hoe beter de requirements, hoe nauwkeuriger de inschatting.
3) Ontwikkelaars: Hierdoor weten de ontwikkelaars waar het systeem aan moet voldoen.
4) Testers: Hierdoor weten de testers waaraan de te testen software moet voldoen. De gegeven requirements zijn
tevens de norm voor het testen van de software.
5) Gebruikers: Zij weten wat het systeem na het ontwikkelen wel en niet kan. Dit zal de manier van werken
beïnvloeden (prettig of niet prettig).
Als het niet lukt om de requirements te achterhalen, maakt het ook niet meer uit hoe goed je de overige
activiteiten uitvoert.
Requirements globaal gezien: opdrachtverstrekking, projectplan.
Requirements gedetailleerd gezien: detailplanning, ontwerp, bouw, test. Deze ontwikkelactiviteiten
nemen de requirements als vertrekpunt.
De relatieve herstelkosten van een doorwerkfout, betreft de requirements, worden steeds hoger naarmate er meer
activiteiten zijn uitgevoerd met de verkeerde requirements.
3
, Van het totale budget, dat wordt gebruikt voor het ontwikkelen van een systeem/software applicatie, gaat 25%
tot 40% op aan het herstellen van fouten in de requirements.
Drie grote fouten die projecten doen falen/niet succesvol maken:
Gebrek aan gebruikersinbreng, onvolledige requirements/specificaties, veranderende
requirements/specificaties.
Kritieke succesfactoren
Kwalitatief goede requirementsspecificaties; volledig, consistent, eenduidig en valide.
Managen van wijzigingen in de requirements; voorkomt een scope creep (omvang van de te ontwikkelen
software neemt niet toe).
Voldoende gebruikersinbreng; om een intensieve samenwerking tussen de gebruikers en het
ontwikkelteam, betreft de requirements, scherp te krijgen/te houden.
Het belang en de moeilijkheidsgraad van requirements worden vaak onderschat. Dit is een verklaring voor het feit
dat er zoveel softwareprojecten met problemen kampen.
4
REQUIREMENTS
BRUG TUSSEN BUSINESS EN ICT
1
,INHOUD
H1 – Belang van de requirements ................................................................................................................................... 3
H2 – Requirements .......................................................................................................................................................... 5
H5 – Requirementsmodel ................................................................................................................................................ 7
H6 (50-54) – Businessrequirements ................................................................................................................................ 9
H7 – Gebruikersrequirements ....................................................................................................................................... 10
H8 – Softwarerequirements .......................................................................................................................................... 12
Functionele softwarerequirements ........................................................................................................................... 12
Niet-functionele softwarerequirements ................................................................................................................... 13
Functionaliteit ........................................................................................................................................................ 13
Betrouwbaarheid ................................................................................................................................................... 14
Bruikbaarheid ........................................................................................................................................................ 14
Efficiency ................................................................................................................................................................ 14
Onderhoudbaarheid .............................................................................................................................................. 15
Overdraagbaarheid ................................................................................................................................................ 15
H9 (86-89) – Requirementsproces (sub gebieden, requirements development) ......................................................... 16
H11 – Requirementstechnieken .................................................................................................................................... 17
Elicitatietechnieken ............................................................................................................................................... 17
Analysetechnieken................................................................................................................................................. 18
Specificatietechnieken ........................................................................................................................................... 19
Validatietechnieken ............................................................................................................................................... 20
H12 (120-121) – Requirement management (TRACEERBAARHEID) ............................................................................. 21
H13 – Elicitatietechnieken ............................................................................................................................................. 22
H14 – Analysetechnieken .............................................................................................................................................. 23
H15 – Specificatietechnieken ........................................................................................................................................ 24
H16................................................................................................................................................................................. 25
H17 – Belanghebbenden ............................................................................................................................................... 26
H19 (187-191) – Requirementsproducten .................................................................................................................... 28
H20 – Niet-functionele softwarerequirements ............................................................................................................. 30
H21 – Use cases ............................................................................................................................................................. 31
2
,H1 – BELANG VAN DE REQUIREMENTS
Requirements zijn er enerzijds om de business optimaal te kunnen ondersteunen en anderzijds om het software-
ontwikkelteam het project te kunnen laten realiseren. Het gaat dan voornamelijk om het afstemmen van de
requirements. De requirements vormen een brug tussen de business en de ICT
Schommelkarikatuur: afstemmen van requirements.
De vijf belanghebbenden van een systeem + waarom zij de betreffende requirements nodig hebben:
1) Opdrachtgever: softwareontwikkeltraject niet zonder reden gestart bepaalde bedrijfsdoelen
halen/problemen op te lossen.
2) Opdrachtnemer: Hij weet hierdoor wat er ontwikkeld moet worden en kan inschattingen gaan maken betreft de
kosten, de planning en het personeel. Hoe beter de requirements, hoe nauwkeuriger de inschatting.
3) Ontwikkelaars: Hierdoor weten de ontwikkelaars waar het systeem aan moet voldoen.
4) Testers: Hierdoor weten de testers waaraan de te testen software moet voldoen. De gegeven requirements zijn
tevens de norm voor het testen van de software.
5) Gebruikers: Zij weten wat het systeem na het ontwikkelen wel en niet kan. Dit zal de manier van werken
beïnvloeden (prettig of niet prettig).
Als het niet lukt om de requirements te achterhalen, maakt het ook niet meer uit hoe goed je de overige
activiteiten uitvoert.
Requirements globaal gezien: opdrachtverstrekking, projectplan.
Requirements gedetailleerd gezien: detailplanning, ontwerp, bouw, test. Deze ontwikkelactiviteiten
nemen de requirements als vertrekpunt.
De relatieve herstelkosten van een doorwerkfout, betreft de requirements, worden steeds hoger naarmate er meer
activiteiten zijn uitgevoerd met de verkeerde requirements.
3
, Van het totale budget, dat wordt gebruikt voor het ontwikkelen van een systeem/software applicatie, gaat 25%
tot 40% op aan het herstellen van fouten in de requirements.
Drie grote fouten die projecten doen falen/niet succesvol maken:
Gebrek aan gebruikersinbreng, onvolledige requirements/specificaties, veranderende
requirements/specificaties.
Kritieke succesfactoren
Kwalitatief goede requirementsspecificaties; volledig, consistent, eenduidig en valide.
Managen van wijzigingen in de requirements; voorkomt een scope creep (omvang van de te ontwikkelen
software neemt niet toe).
Voldoende gebruikersinbreng; om een intensieve samenwerking tussen de gebruikers en het
ontwikkelteam, betreft de requirements, scherp te krijgen/te houden.
Het belang en de moeilijkheidsgraad van requirements worden vaak onderschat. Dit is een verklaring voor het feit
dat er zoveel softwareprojecten met problemen kampen.
4
