Summary
Samenvatting handboek requirements
- Course
- Institution
- Book
Samenvatting handboek requirements. Leidraad voor analisten in agile, traditionele en hybride omgevingen. Geheel herziene druk. Auteur: Nicole de Swart.
[Show more]
Connected book
Book Title:
Author(s):
- Edition:
- ISBN:
- Edition:
3 reviews
By: Jeroen2584 • 1 year ago
By: zhusman • 1 year ago
By: camielzieleman • 2 year ago
Seller
Follow
thomasvandongen
Reviews received
Content preview
Samenvatting Hoofdstuk 1:Vakgebied in beweging
Requirements Engineering = Een discipline binnen de softwareontwikkeling
Voordat een organisatie besluit om een softwareontwikkeling traject te starten is
doorgaans uit een bedrijfs- of een marktonderzoek gebleken dat er behoefte is aan
extra geautomatiseerde ondersteuning
Requirements engineering gaat over het concretiseren van de behoefte van de
business en de gewenste geautomatiseerde ondersteuning daarbij
Het doel van requirements engineering is het tot stand brengen en in stand houden
van overeenstemming tussen opdrachtgever, de overige belanghebbende uit de
business en het softwareontwikkeling team over de requirements
De requirements vanuit de business worden als basis genomen voor de
softwareontwikkeling. Waaruit die uit de behoefte van de business voortkomen.
Daarna wordt er vanuit de requirements een systeem gerealiseerd.
Het gaat bij requirements engineering om het bereiken van overeenstemming tussen de
opdrachtgever, de over belanghebbende uit de business en het softwareontwikkelteam over
de requirements op alle detailniveaus.
Een voorwaarde voor het bereiken van overeenstemming is vanzelfsprekend dat alle
belanghebbenden de requirements goed en op dezelfde manier begrijpen.
Het tot stand brengen van overeenstemming over de requirements staat bekend als
requirements development. Dit resulteert in een verzameling goedgekeurde
requirements, baseline genoemd. De baseline zorgt de basis voor de
softwareontwikkeling.
Daarna is aandacht nodig voor het in standhouden van de overeenstemming. Het
moet mogelijk zijn om de requirements aan te passen wanneer dit nodig is. Het
onderdeel van de requirements engineering dat zich richt op het gecontroleerd
doorvoeren van wijzigingen in de requirements heet requirements management.
Het systeemperspectief
In de jaren zeventig van de vorige eeuw kwam men tot het inzicht dat de gewenste
acties van het systeem en de implementatie daarvan afzonderlijk bekeken moeten
worden
In de eerste twee decennia stonden het systeem en de eisen die de business daaraan
stelt centraal
Deze eisen werden softwarerequirements genoemd en zijn onder te verdelen in
functionele en niet-functionele softwarerequirements
,Het businessperspectief
Met de komst van het businessperspectief verschoof het accent van de
functionaliteit van het systeem naar de bedrijfs-en klantprocessen die het
ondersteunt.
Het systeem ontleent haar bestaansrecht immers aan de toegevoegde waarde die
het levert aan de business.
Het is daarom beter om de requirements vanuit de te ondersteunen processen te
benaderen. Hierdoor blijft de aandacht van het softwareontwikkelteam gericht op de
toegevoegde waarde die het systeem moet leveren.
Bij het business perspectief staan de behoeften van de business aan
geautomatiseerde ondersteuning centraal. Dit perspectief bevat twee typen
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 behalen dat waarde heeft voor de
gebruiker.
Vanaf de jaren negentig gingen veel soctwareontwikkelprojecten use case gedreven
werken. Dit betekent dat alle disciplines binnen het project de use cases als werk- en
communicatie-eenheden gebruiken. Een groot voordeel hiervan is dat alle
betrokkenen, van opdrachtgever en gebruiker tot ontwikkelaars en testers, een
gezamenlijke ‘kapstok’ hebben. Hierdoor werd de samenhang inzichtelijker.
Agile gedachtengoed
De agile aanpak brengt softwareontwikkeling terug tot de kern, namelijk het
ontwikkelen van voor de business waardevolle software
Agile betekent wendbaar, beweeglijk of vlug
Agile softwareontwikkeling maakt het mogelijk in te spelen op veranderingen en om
te gaan met onzekerheden
Het hele agile team is gericht op het leveren van zo veel mogelijk waarde voor de
business
Een agile team bestaat gewoonlijk uit een product owner, een multidisciplinair
ontwikkelteam en een scrum master. Ze werken in iteraties (sprints) van maximaal 4
weken, waarin ze steeds nieuwe functionaliteiten aan het systeem toevoegen.
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 en
bovendien zijn wijzigingen in de requirements onvermijdelijk vanwege
voortschrijdend inzicht en veranderde omstandigheden.
Pas wanneer gebruikers het systeem zien of ermee werken, komen ze erachter welke
geautomatiseerde ondersteuning ze precies nodig hebben!
Hierdoor neemt terugkoppeling op de zojuist ontwikkelde software een belangrijke
plaats in binnen agile. De terugkoppeling en de ervaringen met de tot nu toe
opgeleverde software, zijn essentiële input voor de requirements op de product
backlog.
, Een product backlog is een geprioriteerde opsomming van nog uit te werken en te
implementeren requirements
User stories zijn binnen de agile veruit de meest gebruikte requirementstechniek. Ze
maken het de belanghebbende uit de business en het ontwikkelteam mogelijk om de
requirements op het juiste moment voor iedereen inzichtelijk te maken. 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
Vanwege de grote verschillen in gedachtegang, producten en werkwijze, spreekt dit
boek binnen agile niet over requirements engineering. Het vakgebied requirements
engineering behoudt haar oorspronkelijke betekenis en duidt op een traditionele,
niet-agile omgeving.
Een agile team gaat ervan uit dat zij (en ook de business) nog niet weten aan welke
requirements het uiteindelijke systeem moet voldoen. Bij requirements engineering
probeert de requirementsanalist in een keer de juiste requirements in kaart te
brengen.
De items op een product backlog zijn te beschouwen als geheugensteun voor nog uit
te voeren (requirements)werk. De items in de baseline zijn goedgekeurde
specificaties van requirements die aan kwaliteitscriteria zoals eenduidigheid en
volledigheid moeten voldaan.
Requirementsanalist = iemand die het opstellen van requirements als taak heeft.
De requirementsanalist vervult een brugfunctie tussen de business en het
softwareontwikkelteam. Hij helpt de belanghebbenden uit de business bij het
definiëren van hun requirements en brengt deze over aan het ontwikkelteam.
De rollen bij een agile team:
De scrum master zorgt er als dienend leider voor dat iedereen binnen en buiten het
scrum team de agile principes en regels begrijpt en daarnaar handelt.
De product owner neemt in het kader van de requirements een vooraanstaande
positie in. Hij of zij is verantwoordelijk voor het maximaliseren van de
businesswaarde van het te ontwikkelen systeem en van het ontwikkelteam. Daarmee
is hij verantwoordelijk voor het managen van de product backlog.
Het blijkt vaak lastig om een belanghebbende uit de business te vinden die de rol van
product owner kan en wil vervullen. In dat geval valt de organisatie meestal terug op
een requirementsanalist die dan optreedt als of namens de product owner.
, Samenvatting Hoofdstuk 2:
Typen requirements
Wat is een requirements?
Een requirement is een behoefte aan geautomatiseerde ondersteuning. Bijvoorbeeld
de inkoper wil laten controleren of de voorraad het minimumbestelniveau heeft
bereikt.
Een requirement is een eis die gesteld wordt aan het systeem. De eis geeft aan wat
het gedrag of de kwaliteit van het systeem moet zijn. Bijvoorbeeld het systeem moet
controleren of de voorraad het minimumbestelniveau heeft bereikt (gedrag).
En kan zijn:
Een behoefte van een belanghebbende uit de business om een nieuw of bestaand
proces geautomatiseerd te ondersteunen
Een behoefte van een belanghebbende uit de business om verbeteringen in een
proces te realiseren met behulp van automatisering
Dus samengevat is een requirement:
a) Een behoefte aan geautomatiseerde ondersteuning: een proces of verbetering
daarin, die een belanghebbende uit de business met behulp van het systeem wil
uitvoeren. (Businessperspectief)
b) Een eis aan het systeem: gedrag (functionaliteit) of een kwaliteit die het systeem
moet bezitten om in een behoefte te voorzien van een belanghebbende uit de
business. (Systeemperspectief)
Behoefte aan geautomatiseerde ondersteuning:
Wat? Een proces of activiteit
Waarom? Verbetering in een proces
Eis aan het systeem:
Wat? Gedrag van het systeem
Hoe goed? Kwaliteitskenmerk van het systeem
Wat is een requirement niet?
Het zijn alleen de eisen die gesteld worden aan het gedrag of de kwaliteit van het
systeem om in een behoefte van een belanghebbende uit de business te voorzien.
Andere eisen zijn geen requirements.
Sommige eisen zijn wel belangrijk maar maken deel uit van andere vakgebieden zoals
projectmanagement, testen en technische beperkingen. Maar ook ontwerpbeslissingen.
Requirements moeten in principe oplossingsvrij zijn. Dat wil zeggen dat ze onafhankelijk van
de implementatiewijze zijn gedefinieerd. Anders bestaat de kans dat op voorhand andere,
misschien wel betere, oplossingen worden uitgesloten.
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 thomasvandongen. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $5.34. You're not tied to anything after your purchase.
Can Stuvia be trusted?
4.6 stars on Google & Trustpilot (+1000 reviews)
53068 documents were sold in the last 30 days
Founded in 2010, the go-to place to buy study notes for 14 years now