Auteur: Nicole de Swart
Samenvatting door Lucas Vonk
, Hoofdstuk 1: Vakgebied in beweging.
Kern: Binnen requirements engineering draait het om het vaststellen van een baseline met
goedgekeurde requirements. De product back log in agile is meer een actielist, een
opsomming van nog uit te werken en met behulp van werkende software te valideren
requirements. Het streven is niet om meteen de juiste requirements te vinden, maar om
gaandeweg het traject steeds beter zicht te krijgen op de werkelijke gebruikersbehoeften.
Uitwerking:
Requirements engineering is het vakgebied dat zich bezighoudt met het tot stand bren-
gen en in stand houden van overeenstemming tussen de opdrachtgever, de overige
belanghebbenden uit de business en het software-ontwikkelteam over de requirements.
Het vakgebied is onder te verdelen in requirements development (het tot stand bren-
gen) en requirements management (het in stand houden van de overeenstemming).
In de jaren zeventig en tachtig lag de focus op de eisen die de business stelt aan
het systeem. Dit zijn de functionele en niet-functionele softwarerequirements. Daarna
verschoof de aandacht naar de bedrijfs- en klantprocessen die het systeem moest
ondersteunen. Hierdoor ontstonden de business- en gebruikersrequirements. Deze
verschuiving van het systeem- naar het businessperspectief werd gevolgd door een nieuwe,
agile manier van softwareontwikkeling, Vanaf toen was een softwareontwikkeltraject
volledig gericht op het ontwikkelen van voor de business waardevolle software.
Hoewel een deel van de requirements engineeringstechniek ook zeker in een
agile omgeving toepasbaar zijn, is de kern en gedachtegang van het vakgebied requirements
engineering fundamenteel anders dan dat van agile. Daarom 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.
De requirementsanalist vervult binnen requirements engineering een brugfunctie tussen de
business en het software-ontwikkelteam. Hij helpt de belanghebbenden uit de
business bij het definiëren van hun requirements en brengt deze over aan het
ontwikkelteam. Binnen agile is de rol van requirementsanalist niet expliciet onderkend. De
product owner is verantwoordelijk voor het managen van de product back log. Het opstellen
van de requirements daarin mag hij grotendeels laten uitvoeren door het multidisciplinaire
ontwikkelteam. Daarin moeten ook de vaardigheden van een requirementsanalist
vertegenwoordigd zijn.
Deel I van dit boek gaat in op het begrip requirements en licht de verschillende typen
requirements toe.
, Hoofdstuk 2: Requirementsperspectieven
Kern:
De verschillende typen requirements zijn weergegeven in het requirementsmodel. Dit model
bestaat uit het systeemperspectief, met daarin de softwarerequirements, en het
businessperspectief, met daarin de businessrequirements en de gebruikersrequirements.
Uitwerking:
De letterlijke betekenis van de term requirement is a) behoefte of b) eis. Sommige
requirements zijn behoeften van de business aan geautomatiseerde ondersteuning en
andere requirements zijn eisen aan het gedrag of de kwaliteit van het systeem.
Het systeemperspectief benadert de requirements vanuit het systeem en de eisen die de
business daaraan stelt. Tet systeemperspecticf bevat functionele en niet-functionele
softwarerequirements. Dit is achtereenvolgens gedrag en kwaliteit die het systeem moet
bezitten om in de behoeften te voorzien van de belanghebbenden uit de business.
Bij het businessperspectief staan de behoeften van de business centraal om processen te
ondersteunen met geautomatiseerde systemen. Het businessperspectief voegt
aan het systeemperspectief toe ‘waarom’ het systeem gewenst is en ‘wat’ voor proces of
activiteit het systeem moet ondersteunen. Dit zijn achtereenvolgens de business- en de
gebruikersrequirements. Businessrequirements geven aan welke toegevoegde waarde
het systeem moet leveren aan de business. Gebruikersrequirements geven aan welke
werkzaamheden door het systeem uitgevoerd of ondersteund moeten worden.
Het volgende hoofdstuk beschrijft businessrequirements en bedrijfsdoelen die de
belanghebbenden uit de business met het systeem willen behalen.
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, creditcard of Stuvia-tegoed voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper lucasvonk. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €3,99. Je zit daarna nergens aan vast.