#2 Swart H15 Flashcards

1
Q

benoem de 4 kennisgebieden van requirements development

A

elicitatie
analyse
specificatie
validatie

[de kennisgebieden mogen niet gezien worden als achter elkaar uit te voeren activiteiten]

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

eliciteren

A

eliciteren van reqs is te beschouwen als een ontdekkingstocht waarin de bewuste en onbewuste reqs van de belanghebbenden expliciet worden gemaakt

[RA moet helpen met de gedachtevorming van de belanghebbenden, noteren is niet genoeg]

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

[elicitatietechnieken]

interviewen

A

interviewen is een eenvoudige, goedkope en breed toepasbare elicitatietechniek die de RA in iedere processtap toepast.

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

[elicitatietechnieken]

prototype maken

A

een prototype is geschikt om de details van de gewenste systeemondersteuning te achterhalen.

met een prototype visualiseert de requirementsanalist het nieuwe systeem en de nieuwe werkwijze mbv voorbeeldschermen

  • prototype kan leiden tot nieuwe inzichten en reqs waar ze nog niet eerder aan hadden gedacht
  • kritiek/ reageren op iets tastbaars is eenvoudiger dan zelf iets nieuws bedenken
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

[elicitatietechnieken]

workshops houden

A

requirementsworkshops zijn vooral effectief wanner een specifiek onderwerp vanuit verschillende gezichtspunten bekeken moet worden of wanneer er grote meningsverschillen over bestaan

  • er ontstaat een gezamenlijk beeld van de problematiek en van de mogelijke oplossingen
  • verassende ideeën kunnen worden opgeleverd over de ondersteuning die het systeem moet bieden aan de gebruikers
  • complexe use cases kunnen worden uitgewerkt
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

voordeel opstartworkshop

A

[uitsluitend interviews]

  • de voornaamste belanghebbenden zijn tegelijkertijd aanwezig; ze leren elkaar en elkaars belangen kennen. Ze bereiken overeenstemming over de toegevoegde waarde die het project moet leveren en over de wijze waarop ze daar allemaal aan gaan bijdragen.
    {positief effect op de toekomstige samenwerking en het bevordert de onderlinge communicatie}
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

[elicitatietechnieken]

observeren

A

deze techniek wordt door de RA voornamelijk gebruikt bij het detailleren van de requirements.

  • door medewerkers de observeren bij het uitvoeren van de dagelijkse werkzaamheden krijgt de RA detailinformatie en begrijpt hij het werk van de toekomstige gebruikers
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

wanneer heeft observeren zonder interactie de voorkeur

A

als de snelheid en hoeveelheid werk van belang is

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

wanneer is observeren met interactie beter?

A

als de RA een gedetailleerd beeld wilt verkrijgen van de werkzaamheden die de mw uitvoert

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

analyseren

A

analyseren is het onderzoeken van de gevonden requirements op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid

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

waar let de RA op bij het analyseren?

A
  • de consistentie van de reqs
  • de volledigheid van de totale verzameling reqs
  • de juistheid van de individuele reqs
  • de prioriteit van de reqs onderling
  • de technische en financiele haalbaarheid van de reqs
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

[analysetechniek]

conceptueel modelleren

A

[zowel een analyse- als een specificatietechniek]

  • duidelijke informatieoverdracht

conceptuele modellen geven een gestructureerde en visuele weergave van een bepaald aspect van de business. dit aspect is bv het bedrijfsproces, de gewenste geautomatiseerde ondersteuning of de bedrijfsobjecten.

  • bij CM gaat het niet om de interne werking van het systeem. Het is aan de softwarearchitect en de ontwikkelaars om de structuur van de software te ontwerpen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

waar bestaat een CM uit?

A

een model bestaat uit een visuele weergave, het diagram, en een tekstuele beschrijving die het geheel toelicht. Door modellen te maken van essentiele aspecten van de business, is inconsistentie, onvolledige en onjuiste informatie eenvoudiger te vinden.

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

[analysetechniek]

prioriteren

A

reqs met een hoge prioriteit zijn belangrijker voor de business en leveren een grotere bijdrage aan het behalen van de businessrequirements dan reqs met een lagere prioriteit.

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

[analysetechniek]

prototype

A

prototypen maken is een krachtig middel om ontbrekende en incorrecte reqs te achterhalen

  • de technische haalbaarheid van specifieke reqs onderzoeken
  • nieuwe inzichten of nieuwe/gewijzigde reqs
  • kan behulpzaam zijn bij het definiëren van het gewenste eindresultaat en bij het detailleren van de reqs
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

verticale prototypen [proof of concept]

A

is bedoeld om de technische haalbaarheid van bepaalde reqs te onderzoeken

17
Q

horizontale prototypen

A

een horizontaal prototype laat het gedrag van het systeem zien aan de hand van een reeks voorbeeldschermen zonder dat de achterliggende software is ontwikkeld
[ de gebruiker krijgt een goed beeld van de werking van het systeem ]

  • dit levert goede feedback op. Het is een goed middel om nieuwe reqs te eliciteren, eerder gevonden reqs te toetsen en om ontbrekende reqs te achterhalen.

[onmisbaar bij het ontwerpen van een userinterface]
- de nadruk ligt op het gedrag van het systeem of op de gegevens op de schermen

