Samenvatting: Handboek requirements
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.
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.
