Summary
Functional Analysis Samenvatting HoGent
- Course
- Institution
Samenvatting van het vak Functional Analysis, in het 2de bachelor van het traject Toegepaste Informatica (TI)
[Show more]
Seller
Follow
TomDeBakker
Reviews received
Content preview
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
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller TomDeBakker. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $5.97. You're not tied to anything after your purchase.
Can Stuvia be trusted?
4.6 stars on Google & Trustpilot (+1000 reviews)
79373 documents were sold in the last 30 days
Founded in 2010, the go-to place to buy study notes for 14 years now