18
Q

[analysetechniek]

categoriseren

A

het onderverdelen van reqs in groepen of typen.
Door de reqs te categoriseren is eenvoudiger te zien of een bepaald type req onder- of oververtegenwoordigd is en of de reqs van hetzelfde type onderling consistent zijn

19
Q

categoriseren [businessperspectief]

A

de gedetailleerde reqs zijn opgenomen in use cases. Daarbinnen plaatst de RA de reqs in de basisstroom of in een alternatieve stroom

20
Q

categoriseren [systeemperspectief]

A

de functionele softwarerequirements worden geformuleerd als atomaire beweringen en vervolgens worden ze gegroepeerd naar bv. gebruikersobjecten of gebruikersgroepen

21
Q

categoriseren [niet-functionele reqs]

A

standaard subcategorieën zijn beschikbaar zoals de ISO 25010

22
Q

specificatie

A

specificeren is het vastleggen van reqs en informatie daarover, zodat alle belanghebbenden weten welke reqs overeengekomen zijn

23
Q

belang specificeren

A
  • verkleint risico dat de reqs van de business verkeerd begrepen worden door de leden van het softwareontwikkelteam
  • onderhoudbaarheid vd specificaties
24
Q

[specificatietechniek]

formuleren

A
  • in de eerste twee stappen van het requirementsproces is de beschrijving bedoeld om de belanghebbenden snel inzicht te geven in de bedrijfscontext en in de gekozen oplossing
  • een nadere uitwerking en meer toelichting volgen later bij het detailleren van reqs
    • een korte onderbouwing van de gemaakte keuzes mag niet ontbreken
  • de formulering bepaalt voor het grootste deel of de reqs door de belanghebbenden begrepen en correct geïnterpreteerd worden
25
Q

[specificatietechniek]

tekst structureren

A
  • door het aanbrengen van structuur is informatie eenvoudiger over te dragen
26
Q

[specificatietechniek]

requirementspatroon toepassen

A

een requirementspatroon is een blauwdruk voor het specificeren van een veelvoorkomend req of een veelvoorkomende specificatiewijze. Ook bestaat het uit een toelichting en voorbeelden.

[de toelichting geeft aan in welke situatie het patroon toepasbaar is, welke informatie noodzakelijk is, wat de valkuilen (anti-patterns) zijn en welke aanvullende reqs mogelijk relevant zijn]

requirementspatronen helpen de RA bij het volledig en juist specificeren van gedetailleerde reqs.

27
Q

validatie

A

valideren is het zekerstellen dat de gespecificeerde reqs overeenkomen met de behoeften van de business en voldoen aan de overige kwaliteitseisen.

  • of de eisen en behoeften van de business correct zijn verwoord kunnen alleen de belanghebbenden uit de business zelf valideren
  • of de specificaties exact genoeg zijn om als basis voor de realisatie en voor het testen te dienen kan alleen het ontwikkelteam verifiëren.
28
Q

[validatietechniek]

reviewen

A

de RA vraagt de belanghebbenden de specificaties kritisch te lezen en onjuistheden/onduidelijkheden te signaleren.

29
Q

informele review

A

de RA heeft informele reviews nodig om de kwaliteit van zijn specificaties te verbeteren.

  • informeel reviewen doet een RA door bv. na een interview zijn conclusies schriftelijk terug te koppelen aan zijn gesprekspartner
  • aan te bevelen om de specificaties meerdere malen te laten reviewen door collega-RA, softwarearchitect, ontwikkelaars & testers
30
Q

formele review

A

het goedkeuren van een product gebeurt na een formele review

  • de goedkeuring wordt gevraagd aan de voornaamste belanghebbenden
  • hierbij is een kwaliteitsmedewerker betrokken die valideert of het product aan de afgesproken standaarden voldoet
  • de inhoudelijke beoordeling wordt door de belanghebbenden uit de business en door de leden van het ontwikkelteam gedaan.
31
Q

[validatietechniek]

inspecteren

A

inspecteren is een formeel proces waarin de deelnemers tijdens een inspectiebijeenkomst zoveel mogelijk fouten in de specificaties opsporen.

  • een voor een worden de reqs gezamenlijk besproken
  • hiermee komen interpretatieverschillen aan het licht +
32
Q

inspecteren

wie nemen deel hieraan?

A

ontwikkelaar, tester, collega-RA, softwarearchitect, kwaliteitsmedewerker

33
Q

[validatietechniek]

doorspreken

A

de RA leidt de belanghebbenden al pratende door de te valideren specificaties

  • 1 of meer bijeenkomsten waarin de belanghebbenden direct reageren op de reqs
  • deze techniek is vooral bedoeld voor de belanghebbenden uit de business die niet gewend zijn om tekstuele specificaties en conceptuele modellen te lezen [deze techniek heeft de voorkeur]
34
Q

[validatietechniek]

testcases opstellen

A
  • deze techniek is geschikt voor het verhogen van de kwaliteit van de gedetailleerde specificaties

bij het opstellen van testcases en acceptatiecriteria wordt inzichtelijk welke reqs niet volledig/ eenduidig/ consistent zijn gespecificeerd

de RA en de tester werken deels parallel aan de gedetailleerde reqs en de testcases.