#1 Swart H1 Flashcards
requirements engineering
gaat over het concretiseren van de behoefte van de business en de gewenste geautomatiseerde ondersteuning daarbij
[een discipline binnen systeemontwikkeling]
wat is het doel van requirements engineering?
het tot stand brengen en in stand houden van overeenstemming tussen de opdrachtgever, de overige belanghebbenden uit de business en het softwareontwikkelteam over de requirements
wat is een voorwaarde voor het bereiken van overeenstemming
dat alle belanghebbenden de requirements goed en op dezelfde manier begrijpen
requirements development
het tot stand brengen van overeenstemming over de requirements
-> dit resulteert in een baseline
het draait hierbij om het achterhalen, analyseren, specificeren en valideren van de requirements [kennisgebieden]
baseline
een verzameling goedgekeurde requirements
[basis voor de softwareontwikkeling]
requirements management
onderdeel van requirements engineering dat zich richt op het gecontroleerd doorvoeren van wijzigingen in de requirements
softwarerequirements
het systeem en de eisen die de business daaraan stelt
[functionele en niet-functionele eisen]
[systeemperspectief]
ondanks een requirementsmanagementtool was het lastig om overzicht te houden en de vele individuele requirements in context te plaatsen.
wat was het gevolg hiervan?
er traden gemakkelijk interpretatieverschillen op en de requirements waren moeilijk te valideren
businessperspectief
het accent is gericht op bedrijfs- en klantprocessen ipv de functionaliteit van het systeem
waarom is het beter om de requirements vanuit de te ondersteunen processen te benaderen?
het systeem ontleent haar bestaansrecht immers aan de toegevoegde waarde die het levert aan de business.
welke twee typen requirements staan er centraal bij het businessperspectief?
business- en gebruikersrequirements
use case
een use case geeft aan hoe het systeem en de gebruiker samenwerken om een eindresultaat te halen dat waarde heeft voor de gebruiker.
alle disciplines binnen het project gebruiken de use cases als werk- en communicatie-eenheid
[waarvoor geldt dit?]
- voor de planning en de voortgangsbewaking
- voor het achterhalen en vastleggen van requirements
- voor het ontwerpen
- het ontwikkelen en testen van de software
wat is een voordeel van use case gedreven werken?
alle betrokkenen hebben een gezamenlijke kapstok, iedereen praat over dezelfde dingen
[opdrachtgever, gebruikers, ontwikkelaars, testers]
agile softwareontwikkeling
AS maakt het mogelijk in te spelen op veranderingen en om om te gaan met onzekerheden
waar zorgt de agile aanpak voor?
het brengt softwareontwikkeling terug tot de kern, namelijk het ontwikkelen van voor de business waardevolle software
waar bestaat een agile team uit?
[scrum team]
product owner
multidisciplinair ontwikkelteam
scrum master
[in een agile team is iedereen een gewoon teamlid, er zijn geen vaste rollen]
een agile team werkt in iteraties, wat is de toegevoegde waarde hiervan?
op deze manier wordt er getoetst of de software voldoet aan de verwachtingen van de belanghebbenden en krijgt de opdrachtgever de mogelijkheid om de software vroegtijdig in gebruik te nemen
wat geeft voldoende richting voor een agile team
een productvisie met het bedrijfsdoel en een opsomming van de voornaamste kenmerken van het systeem
product backlog
een product backlog in een geprioriteerde opsomming van nog uit te werken en te implementeren requirements
wanneer vindt het uitwerken van de in de product backlog opgesomde requirements plaats?
kort voor de iteratie waarin het ontwikkelteam ze nodig heeft
waar zorgen user stories voor
[requirementstechniek]
ze maken het de belanghebbenden uit de business en het ontwikkelteam mogelijk om de requirements op het juiste moment voor iedereen inzichtelijk te maken
waar is de requirementsanalist verantwoordelijk voor
- voor het vullen van de baseline met eenduidig gespecificeerde en goedgekeurde requirements
- voor het beheer ervan
[mogen niet gewijzigd worden]
wat maakt integraal onderdeel uit van het agile proces
requirements
testen
waarom wordt binnen agile niet over requirements engineering gesproken?
vanwege de grote verschillen in gedachtegang, producten en werkwijze
[requirementsmanagement]
waarom kunnen niet alle wijzigingsverzoeken doorgevoerd worden?
iedere wijziging kost veel tijd en geld
[een zorgvuldige kosten-baten afweging is noodzakelijk]
bij agile zit het achterhalen van requirements veel meer verweven in het ontwikkelproces, wat is het streven?
het streven is niet om meteen de juiste requirements te vinden, maar om gaandeweg het traject steeds beter zicht te krijgen op de werkelijke behoefte van de business
noem het verschil tussen een agile team en requirements engineering
een agile team gaat ervan uit dat zij nog niet weten aan welke requirements het uiteindelijke systeem moet voldoen.
bij requirements engineering probeert de requirementsanalist in 1 keer de juiste requirements in kaart te brengen
noem het verschil tussen de product backlog en de baseline
de items op een product backlog zijn te beschouwen als een geheugensteun voor nog uit te voeren werk. [agile]
de items in de baseline zijn goedgekeurde specificaties van requirements die aan kwaliteitscriteria zoals eenduidigheid en volledigheid moeten voldoen [requirements engineering]
requirements engineer
[andere begrippen]
requirementsanalist, requirementsmanager, informatieanalist, businessanalist
[het opstellen van requirements als taak]
requirementsanalist
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.
hij weet welke informatie het ontwikkelteam nodig heeft om een systeem te realiseren. hij zoekt samen met de belanghebbenden uit de business naar de behoeften die zij hebben aan geautomatiseerde ondersteuning
[verantwoordelijk voor de overeenstemming tussen deze twee groepen]
scrum master
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
product owner
verantwoordelijk voor wat er ontwikkeld gaat worden en in welke volgorde.
De product owner werkt samen met interne en externe stakeholders om de product backlog items te verzamelen en te definiëren.
de product owner is verantwoordelijk voor het maximaliseren van de businesswaarde van het te ontwikkelen systeem en van het werk van het ontwikkelteam
[neemt in het kader van requirements een vooraanstaande positie]
- verantwoordelijk voor het managen van de product backlog
- combinatie van productmanager, projectmanager, requirementsanalist
- zijn doel is om een bedrijfsprobleem op te lossen/ commerciële kans benutten
- hij draagt zijn visie uit, stelt prioriteiten, neemt beslissingen, managet de verwachtingen en maakt helder wat het te ontwikkelen systeem moet kunnen
hybride omgeving
combinatie van agile en traditionele werkwijze
[hybride omgeving]
wie maakt de requirements helder en wie bereidt de iteraties voor?
requirementsanalisten
[hybride omgeving]
als requirementanalisten te ver doorgaan met de requirements en er geen rechtstreeks contact is tussen de business en het ontwikkelteam, is er weer sprake van een brugfunctie.
welke nadelen komen hierbij kijken?
- minder begrip en betrokkenheid van het ontwikkelteam
- informatie gaat verloren en interpretatieverschillen zijn onontkoombaar
Development team
verantwoordelijk voor het bepalen hoe te leveren wat de product owner heeft gevraagd.
