#3 Swart H4

Question 1

gebruikersrequirement

Answer 1

een gebruikersrequirement is een proces dat de gebruiker mbv het systeem wil uitvoeren

De focus ligt op het leveren van toegevoegde waarde aan de gebruikers en aan de klanten

Question 2

wat zijn voordelen van het businessperspectief

Answer 2

• de toegevoegde waarde die het systeem moet leveren bij alle ontwikkelteamleden onder de aandacht blijft
• het achterhalen van de reqs verloopt soepeler. De gebruikers hoeven niet meer te redeneren vanuit het systeem en de functionaliteit die het systeem moet bieden (systeemperspectief), maar vanuit de processen en activiteiten die ze willen uitvoeren met de ondersteuning van het systeem (businessperspectief)

Question 3

use case

Answer 3

een use case is een verzameling gedetailleerde (software + gebruikers)-reqs die samen een logisch geheel vormen van opeenvolgende acties die leiden tot een resultaat dat waarde heeft voor de gebruiker

Question 4

procestaak

Answer 4

een procestaak is een verzameling activiteiten, die samen een afgerond geheel vormen en door dezelfde persoon op een bepaald moment in 1 keer worden uitgevoerd

Question 5

actor

Answer 5

de rol die iets of iemand vervult als hij interacteert met het systeem

Question 6

primaire actor

Answer 6

een actor die waarde hecht aan het resultaat van een use case. het systeem ondersteunt de werkzaamheden van deze actoren (secundaire actoren helpen daarbij)

Question 7

actor + use cases

Answer 7

een actor bevindt zich buiten het systeem en use cases bevinden zich binnen de systeemgrenzen

Question 8

verschil use cases en user stories

Answer 8

use cases - schriftelijk
user stories - mondeling

beide hebben hetzelfde doel, namelijk de gebruikersreqs communiceren aan de ontwikkelaars en testers

Question 9

er zijn 2 stromingen voor de specificatiewijze van de use cases, welke twee

Answer 9

• beknopte use case beschrijvingen

- volledige use case beschrijvingen

Question 10

beknopte use case beschrijvingen

Answer 10

deze stroming richt de use case beschrijvingen primair op de gebruikers. de RA beschrijft alleen het voor de gebruiker zichtbare gedrag

• samenwerking tussen gebruiker en systeem blijft relatief eenvoudig en bevat weinig details

Question 11

nadeel beknopte use case beschrijving

Answer 11

het verhaal over de samenwerking tussen gebruiker en systeem is niet volledig. een groot deel van het systeemgedrag zit verborgen in een separate opsomming van softwarereqs

Question 12

volledige use case beschrijving

Answer 12

deze stroming richt de use case beschrijvingen op de gebruikers en tevens op ontwikkelaars en testers.

• alle gebruikers- en softwarereqs die nodig zijn om het eindresultaat van de use case te halen zijn beschreven
• bevat gedetailleerde informatie
• • de use case techniek is ontstaan om de specificatie van de reqs voor alle doelgroepen begrijpelijk te maken

Question 13

nadeel volledige use case beschrijving

Answer 13

het vergt enige oefening voordat een RA leesbare en overzichtelijke beschrijvingen kan maken

Question 14

wie zijn bronnen voor gebruikersreqs

Answer 14

stakeholders uit de business, klanten of leveranciers

Question 15

waar moet op gelet worden bij user stories

Answer 15

de definitie van een user story geldt alleen voor correct geformuleerde user stories die binnen de scope van het systeem vallen.
- in de praktijk wordt er te makkelijk aangenomen dat elke user story die een gebruiker formuleert ook daadwerkelijk meegenomen moet worden als requirement -

Question 16

Het specificeren vanuit het business perspectief:

Answer 16

er moet uitgegaan worden van een procestaak uit de business, bijvoorbeeld een activiteit of proces binnen een BPMN model. Een ideale omvang van een use case is als deze afgestemd is op zo’n procestaak.