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.
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller robintrum. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $3.23. You're not tied to anything after your purchase.