Nederlandstalige samenvatting van alle hoofdstukken van het boek Handboek Requirements: Leidraad voor analisten in agile, traditionele en hybride omgevingen, 6e druk (2019), geschreven door Nicole de Swart.
1.1. Requirements Engineering
Requirements engineering is een discipline binnen de softwareontwikkeling wat gaat
over het concretiseren van de behoefte van de business en de gewenste
geautomatiseerde ondersteuning daarbij. Het doel hierbij is om overeenstemming te
bereiken en te houden tussen de opdrachtgever, de overige belanghebbenden uit de
business en het softwareontwikkelteam over de requirements. De opdrachtgever is
eindverantwoordelijk maar laat de afstemming over de gedetailleerde requirements
normaliter over aan andere belanghebbenden. De belangen van deze andere
belanghebbenden kunnen echter conflicteren met die van de opdrachtgever. Een
voorwaarde voor het bereiken van overeenstemming is dat alle belanghebbenden de
requirements goed en op dezelfde manier begrijpen. Anders kan er sprake zijn van
schijnovereenstemming.
Het tot stand brengen van overeenstemming over de requirements staat ook wel bekend
als requirements development. Dit resulteert in een verzameling goedgekeurde
requirements, baseline genoemd. De requirements in de baseline zijn echter niet in
beton gegoten, er is daarom nog aandacht nodig voor het in stand houden van de
overeenstemming. Requirements dienen daarom aanpasbaar te zijn, zelfs als ze al door
zijn gevoerd. De afgelopen decennia is requirements engineering verschoven van het
systeem- naar het businessperspectief.
Systeemperspectief
Men kwam in de jaren zeventig tot het inzicht dat de gewenste acties van het systeem
(de functionaliteit, ‘het wat’) en de implementatie daarvan (de technische oplossing, ‘het
hoe’) afzonderlijk bekeken moesten worden. Hierdoor kwam er aandacht voor
requirements aan de systemen en de eisen die de business daaraan stelt. Deze eisen
werden softwarerequirements genoemd en zijn onder te verdelen in functionele en niet-
functionele softwarerequirements. Hieruit ontstonden soms wel honderden
gedetailleerde requirements waar het overzicht lastig over was te bewaren en waar
gemakkelijk interpretatieverschillen opdoemden.
Businessperspectief
Bij het businessperspectief draait het niet zozeer om de functionaliteit van het systeem,
maar om de bedrijfs- en klantprocessen die het ondersteunt. Het systeem ontleent haar
bestaansrecht aan de toegevoegde waarde die het levert aan de business. Bij het
businessperspectief staan de behoeften van de business aan geautomatiseerde
ondersteuning centraal. Hieruit ontstaan twee type requirements: business- en
gebruikersrequirements. Use cases zijn in de negentiger Jaren uitgegroeid tot een
populaire techniek voor het specificeren van de requirements. Een use case geeft aan
hoe het systeem en de gebruiker samenwerken om een eindresultaat te halen dat
waarde heeft voor de gebruiker.
4
, 1.2. Agile gedachtengoed
Rond de eeuwwisseling is agile (wendbaar, beweeglijk of vlug) softwareontwikkeling
ontstaan. Agile is een reactie op de document- en plangedreven zware
softwareontwikkelmethoden die tot die tijd veel werden gebruikt. Agile maakt het
mogelijk om in te spelen op veranderingen en om te gaan met onzekerheden. Het hele
agile team is er op gericht om zo veel mogelijk waarde te leveren voor de business en
bestaat gewoonlijk uit een product owner, een multidisciplinair ontwikkelteam en een
scrum master. Ze werken in iteraties (sprints) van maximaal vier weken waarin steeds
nieuwe functionaliteit aan het systeem wordt toegevoegd. Aan het einde van iedere
iteratie levert het ontwikkelteam, in technische en bij voorkeur ook in functionele zin,
productierijpe software op. Het team begint met een heel eenvoudige variant van het
systeem en verbeteren en breiden die iteratie na iteratie uit en toetsen ze of de software
voldoet aan de verwachtingen van de belanghebbenden.
Het uitgebreid en nauwkeurig specificeren van requirements aan het begin van het
softwareontwikkeltraject is in agile omgevingen overbodig en onwenselijk. Een
productvisie met het bedrijfsdoel en een opsomming van de voornaamste kenmerken
van het systeem geeft voldoende richting. Gebruikers kunnen namelijk vooraf niet exact
aangeven wat ze nodig hebben. Daarnaast zijn wijzigingen in de requirements
onvermijdelijk vanwege voortschrijdend inzicht en veranderende omstandigheden. Pas
wanneer gebruikers het systeem zien en er mee werken komen ze er achter welke
ondersteuning ze precies nodig hebben. Daarom heeft feedback een belangrijke plaats
binnen agile. De terugkoppeling en de ervaringen met de tot dan toe opgeleverde
software zijn essentiële input voor de requirements op de product backlog. Een backlog
is een geprioriteerde opsomming van de nog uit te werken en te implementeren
requirements. Deze opsomming wordt voortdurend geactualiseerd om in lijn te blijven
met de wijzigende inzichten.
User stories zijn binnen agile veruit de meest gebruikte requirementstechniek. User
stories hebben een vaste zinsopbouw die helpt om de requirements vanuit het
gezichtspunt van de gebruiker te bekijken en de aandacht te richten op de toegevoegde
waarde voor de gebruiker.
Requirements engineering en agile
Hoewel een deel van de requirements engineeringstechnieken ook zeker in een agile
omgeving toepasbaar zijn, is de kern en gedachtegang van het vakgebied requirements
engineering fundamenteel anders dan dat van agile. Of er bij agile nog wel sprake is van
het vakgebied requirements engineering is voor discussie vatbaar.
1.3. Requirementsanalist
De requirementsanalist zorgt er voor dat requirements bij het softwareontwikkelteam
terecht komen. Deze rol wordt impliciet of expliciet genomen. Requirementsanalist staat
ook wel bekend als requirementsengineer, informatieanalist en businessanalist. De
requirementsanalist vervult een brugfunctie tussen de business en het
softwareontwikkelteam. Hij helpt de belanghebbenden uit de business bij het
concretiseren van hun wensen en brengt deze over aan het ontwikkelteam. Dit zijn twee
5
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 RobinKras. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $6.12. You're not tied to anything after your purchase.
