Samenvatting Hoofdstuk 1:

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 1 / 4

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. 2 / 4

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. 3 / 4

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.

• / 4