Samenvatting Handboek Requirements H1 t/m 4

Handboek
Requirements



Hoofdstuk
1



Requirements
vertellen
wat
het
te
ontwikkelen
systeem
moet
kunnen.
Zij
vormen
een
brug
tussen
de

business
en
het
softwareteam.










Bij
requirements
gaat
het
om
het
afstemmen
van
verwachtingen.
Het
is
van
groot
belang
dat
de

analist
de
behoeften
en
verwachtingen
van
gebruikers
specificeert
en
dat
deze
goed
begrepen

worden
door
de
ontwikkelaars.



De
volgende
partijen
zijn
betrokken
bij
requirements:









Zij
hebben
de
volgende
belangen
bij
requirements:

De
opdrachtgever:

De
opdrachtgever
start
een
ontwikkeltraject
met
een
reden.
Het
nieuwe
systeem
moet
hem
helpen

om
bepaalde
bedrijfsdoelen
te
halen
of
een
probleem
op
te
lossen.
De
requirements
geven
aan
wat

het
te
ontwikkelen
moet
kunnen
om
het
beoogde
bedrijfsdoel
te
behalen.



De
opdrachtnemer:

De
requirements
vertellen
de
opdrachtnemer
welk
systeem
gerealiseerd
moet
worden.
Pas
als
dit

duidelijk
is
kunnen
de
kosten
ingeschat
worden,
een
planning
maken
en
de
juiste
medewerkers

inzetten.



De
ontwikkelaars:

De
requirements
vertellen
de
ontwikkelaars
waaraan
de
te
bouwen
software
moet
voldoen.
Deze

requirements
vormen
de
basis
van
het
ontwerp
en
de
realisatie.




De
testers:

De
requirements
vertellen
de
testers
waaraan
de
te
testen
software
moet
voldoen.
Dit
zijn
de
norm

waaraan
de
software
wordt
getoetst.





,De
gebruikers:

De
requirements
bepalen
wat
het
systeem
wel
of
niet
kan
en
beïnvloedt
of
de
gebruiker
zijn
werk

goed
en
prettig
kan
uitvoeren.



Ontwikkelactiviteiten
zoals
ontwerpen,
bouwen,
plannen
en
testen
nemen
requirements
als

vertrekpunt.
Als
het
niet
lukt
om
de
requirements
te
achterhalen,
maakt
het
ook
niet
meer
uit
hoe

goed
je
de
overige
activiteiten
uitvoert.
Hiermee
zeggende
dat
fouten
in
de
requirements
gevolgen

heeft
voor
vrijwel
alle
softwareontwikkelactiviteiten.
De
kosten
om
een
requirementsfout
te

herstellen
zijn
laat
in
het
traject
vele
malen
hoger
dan
in
het
begin.



Fase
Relatieve
herstelkosten

Requirements
1
-­‐2

Technisch
ontwerp
5

Realisatie
10

Unit
test
20

Acceptatietest
50

Onderhoud
200



Van
het
totale
budget
voor
maatwerk
softwareontwikkeling
gaat
25
tot
40%
op
aan
het
herstellen

van
fouten
in
de
requirements.
Deze
problemen
ontstaan
vaak
door
de
geringe
kwaliteit
van
de

requirements,
wijzigingen
in
de
requirements
en
het
gebrek
aan
gebruikersinbreng.



De
kritieke
succesfactoren
voor
softwareontwikkeling
zijn:

§ Kwalitatief
goede
requirementsspecificaties;

§ Managen
van
wijzigingen
in
de
requirements;

§ Voldoende
gebruikersinbreng.



Kwalitatief
goede
requirementsspecificaties

Er
zijn
verschillende
kwaliteitscriteria
waaraan
voldaan
moet
worden:

Volledigheid

Het
is
pas
volledig
zodra
er
geen
enkele
requirement
ontbreekt.
Helaas
is
het
niet
mogelijk
dit
vast
te

stellen.
Hierbij
moet
de
requirement
ook
alle
(detail)informatie
bevatten
zodat
de
testers
en

ontwikkelaars
genoeg
informatie
hebben
om
mee
te
kunnen
werken.



Consistentie

Het
is
pas
consistent
zodra
er
geen
conflicterende
requirements
in
staan.
Dit
komt
voor
zodra

bepaalde
belanghebbenden
een
verschil
van
mening
over
de
requirement
hebben.
Voor
consistente

specificaties
zijn
zorgvuldige
formulering
van
requirements
belangrijk.



Eenduidigheid

Het
is
pas
eenduidig
als
specificaties
voor
één
uitleg
vatbaar
zijn.
Hierdoor
wordt
het
door
alle

belanghebbenden
op
dezelfde
manier
geïnterpreteerd.
Dit
is
door
inherent
aan
natuurlijke
taal
niet

100%
mogelijk.



Validiteit

Het
is
valide
als
het
bijdraagt
aan
het
beoogde
bedrijfsdoel.
Hierdoor
hoeft
er
geen
tijd
in
onnodige

functionaliteit
te
worden
gestoken.





, Managen
van
wijzigingen
in
de
requirements

De
watervalaanpak
heeft
als
grondslag
dat
eenmaal
onderkende
requirements
voor
de
rest
van
het

traject
bevroren
kunnen
worden.
Het
managen
van
wijzigende
requirements
voorkomt
het

verschijnsel
scoprecreep
waarbij
de
omvang
van
de
te
ontwikkelen
software
ongemerkt
of

ongecontroleerd
blijft
toenemen.
Het
ontwikkelteam
moet
inzicht
hebben
in
de
wijzigingen
en

actuele
versies
met
statussen.



Voldoende
gebruikersinbreng

Gebruikers
en
andere
belanghebbenden
moeten
aangeven
wat
het
systeem
moet
kunnen
op
zowel

hoog
als
laag
detailniveau.
Intensieve
samenwerking
tussen
de
teams
is
nodig
om
de
requirements

scherp
te
krijgen
en
houden.
Voldoende
gebruikersinbreng
gebeurt
alleen
als
opdrachtgever
en
het

team
hier
het
nut
en
de
noodzaak
van
inzien.
Ontwikkelaars
moeten
blijven
afstemmen
met
de

gebruikers.




Onderschatting
vakgebied

Problemen
die
projecten
in
de
praktijk
ondervinden
zijn
niet
te
verklaren
met
een
gebrek

aan
theoretische
handvatten.
Een
onderschatting
van
het
requirementsvak
is
vaak
een

verklaring
voor
de
huidige
problemen.
Vaak
wordt
er
te
weinig
tijd
en
aandacht
besteed
aan

de
requirements.
Of
het
werk
wordt
overgelaten
aan
onvoldoende
gekwalificeerde

medewerkers.
Onderschatting
van
de
moeilijkheidsgraat
van
requirements
komt
vaak
voor.