Resume
Functional Analysis Samenvatting HoGent
- Cours
- Functional Analysis
- Établissement
- Hogeschool Gent (HoGent)
Samenvatting van het vak Functional Analysis, in het 2de bachelor van het traject Toegepaste Informatica (TI)
[Montrer plus]
Aperçu du contenu
Functional AnalysisTom De Bakker
11/11/2024
1
,Inhoudstafel
Functional Analysis 3
0.1 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
0.2 Voorbeeld examen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1 Hoofdstuk 1: Inleiding 4
2 Hoofdstuk 2: Functionele Requirements 5
2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Use case diagram - Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Use case diagram - Extend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Elementair business proces (/use case) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3 Onderdelen use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.4 Tips, tricks en vaakgemaakte fouten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.5 Template voor opstellen van use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.6 Voorbeelden opstellen van use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Hoofdstuk 3: Niet-functionele Requirements 17
3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Soorten niet-functionele requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Niet-functionele requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1 Template/sjabloon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.2 S.M.A.R.T. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Oefeningen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Hoofdstuk 4: Usability Testing 24
4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Meten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Formatief testen - usability testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Summatief testen - usability testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4.1 SUS methode (System Usability Scale) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 In de praktijk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6 Voorbereiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6.1 Usability Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6.2 Persona’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6.3 Key tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6.4 Scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6.5 Mock-ups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Hoofdstuk 5: Ontwikkelstrategieën 29
5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.1 Regels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.2 Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 KanBan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2
,0.1 Evaluatie INHOUDSTAFEL
Functional Analysis
0.1 Evaluatie
• 30% niet-periode gebonden, ontwerp - Casus (zie evaluatiekaart Chamilo)
∘
Score van deze taak kan overgedragen worden uit EP1 naar EP3
• 70% periode gebonden, schriftelijk examen (gesloten boek)
0.2 Voorbeeld examen
• Je krijgt een test van iemand die usability testen van de moderator en de gebruiker, je krijgt de conversatie.
Uit die conversatie moet je een use case bouwen (bij Software Analysis kreeg je de use cases al). Da staat
op de helft van u punten.
• 1/4 de van de punten staat op Scrum, theorie vragen.
• 1 oefening is een tekening. Uitleggen wat deze figuur is en woordjes aanvullen (stond op 12 punten).
3
, 1 HOOFDSTUK 1: INLEIDING
1 Hoofdstuk 1: Inleiding
Nothing of note
4
, 2 HOOFDSTUK 2: FUNCTIONELE REQUIREMENTS
2 Hoofdstuk 2: Functionele Requirements
2.1 Inleiding
Requirements of behoeften: zijn de eisen van de klant waaraan een product moet voldoen. Er bestaan
2 soorten functionele requirements en niet-functionele requirements. Deze functionaliteiten zullen we
vastleggen en éénduidig definiëren in use cases.
2.2 Use case diagram
Een use case diagram bevat:
• Alle functionele requirements (functionaliteiten/use cases).
• Overzicht van alle rollen die toegang hebben tot het systeem.
• Welke rol welke functionaliteit kan gebruiken.
2.2.1 Use case diagram - Include
Als we voor het uitvoeren van een bepaalde functionaliteit altijd een andere nodig hebben, gebruiken we
include .
Figure 1: Use Case Diagram - Include
2.2.2 Use case diagram - Extend
Als een functionaliteit soms nood heeft aan een andere bij het uitvoeren gebruiken we extends .
Figure 2: Use Case Diagram - Extend
Voorbeeld:
5
,2.3 Use cases 2 HOOFDSTUK 2: FUNCTIONELE REQUIREMENTS
Figure 3: Voorbeeld van include en extend
2.3 Use cases
2.3.1 Inleiding
Een use case bevat het uitgeschreven verhaal van een primary actor die het systeem zal gebruiken om een
bepaald doel te bereiken.
Een use case is een visie op het systeem met een bepaalde scope, afgebakend doel, waarin bepaalde be-
langhebbende partijen in interactie treden met het systeem om dat welbepaalde doel te bereiken. Deze verhalen
zijn ook kort van aard.
Hoe weten we nu welke verhalen we gaan uitwerken als use case? Daarvoor gaan we op zoek naar de elementaire
business processen die een user goal voorstellen. µ
2.3.2 Elementair business proces (/use case)
Elementaire business processen zijn op de te delen in drie verschillende categorieën. Enerzijds hebben we hogere
doelen van een bedrijf die een verzameling zijn van aparte doelen. Dit noemen we “summary goals”.
• Higher level - WAAROM doet de primary actor dit?
• User’s goal - WAT wil de primary actor?
• Lower level - HOE?
Een goede use case bestaat uit 3 tot 15 stappen. Een “stap” is afaik een synoniem voor lower level.
Een higher level is dus een verzameling van verschillende “doelen” of user goals.
Door te kijken naar deze hoe, wat en waarom kunnen we bepalen of iets al dan niet een lower level, user’s
goal of higher level is.
Figure 4: Niveaus elementaire business processen
As for/om te weten hoe we bepalen dat zo iets een user’s goal is kunnen we ook nog kijken naar:
• Proces door 1 persoon
• 2 à 20 minuten
6
,2.3 Use cases 2 HOOFDSTUK 2: FUNCTIONELE REQUIREMENTS
Figure 5: Oefening elementaire business processen
2.3.2.1 Oefeningen Voorbeeld (te hoog):
Een verkoopscontract binnenhalen is een te hoog niveau, is geen elementair business proces.
Ik wil een verkoopscontract binnenhalen. Om dat te doen moet ik met de manager gaan lunchen. Om dat te
doen moet ik geld halen van de rekening. Om dat te doen moet ik mij kenbaar maken. Om dat te doen moet ik
mijn bankkaart hebben en moet mijn bankkaart ingelezen worden. Om dat te doen moet ik …
Voorbeeld (te laag):
De tab toets vinden is te laag, dat is juist één specifieke stap binnen een use case AKA elementair business
proces.
Ik wil de tab-toets vinden zo dat ik de cursor kan plaatsen in het adresveld, zo kan ik mijn adres ingeven, zodat ik
mijn persoonlijke gegevens kan ingeven in het pakket. Zo kan ik een aanvraag indienen voor een autoverzekering,
zo kan ik mijn auto verzekeren, dan kan ik met mijn auto rijden
• Actor: Technieker
• Goals:
∘ Geldautomaat laten werken
■ High-level, want is “waarom”
∘ Laat zelftest op geldautomaat lopen
■ User goal, want is “wat”
.
• Actor: Klant
• Goals:
∘ Gebruik geldautomaat
■ High-level, want is “waarom”, het is “algemeen”
∘ Haal geld af
■ User goal, want is “wat”
∘ Schrijf geld over
■ User goal, want is “wat”
∘ Vraag saldo op
■ User goal, want is “wat”
2.3.3 Onderdelen use case
Een use case bestaat uit:
• Primary actor
• Stakeholders
• Precondities
• Postcondities
• Normaal verloop
• Alternatief verloop
• Domeinspecifieke regels
• Op te klaren punten (optioneel)
7
,2.3 Use cases 2 HOOFDSTUK 2: FUNCTIONELE REQUIREMENTS
2.3.3.1 Primary actor & stakeholders De primary actor is de belanghebbende partij die een function-
aliteit wenst uit te voeren op het systeem, deze activeert dus de use case/functionaliteit.
Stakeholders zijn belanghebbende/deelnemende partijen. Ze nemen niet actief deel aan het verhaal, maar
hebben belang bij het feit dat primary actor zijn doel kan realiseren.
2.3.3.2 Precondities
• Geeft aan wat vervuld moet zijn voordat men kan starten met de use case (controle hiervan in de use case
zelf hoeft dus niet meer).
• Precondities moeten VOOR de start van een use case kunnen gevalideerd worden.
• In vele gevallen geeft een preconditie aan dat een andere use case reeds uitgevoerd is.
2.3.3.3 Postcondities
• Geeft aan wat vervuld moet zijn na uitvoeren van een use case/scenario.
• Bevat wijzigingen van het systeem t.o.v. het domeinmodel.
• Wordt geformuleerd vanuit standpunt van het systeem (bv. systeem heeft de klant geregistreerd).
• Niet elk alternatief scenario bereikt de postcondities.
Voorbeeld:
Use case: Geld afhalen
• Primary Actor: klant
• Precondities: De klant beschikt over voldoende saldo
• Postcondities: De klant heeft geld afgehaald (Eigenlijk fout, moet in functie van het systeem verwoord
worden. Dus beter zou zijn; het systeem heeft het saldo van de klant verminderd.)
2.3.3.4 Normaal verloop
• Normale verloop van een use case beschrijft de main succes story AKA hoe de use case het meest wordt
gebruikt
• Een stappenplan van actiestappen in chronologische en oplopende genummerde volgorde
∘ Elke actiestap beschrijft een wisselwerking tussen de primaire actor en het systeem
∘ In één stap is het onmogelijk dat de primary actor EN het systeem iets doen!
∘ Een actiestap beschrijft ook geen specifieke UI actie, big no no, worden punten voor afgetrokken
∘ Bevestigingen en annulaties zijn overbodigen, aangezien we ervanuitgaan dat de primary actor steeds
de stappen wil uitvoeren. De enige uitzondering hierop is als deze toch zouden leiden tot een speciaal
verloop.
Voorbeelde van mogelijke (actie)stappen zijn:
• Primary actor voert actie uit
• Systeem registreert interne wijziging
• Systeem voert validatie of actie uit
• Systeem vraagt naar gegevens
• Systeem toont een melding en/of stuurt een melding
2.3.3.5 Alternatief verloop Alternatieve verlopen zijn uitbreidingen op het normaal verloop of andere
alternatieve verlopen, wanneer een stap afwijkt van het verhaal.
Elk alternatief verloop heeft hierbij als nummering de stap van het oorspronkelijke scenario waar de afwijking
begint, aangevuld met een alfabetische nummering van de mogelijke alternatieve verlopen voor die stap. Binnen
het alternatief verloop zelf wordt dan de nummering aangevuld met een oplopend nummer (opnieuw startend
bij 1) van chronologisch opeenvolgende deelstappen.
Een voorbeeld, “4A1”; hierbij gaat het om een stap uit het alternatief verloop dat:
• Begint in stap 4 van het normaal verloop (of een ander alternatief verloop)
• Het eerste mogelijke alternatieve verloop is, hence A
• De 1ste stap is in dit alternatief verloop.
Bij het opstellen van een alternatief verloop, wordt stap “4A1” voorafgegaan door een bulletpoint “4A”.
Hierachter plaatsen we de titel van het alternatief verloop. Deze wordt dan gevolgd door verschillende stappen,
“4A1”, “4A2”, “4A3”, …
• Als titel noteren we wat het systeem ontdekt heeft, niet wat er gebeurd is
∘ Niet: “Klant vergeet pincode in te geven”
8
,2.3 Use cases 2 HOOFDSTUK 2: FUNCTIONELE REQUIREMENTS
∘ ⇓
∘ Wel: “Tijdslimiet overscheden bij ingave pincode”
Een alternatief verloop kan tenslotte op verschillende manieren eindigen:
• Verhaal keert terug naar een stap in het normaal verloop
• Verhaal keert terug naar een stap in een ander alternatief verloop
• Er wordt een externe use case opgeroepen
• De huidige use case wordt stopgezet. Vermeldt hierbij steeds de bereikte postcondities
Notatie:
1. De klant wenst geld af te halen
2. Het systeem vraagt pincode
3. De klant voert de pincode in
4. Het systeem valideert de pincode
5. …
Uitbreidingen
4a. Ongeldige pincode
4a1. Het systeem toont een gepaste melding
4a2. Keer terug naar stap 2 van het normaal verloop
4b. Fout wachtwoord te dikwijls ingegeven
4b1. systeem verwittigt gebruiker
Usecase eindigt zonder bereiken postcondities
2.3.3.6 Domeinspecifieke regels Omvat alle technische regels voor validaties, logica, …
De naamgeving is steeds DR_<naam> waarbij de <naam> vrij te kiezen is.
Voorbeeld:
• DR_NIEUW_LID
∘ Een nieuw lid is minstens 18 jaar oud
∘ Wachtwoord is 8-16 tekens lang en bevat geen spaties
2.3.3.7 Op te klaren punten Wordt gebruikt om alle zaken die nog onduidelijk waren bij het opstellen
van de use case op te sommen, deze sectie is voornamelijk bedoelt om te communiceren met de klant. Vaak is
deze sectie echter leeg en overbodig.
2.3.4 Tips, tricks en vaakgemaakte fouten
Een use case bestaat uit actiestappen die een specifieke volgorde hebben, voorbeelden van actiestappen zijn:
• Interactie tussen primary actor en systeem
∘ (Klant geeft adres in)
• Een validatie
∘ (Systeem valideert pincode)
• Een interne wijziging
∘ (Systeem vermindert totale bedrag met hoeveelheid)
Tips
• Gebruik eenvoudige zinnen
∘ Onderwerp - werkwoord - voorwerp
• “Wie heeft de bal”
∘ Bij elke actie heeft 1 actor een boodschap
• Vogelperspectief / Bird’s Eye View
∘ Geef bankkaart en pincode. Verminder saldo met opgegeven bedrag
∘ ⇓ kan beter verwoord worden als ⇓
∘ De klant plaatst bankkaart in kaartlezer en geeft pincode in
∘ Het systeem vermindert het saldo met het opgegeven bedrag
• Toon wat de bedoeling van de actor is, niet de beweging
∘ Beschrijf GEEN interacties met de GUI
■ Men trekt hier veel punten voor af
■ Hoe (door een knop in de UI) they don’t care about, specifiek functioneel beschrijven
■ Klankt drukt op OK ⇒ Klant bevestigt
∘ Functionele eisen
9
, 2.3 Use cases 2 HOOFDSTUK 2: FUNCTIONELE REQUIREMENTS
∘ Vermeld niet HOE iets gebeurt, maar WAT er gebeurt
■ Bv: Het systeem connecteert met de databank en voert de query uit en toont de tabellen ⇒ Het
systeem toont het resultaat van de operatie
Voorbeelden:
Note: “zendt een e-mail” is niet ideaal. Je moet niet aangeven hoe iets gebeurt, maar wat er gebeurt. Beter
zou zijn “zendt een validatie”.
• Vermijd “if statements”
• Bij het oproepen van een andere use case, gebruik geen calls maar schrijf in de taal van de opdrachtgever
∘ De gebruiker bevestigt en roept UC Betalen winkelmand / ”Betalen winkelmand” op
∘⇓
∘ Gebruiker betaalt de winkelmand
• Systeem komt niet aanbod in de usecase. In onderstaand voorbeeld wordt bijvoorbeeld alleen maar de
primary actor vernoemd
∘ Use case: Afname cash
∘ Primary actor: Klant
1. Klant geeft kaart in en pincode
2. Klant geeft “geld afhaling” door en het bedrag
3. Klant neemt geld, kaart en ticket
4. Klant vertrekt
∘⇓
1. Gebruiker laat bankkaart lezen door bankterminal
2. Systeem leest het bank-id, rekeningnr, geëncrypteerdepincode van de kaart, valideert de gegevens
3. Gebruiker geeft pincode in
4. Systeem valideert ingegeven pincode t.o.v. geëncrypteerdepincode
5. Gebruiker geeft het bedrag in
10
Les avantages d'acheter des résumés chez Stuvia:
Qualité garantie par les avis des clients
Les clients de Stuvia ont évalués plus de 700 000 résumés. C'est comme ça que vous savez que vous achetez les meilleurs documents.
L’achat facile et rapide
Vous pouvez payer rapidement avec iDeal, carte de crédit ou Stuvia-crédit pour les résumés. Il n'y a pas d'adhésion nécessaire.
Focus sur l’essentiel
Vos camarades écrivent eux-mêmes les notes d’étude, c’est pourquoi les documents sont toujours fiables et à jour. Cela garantit que vous arrivez rapidement au coeur du matériel.
Foire aux questions
Qu'est-ce que j'obtiens en achetant ce document ?
Vous obtenez un PDF, disponible immédiatement après votre achat. Le document acheté est accessible à tout moment, n'importe où et indéfiniment via votre profil.
Garantie de remboursement : comment ça marche ?
Notre garantie de satisfaction garantit que vous trouverez toujours un document d'étude qui vous convient. Vous remplissez un formulaire et notre équipe du service client s'occupe du reste.
Auprès de qui est-ce que j'achète ce résumé ?
Stuvia est une place de marché. Alors, vous n'achetez donc pas ce document chez nous, mais auprès du vendeur TomDeBakker. Stuvia facilite les paiements au vendeur.
Est-ce que j'aurai un abonnement?
Non, vous n'achetez ce résumé que pour €5,49. Vous n'êtes lié à rien après votre achat.
Peut-on faire confiance à Stuvia ?
4.6 étoiles sur Google & Trustpilot (+1000 avis)
79202 résumés ont été vendus ces 30 derniers jours
Fondée en 2010, la référence pour acheter des résumés depuis déjà 14 ans