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
Les avantages d'acheter des résumés chez Stuvia:
Qualité garantie par les avis des clients
Les clients de Stuvia ont évalués plus de 700 000 résumés. C'est comme ça que vous savez que vous achetez les meilleurs documents.
L’achat facile et rapide
Vous pouvez payer rapidement avec iDeal, carte de crédit ou Stuvia-crédit pour les résumés. Il n'y a pas d'adhésion nécessaire.
Focus sur l’essentiel
Vos camarades écrivent eux-mêmes les notes d’étude, c’est pourquoi les documents sont toujours fiables et à jour. Cela garantit que vous arrivez rapidement au coeur du matériel.
Foire aux questions
Qu'est-ce que j'obtiens en achetant ce document ?
Vous obtenez un PDF, disponible immédiatement après votre achat. Le document acheté est accessible à tout moment, n'importe où et indéfiniment via votre profil.
Garantie de remboursement : comment ça marche ?
Notre garantie de satisfaction garantit que vous trouverez toujours un document d'étude qui vous convient. Vous remplissez un formulaire et notre équipe du service client s'occupe du reste.
Auprès de qui est-ce que j'achète ce résumé ?
Stuvia est une place de marché. Alors, vous n'achetez donc pas ce document chez nous, mais auprès du vendeur RobinKras. Stuvia facilite les paiements au vendeur.
Est-ce que j'aurai un abonnement?
Non, vous n'achetez ce résumé que pour €5,49. Vous n'êtes lié à rien après votre achat.
