#2 Swart H15 Flashcards
(34 cards)
benoem de 4 kennisgebieden van requirements development
elicitatie
analyse
specificatie
validatie
[de kennisgebieden mogen niet gezien worden als achter elkaar uit te voeren activiteiten]
eliciteren
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]
[elicitatietechnieken]
interviewen
interviewen is een eenvoudige, goedkope en breed toepasbare elicitatietechniek die de RA in iedere processtap toepast.
[elicitatietechnieken]
prototype maken
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
[elicitatietechnieken]
workshops houden
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
voordeel opstartworkshop
[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}
[elicitatietechnieken]
observeren
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
wanneer heeft observeren zonder interactie de voorkeur
als de snelheid en hoeveelheid werk van belang is
wanneer is observeren met interactie beter?
als de RA een gedetailleerd beeld wilt verkrijgen van de werkzaamheden die de mw uitvoert
analyseren
analyseren is het onderzoeken van de gevonden requirements op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid
waar let de RA op bij het analyseren?
- 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
[analysetechniek]
conceptueel modelleren
[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
waar bestaat een CM uit?
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.
[analysetechniek]
prioriteren
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.
[analysetechniek]
prototype
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
verticale prototypen [proof of concept]
is bedoeld om de technische haalbaarheid van bepaalde reqs te onderzoeken
horizontale prototypen
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
[analysetechniek]
categoriseren
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
categoriseren [businessperspectief]
de gedetailleerde reqs zijn opgenomen in use cases. Daarbinnen plaatst de RA de reqs in de basisstroom of in een alternatieve stroom
categoriseren [systeemperspectief]
de functionele softwarerequirements worden geformuleerd als atomaire beweringen en vervolgens worden ze gegroepeerd naar bv. gebruikersobjecten of gebruikersgroepen
categoriseren [niet-functionele reqs]
standaard subcategorieën zijn beschikbaar zoals de ISO 25010
specificatie
specificeren is het vastleggen van reqs en informatie daarover, zodat alle belanghebbenden weten welke reqs overeengekomen zijn
belang specificeren
- verkleint risico dat de reqs van de business verkeerd begrepen worden door de leden van het softwareontwikkelteam
- onderhoudbaarheid vd specificaties
[specificatietechniek]
formuleren
- 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
