#1 Swart H1 Flashcards

1
Q

requirements engineering

A

gaat over het concretiseren van de behoefte van de business en de gewenste geautomatiseerde ondersteuning daarbij

[een discipline binnen systeemontwikkeling]

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

wat is het doel van requirements engineering?

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

wat is een voorwaarde voor het bereiken van overeenstemming

A

dat alle belanghebbenden de requirements goed en op dezelfde manier begrijpen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

requirements development

A

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]

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

baseline

A

een verzameling goedgekeurde requirements

[basis voor de softwareontwikkeling]

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

requirements management

A

onderdeel van requirements engineering dat zich richt op het gecontroleerd doorvoeren van wijzigingen in de requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

softwarerequirements

A

het systeem en de eisen die de business daaraan stelt

[functionele en niet-functionele eisen]

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

[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?

A

er traden gemakkelijk interpretatieverschillen op en de requirements waren moeilijk te valideren

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

businessperspectief

A

het accent is gericht op bedrijfs- en klantprocessen ipv de functionaliteit van het systeem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

waarom is het beter om de requirements vanuit de te ondersteunen processen te benaderen?

A

het systeem ontleent haar bestaansrecht immers aan de toegevoegde waarde die het levert aan de business.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

welke twee typen requirements staan er centraal bij het businessperspectief?

A

business- en gebruikersrequirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

use case

A

een use case geeft aan hoe het systeem en de gebruiker samenwerken om een eindresultaat te halen dat waarde heeft voor de gebruiker.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

alle disciplines binnen het project gebruiken de use cases als werk- en communicatie-eenheid
[waarvoor geldt dit?]

A
  • voor de planning en de voortgangsbewaking
  • voor het achterhalen en vastleggen van requirements
  • voor het ontwerpen
  • het ontwikkelen en testen van de software
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

wat is een voordeel van use case gedreven werken?

A

alle betrokkenen hebben een gezamenlijke kapstok, iedereen praat over dezelfde dingen
[opdrachtgever, gebruikers, ontwikkelaars, testers]

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

agile softwareontwikkeling

A

AS maakt het mogelijk in te spelen op veranderingen en om om te gaan met onzekerheden

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

waar zorgt de agile aanpak voor?

A

het brengt softwareontwikkeling terug tot de kern, namelijk het ontwikkelen van voor de business waardevolle software

17
Q

waar bestaat een agile team uit?

[scrum team]

A

product owner
multidisciplinair ontwikkelteam
scrum master

[in een agile team is iedereen een gewoon teamlid, er zijn geen vaste rollen]

18
Q

een agile team werkt in iteraties, wat is de toegevoegde waarde hiervan?

A

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

18
Q

wat geeft voldoende richting voor een agile team

A

een productvisie met het bedrijfsdoel en een opsomming van de voornaamste kenmerken van het systeem

19
Q

product backlog

A

een product backlog in een geprioriteerde opsomming van nog uit te werken en te implementeren requirements

20
Q

wanneer vindt het uitwerken van de in de product backlog opgesomde requirements plaats?

A

kort voor de iteratie waarin het ontwikkelteam ze nodig heeft

21
Q

waar zorgen user stories voor

A

[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

22
Q

waar is de requirementsanalist verantwoordelijk voor

A
  • voor het vullen van de baseline met eenduidig gespecificeerde en goedgekeurde requirements
  • voor het beheer ervan
    [mogen niet gewijzigd worden]
23
Q

wat maakt integraal onderdeel uit van het agile proces

A

requirements

testen

24
Q

waarom wordt binnen agile niet over requirements engineering gesproken?

A

vanwege de grote verschillen in gedachtegang, producten en werkwijze

25
Q

[requirementsmanagement]

waarom kunnen niet alle wijzigingsverzoeken doorgevoerd worden?

A

iedere wijziging kost veel tijd en geld

[een zorgvuldige kosten-baten afweging is noodzakelijk]

26
Q

bij agile zit het achterhalen van requirements veel meer verweven in het ontwikkelproces, wat is het streven?

A

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

27
Q

noem het verschil tussen een agile team en requirements engineering

A

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

28
Q

noem het verschil tussen de product backlog en de baseline

A

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]

29
Q

requirements engineer

[andere begrippen]

A

requirementsanalist, requirementsmanager, informatieanalist, businessanalist

[het opstellen van requirements als taak]

30
Q

requirementsanalist

A

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]

31
Q

scrum master

A

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

32
Q

product owner

A

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
33
Q

hybride omgeving

A

combinatie van agile en traditionele werkwijze

34
Q

[hybride omgeving]

wie maakt de requirements helder en wie bereidt de iteraties voor?

A

requirementsanalisten

35
Q

[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?

A
  • minder begrip en betrokkenheid van het ontwikkelteam

- informatie gaat verloren en interpretatieverschillen zijn onontkoombaar

36
Q

Development team

A

verantwoordelijk voor het bepalen hoe te leveren wat de product owner heeft gevraagd.