#3 Swart H17 Flashcards
wat wordt er gedaan met een conceptueel model
er worden uiteenlopende aspecten van de business gemodelleerd
domeinmodel
een domeinmodel is een gestructureerde weergave van de belangrijkste begrippen die in het bedrijfsdomein voorkomen
- het bestaat uit een diagram waarin de relaties tussen de begrippen zijn weergegeven en uit een lijst met definities en het waardebereik van die begrippen
[[UML]] - de RA maakt een eerste versie van dit model aan het begin van het requirementsproces bij de analyse van het bedrijfsdomein -> dit wordt gedurende het proces aangevuld
wanneer wordt een domeinmodel gebruikt
als een begrippenlijst onvoldoende inzicht geeft in met name de relaties tussen de bedrijfsbegrippen
procesmodel
een procesmodel is een gestructureerde weergave van de volgorde waarin de activiteiten uitgevoerd worden
- een procesmodel van de relevante bedrijfsprocessen kan veel inzicht geven in het bedrijfsdomein en in de gewenste ondersteuning van het systeem
[[flowchart & UML-activiteitendiagram]]
wanneer wordt een procesmodel gebruikt
als een tekstuele beschrijving over de business onvoldoende inzicht biedt
use case model
een use case model geeft aan uit welke use cases het systeem bestaat en met welke actoren het systeem interactie heeft.
- het laat de toegevoegde waarde van het systeem voor de business en de afbakening van het systeem zien
- globale gebruikersrequirements worden gewoonlijk gemodelleerd als use cases
[[UML use case diagram]]
wanneer wordt een use case gebruikt
als er use cases onderkend worden
samenhang van de use case stromen
de kern van een use case beschrijving bestaat uit een basisstroom en alternatieve stromen. de samenhang tussen de stromen wordt weergegeven in een flowschema
[[UML activiteitendiagram & flowchart]]
voordeel flowschema
het geeft snel overzicht en het brengt ontbrekende alternatieve stromen of use case stappen aan het licht
wanneer wordt een samenhang van use case stromen gebruikt?
als de beschrijving van de stromen onvoldoende overzicht biedt
prioriteren
verwachtingsmanagement
de juiste vragen stellen
prioriteringstechnieken
prioriteringstechniek
MoSCoW-prioritering
Must have: zonder deze reqs is het systeem onbruikbaar
Should have: hoewel niet wenselijk, is het mogelijks deze reqs achterwege te laten, vaak is er dan een workaround nodig
Could have: deze reqs hebben een duidelijke toegevoegde waarde maar het systeem is ook bruikbaar zonder deze req
Won’t have this time: van deze reqs is afgesproken dat ze niet in de komende release geïmplementeerd zullen worden
prototype
- het systeem niet te goed nabootsen
- het prototype snel aanpassen
- met herkenbare scenario’s en gegevens werken
[kan het beste quick and dirty gebouwd worden]
categoriseren
categoriseren is een analysetechniek waarbij verschillende typen requirements onderkend worden. het is noodzakelijk om af te spreken welke typen dat zijn
Kano model
Kano heeft de producteigenschappen ingedeeld in drie categorieën
satisfiers, dissatisfiers en/of delighters.
Satisfiers (prestatiefactoren)
Dit zijn eigenschappen van een systeem op grond waarvan de klant besluit een systeem te laten maken, te kopen, aan te passen etc.
[prijs, gebruiksduur accu, grootte, gewicht, merk]
De klant gaat met satisfiers bewust op zoek, dit zijn eigenschappen waarvoor geldt dat hoe beter het product eraan voldoet hoe meer de klant tevreden zal zijn. Het ontbreken of het aanwezig zijn van satisfiers heeft een lineair effect op de klanttevredenheid.
Dissatisfiers (basisfactoren)
Dit zijn eigenschappen van een systeem waarvan de klant verwacht dat die als vanzelfsprekend aanwezig zijn. Hoe goed deze eigenschappen ook zijn, de verwachting wordt nooit overtroffen, de klant vindt het normaal dat het product hieraan voldoet. Het ontbreken van een dergelijke eigenschap heeft tot gevolg dat de klanttevredenheid aanzienlijk afneemt.
[bv. standaardfuncties van een telefoon -> camera, browser, de mogelijkheid om apps toe te voegen]
Het lastige van dit soort requirements is dat de klant er niet aan denkt om ze te noemen, hij is zich er latent bewust van, het zijn onderbewuste requirements. Pas als er expliciet naar gevraagd wordt, worden ze genoemd. Alle reden dus om tijdens de elicitatie herhaaldelijk deze categorie aandacht te geven omdat afwezigheid van dissatisfiers de acceptatie van het systeem in gevaar brengt.
Delighters ( factoren)
Dit zijn vernieuwende producteigenschappen waarvan de klant positief verrast zal zijn als die ze opmerkt. Aanwezigheid van dit soort eigenschappen zal de klanttevredenheid sterk doen toenemen, afwezigheid heeft een neutraal effect. De klant is zich niet bewust dat dit soort eigenschappen, het zijn dan ook onbewuste requirements. De klant zal er niet om vragen omdat die er simpelweg niet aan denkt.
