Analyse en Functioneel Ontwerpen
College 1 Introductie
Analyse
Inleiding
Analyseren is het ontleden van een probleem in verschillende onderdelen zoals:
• Verschillende deelproblemen van een probleem onderscheiden
• De benodigde informatie verzamelen over de achtergronden en oorzaken
• Verbanden leggen tussen de gegevens die je hebt verzameld
Requirementsanalyse
Requirementanalyse is een traject dat leidt tot een vastgestelde set requirements
(baseline). Requirements zijn de eisen die de business stelt aan een oplossing.
Verschillende typen requirements zijn:
• Business requirements (waarom)
• User requirements (wat)
• Systeem requirements (hoe)
Informatieanalyse
Informatieanalyse is de 1e fase in de ontwikkeling van een informatiesysteem. Het
doel van de informatieanalyse is het vaststellen of het ontwikkelen of aanpassen van
het systeem mogelijk is, en wat de consequenties zijn op verschillende gebieden
(technisch, economisch, sociaal).
Requirements
Een requirement is een eis die het systeem moet bezitten om in een behoefte te
voorzien van een belanghebbende uit de business.
Een functionele requirement (werkwoord) geeft het gedrag van een systeem weer.
Een niet-functionele requirement (soms getallen) is een kwaliteitseis waaraan het
systeem moet voldoen zoals: snelheid, veiligheid of gebruiksvriendelijkheid.
Tips:
• Het systeem is waar je de requirements voor schrijft.
• Houd je aan de terminologie van de casus
• Functioneel: zoek naar werkwoorden i.c.m. een actor/gebruiker
,Functioneel ontwerpen
Inleiding
Bij functioneel ontwerpen maken we gebruik van diverse technieken die samen een
bijna compleet beeld geven van wat er gerealiseerd moet worden:
• Use case diagram
• Use case beschrijvingen
• Domeinmodel
• Schermontwerpen
Bij functioneel ontwerpen praten we over hoe het systeem vanuit de gebruiker werkt.
We zitten hierbij op het logische niveau, niet op het technische niveau.
Argile
Argile betekent letterlijk: behendig, lenig. In de ICT staat het voor
softwareontwikkeling in korte overzichtelijke perioden van vaak hooguit een week.
Deze iteraties (meerdere kleine cycli die telkens een compleet deelsysteem oplevert)
zijn als het ware kleine projecten op zich zelf.
Scrum
Scrum is 1 van de agile frameworks en kan worden ingezet om in teamverband op
een effectieve, flexibele manier software te ontwikkelen. De kern van Scrum is een
zelfsturend team. Iedereen werkt samen en is betrokken bij het plannen, benoemen
van blokkades en het verdelen van de taken.
De Product Owner is een vertegenwoordiger van de business en maakt samen met
de belanghebbenden een lijst van de requirements, de product backlog. Op basis
van de product backlog bepaalt het Development Team welke requirements zij in de
eerstvolgende iteratie oftewel sprint gaan ontwikkelen.
College 2 User Stories
User story
Een user story is een verhaal (story) verteld vanuit de gebruiker (user) van een
informatiesysteem. Dus: user stories beschrijven gewenste functionaliteit vanuit het
gezichtspunt van de gebruiker.
Een belangrijk voordeel van user stories is dat ze in de taal van de gebruiker zijn
geformuleerd en dus ook bijna iedereen kan begrijpen.
Een user story bestaat uit drie onderdelen:
1. Een kernzin: Wie wil wat en waarom? (vaste structuur)
2. De acceptatiecriteria: Hiermee wordt er getoetst of de gerealiseerde
functionaliteit overeenkomt met wat er gevraagd is. (Wanneer voldoet het?)
3. Mondelinge communicatie: Met de gebruiker de details van de gewenste
functionaliteit helder krijgen.
, Kernzin
Als een [wie] wil ik [wat] zodat [waarom]
[wie]
1 onderwerp per kernzin
[wat]
1 actie per kernzin (niet invullen hoe)
Is vaak de functionele requirement
[waarom]
Wat is de toegevoegde waarde voor de gebruiker
Acceptatiecriteria
De acceptatiecriteria wordt vaak gebruikt om de gerealiseerde functionaliteit te
testen. Je kunt het zien als het antwoord op de vraag:
• “Wanneer voldoet de functionaliteit aan de eisen van de gebruiker?”
• “Wanneer is de gebruiker tevreden?”
Het gaat hierbij zowel om de functionele als de niet-functionele eisen. Net zoals de
kernzin wordt de acceptatiecriteria kort en bondig geformuleerd.
Kwaliteit van user stories
• Independent (onafhankelijk) = hebben geen overlapping en worden in
willekeurige volgorde gerealiseerd.
• Negotiable (onbehandelbaar) = er moet nog ruimte zijn voor de invulling
van de details
• Valuable (waardevol) = er moet een toegevoegde waarde zijn
• Estimable (inschatbaar) = je moet een user story globaal kunnen
inschatten
• Small enough (klein genoeg) = er mogen niet meerdere functionaliteiten in
een user story zitten
• Testable (testbaar) = je moet kunnen kijken of de functionaliteit
van de user story aan de eisen voldoet
College 3 Use Case Diagram
Use case diagram
In een use case diagram beschrijven we het gedrag van het systeem. Het is bedoeld
om een overzicht te geven van de gebruikerseisen aan het systeem in termen van
wat ze met dat systeem kunnen doen.
Een use case diagram bestaat uit drie onderdelen:
1. Het systeem en de grenzen
2. De actoren die het systeem benaderen
3. De (primaire) use cases binnen het systeem
College 1 Introductie
Analyse
Inleiding
Analyseren is het ontleden van een probleem in verschillende onderdelen zoals:
• Verschillende deelproblemen van een probleem onderscheiden
• De benodigde informatie verzamelen over de achtergronden en oorzaken
• Verbanden leggen tussen de gegevens die je hebt verzameld
Requirementsanalyse
Requirementanalyse is een traject dat leidt tot een vastgestelde set requirements
(baseline). Requirements zijn de eisen die de business stelt aan een oplossing.
Verschillende typen requirements zijn:
• Business requirements (waarom)
• User requirements (wat)
• Systeem requirements (hoe)
Informatieanalyse
Informatieanalyse is de 1e fase in de ontwikkeling van een informatiesysteem. Het
doel van de informatieanalyse is het vaststellen of het ontwikkelen of aanpassen van
het systeem mogelijk is, en wat de consequenties zijn op verschillende gebieden
(technisch, economisch, sociaal).
Requirements
Een requirement is een eis die het systeem moet bezitten om in een behoefte te
voorzien van een belanghebbende uit de business.
Een functionele requirement (werkwoord) geeft het gedrag van een systeem weer.
Een niet-functionele requirement (soms getallen) is een kwaliteitseis waaraan het
systeem moet voldoen zoals: snelheid, veiligheid of gebruiksvriendelijkheid.
Tips:
• Het systeem is waar je de requirements voor schrijft.
• Houd je aan de terminologie van de casus
• Functioneel: zoek naar werkwoorden i.c.m. een actor/gebruiker
,Functioneel ontwerpen
Inleiding
Bij functioneel ontwerpen maken we gebruik van diverse technieken die samen een
bijna compleet beeld geven van wat er gerealiseerd moet worden:
• Use case diagram
• Use case beschrijvingen
• Domeinmodel
• Schermontwerpen
Bij functioneel ontwerpen praten we over hoe het systeem vanuit de gebruiker werkt.
We zitten hierbij op het logische niveau, niet op het technische niveau.
Argile
Argile betekent letterlijk: behendig, lenig. In de ICT staat het voor
softwareontwikkeling in korte overzichtelijke perioden van vaak hooguit een week.
Deze iteraties (meerdere kleine cycli die telkens een compleet deelsysteem oplevert)
zijn als het ware kleine projecten op zich zelf.
Scrum
Scrum is 1 van de agile frameworks en kan worden ingezet om in teamverband op
een effectieve, flexibele manier software te ontwikkelen. De kern van Scrum is een
zelfsturend team. Iedereen werkt samen en is betrokken bij het plannen, benoemen
van blokkades en het verdelen van de taken.
De Product Owner is een vertegenwoordiger van de business en maakt samen met
de belanghebbenden een lijst van de requirements, de product backlog. Op basis
van de product backlog bepaalt het Development Team welke requirements zij in de
eerstvolgende iteratie oftewel sprint gaan ontwikkelen.
College 2 User Stories
User story
Een user story is een verhaal (story) verteld vanuit de gebruiker (user) van een
informatiesysteem. Dus: user stories beschrijven gewenste functionaliteit vanuit het
gezichtspunt van de gebruiker.
Een belangrijk voordeel van user stories is dat ze in de taal van de gebruiker zijn
geformuleerd en dus ook bijna iedereen kan begrijpen.
Een user story bestaat uit drie onderdelen:
1. Een kernzin: Wie wil wat en waarom? (vaste structuur)
2. De acceptatiecriteria: Hiermee wordt er getoetst of de gerealiseerde
functionaliteit overeenkomt met wat er gevraagd is. (Wanneer voldoet het?)
3. Mondelinge communicatie: Met de gebruiker de details van de gewenste
functionaliteit helder krijgen.
, Kernzin
Als een [wie] wil ik [wat] zodat [waarom]
[wie]
1 onderwerp per kernzin
[wat]
1 actie per kernzin (niet invullen hoe)
Is vaak de functionele requirement
[waarom]
Wat is de toegevoegde waarde voor de gebruiker
Acceptatiecriteria
De acceptatiecriteria wordt vaak gebruikt om de gerealiseerde functionaliteit te
testen. Je kunt het zien als het antwoord op de vraag:
• “Wanneer voldoet de functionaliteit aan de eisen van de gebruiker?”
• “Wanneer is de gebruiker tevreden?”
Het gaat hierbij zowel om de functionele als de niet-functionele eisen. Net zoals de
kernzin wordt de acceptatiecriteria kort en bondig geformuleerd.
Kwaliteit van user stories
• Independent (onafhankelijk) = hebben geen overlapping en worden in
willekeurige volgorde gerealiseerd.
• Negotiable (onbehandelbaar) = er moet nog ruimte zijn voor de invulling
van de details
• Valuable (waardevol) = er moet een toegevoegde waarde zijn
• Estimable (inschatbaar) = je moet een user story globaal kunnen
inschatten
• Small enough (klein genoeg) = er mogen niet meerdere functionaliteiten in
een user story zitten
• Testable (testbaar) = je moet kunnen kijken of de functionaliteit
van de user story aan de eisen voldoet
College 3 Use Case Diagram
Use case diagram
In een use case diagram beschrijven we het gedrag van het systeem. Het is bedoeld
om een overzicht te geven van de gebruikerseisen aan het systeem in termen van
wat ze met dat systeem kunnen doen.
Een use case diagram bestaat uit drie onderdelen:
1. Het systeem en de grenzen
2. De actoren die het systeem benaderen
3. De (primaire) use cases binnen het systeem
