3 Het ontwerpproces: de analysefase
Inleiding
In dit hoofdstuk wordt de analysefase van het ontwerpproces behandeld. Als opdracht bij dit hoofdstuk voer je een analyse uit voor het restaurant Kiriakos.
Ter ondersteuning van de onderwerpen wordt aan de hand van de kaartjesautomaat een aantal voorbeelden gegeven.
Ontwerpen doe je niet zomaar. Net zoals een goede programmeur van tevoren nadenkt over de stappen (het algoritme) van het te ontwerpen programma, zo zal een ontwerper bij het tot stand komen van het ontwerp ook een aantal fasen moeten doorlopen. Daarbij zullen een aantal vragen geformuleerd moeten worden en beantwoord moeten worden:
- Is het duidelijk wat de opdrachtgever voor ogen heeft?
- Welke taken moet het systeem precies uitvoeren?
- Is het duidelijk welke mensen met het systeem moeten gaan werken?
Op grond van de informatie die uit de eerste analyse voortkomt, kan
- een probleemstelling
- een use case diagram
- een taakmodel
- een gebruikersprofiel
- een programma van eisen
worden opgesteld.
In de probleemstelling moet in één zin duidelijk worden wat het doel van het project is. In het use case diagram wordt duidelijk wat de hoofdtaken zijn en wie daarbij betrokken zijn. In het taakmodel wordt schematisch weergegeven hoe de verschillende taken op elkaar aansluiten. In het gebruikersprofiel wordt duidelijk welke kenmerken de gebruikers hebben. In het programma van eisen wordt beschreven waar het systeem aan moet voldoen.
3.1 De analyse
Het doel van een project is over het algemeen om een verbetering door te voeren in bijvoorbeeld: efficiëntie, reductie van fouten, onkostenbesparing. Taken die nu nog handmatig gebeuren, moeten straks met het nieuwe systeem worden uitgevoerd. Om die overgang goed te kunnen maken moet precies in kaart worden gebracht hoe de taken worden uitgevoerd zonder het systeem. Het kan ook zijn dat een bestaand systeem moet worden aangepast. De taken zijn dan al geautomatiseerd, maar er komen nieuwe taken bij. In dat geval moet duidelijk zijn hoe de nieuwe taken aansluiten op de oude taken.
Voor het in kaart brengen van de bestaande situatie bestaan verschillende technieken. Eén van de technieken is het interviewen van de toekomstige gebruikers. Zij zijn deskundig en kunnen een waardevolle bijdrage leveren aan het ontwikkelen van een geautomatiseerd systeem.
In plaats van het afnemen van interviews kun je ook observeren. Als alle handelingen nog met de hand gebeuren, beschrijf dan wat er gebeurt: Wat wordt opgeschreven, doorgegeven, bewaard of weggegooid?
Een kaartjesautomaat analyse
Stel je de tijd voor waarin je alle treinkaartje nog aan het loket kon kopen. Toen dat proces geautomatiseerd moest worden, heeft de ontwerper ongetwijfeld de loketmedewerkers geïnterviewd. De ontwerper wil dan antwoorden hebben op vragen als:
- Welk soort kaartje verkoopt u het meest?
- Hoe betalen de meeste klanten?
Bij het ontwerp van het systeem zal het antwoord op de eerste vraag heel belangrijk zijn geweest. Kaartjes die zelden verkocht worden hoeven niet altijd zichtbaar te zijn in het keuzemenu.
Natuurlijk is de vragenlijst veel langer. Bovendien krijgt de ontwerper ook nog andere informatie. Welke soorten kaartjes er bestaan (of nog bedacht zullen worden), zal de ontwerper niet alleen van de loketmedewerker te horen hebben gekregen. Welke betalingsmogelijkheden er nu zijn zal niet het enige uitgangspunt zijn geweest. Het geautomatiseerde systeem moet ook inspelen op ontwikkelingen in het elektronisch betalingsverkeer.
Toch zal uiteindelijk het gedrag van de klant het uiterlijk van het definitieve systeem voor een goed deel bepalen. De ontwerper kan daarvoor observeren en bijvoorbeeld een paar dagen naast de loketmedewerker gaan zitten of in de rij gaan staan om een ingewikkeld kaartje te kopen. Dan merkt de ontwerper zelf hoe de loketbediende reageert. Stelt de loketbediende bijvoorbeeld een wedervraag, of is dat niet nodig? De ontwerper moet van te voren wel weten waarop gelet moet worden. Het heeft geen zin om te kijken of mensen wel netjes op hun beurt wachten. Het heeft wel zin om te luisteren hoe mensen een kaartje kopen. Als iemand vraagt om een retour naar Den Haag, is het dan duidelijk dat het een tweedeklas kaartje is? Zijn er stilzwijgende afspraken dat een tweedeklas kaartje de standaard is? Is er ook een stilzwijgende afspraak dat het vertrekstation dezelfde plaats is als waar het kaartje wordt gekocht?
Analyse voor restaurant Kiriakos
De eigenaar van restaurant Kiriakos wil meegaan met zijn tijd en besluit zijn zaak te moderniseren. Het wordt de hoogste tijd dat het plaatsen en afhandelen van bestellingen geautomatiseerd wordt voor achtereenvolgens: de klanten, de obers en de kok. Nu worden bestellingen nog met pen en papier verwerkt.
De ober neemt bij de klant een bestelling op door de keuze van de klant te noteren op een blaadje. Daarna levert hij het blaadje met de bestelling in bij de kok. Als de kok klaar is met het bereiden van de maaltijd, krijgt de ober vanuit de keuken een verbaal seintje. De ober brengt het eten naar de tafel van de klant. Na het eten rekent de klant af met de ober.
Dit is een weergave van de huidige situatie. De ontwerper van het nieuwe systeem is een dag in het restaurant gaan zitten om de situatie te beschrijven. Hij heeft ook de eigenaar geïnterviewd. De eigenaar wil alle taken die nu met de hand worden uitgevoerd automatiseren. Het is duidelijk dat niet het bereiden van het eten wordt geautomatiseerd. Wel moeten de papiertjes verdwijnen waarop de bestellingen worden geschreven en daarmee de mogelijkheid te creëren om automatisch de rekening te bepalen. Ook is het storende geroep tussen de keuken en het restaurantgedeelte niet meer nodig.
Bovendien kan de automatiseringsslag gebruikt worden om de bestaande processen efficiënter te maken, door bijvoorbeeld een volledig andere indeling te kiezen en taken overbodig te maken. Als voorbeeld zou Kiriakos zijn klanten kunnen informeren via een smartphone of er nog plaats is in het restaurant.
Klik hier voor de opdracht om een analyse voor het restaurant te maken.
3.2 De Use Cases
De interviews en/of de observaties hebben de ontwerper een beeld gegeven van de bestaande situatie. Alle handelingen en interacties moeten nu gestructureerd worden. Bovendien moet duidelijk worden wie wat doet. Om een beter beeld te krijgen van de rollen die door de verschillende partijen worden gespeeld, worden zogenaamde use cases gemaakt. Elke use case is een pad dat door een bepaalde partij wordt gevolgd om een bepaald doel te bereiken.
Bij het ontwerpen van een use case diagram zijn er enkele punten waar je op moet letten:
- Het systeem wordt weergegeven als een rechthoek.
- De use cases worden in de rechthoek, het systeem, geplaatst.
- De actoren worden altijd buiten het systeem geplaatst.
- Een actor hoeft niet altijd een persoon te zijn. Het kan ook een ander systeem zijn.
- Neemt een actor deel aan een use case dan is dat terug te zien door een lijn die de actor met de betreffende use case verbindt.
Use cases kunnen in een latere fase van het ontwerpproces nog verder worden uitgewerkt c.q. worden aangepast.
Een kaartjesautomaat Use Case
Een klant heeft als algemeen doel het reizen met de trein. Daarbinnen kun je verschillende acties onderscheiden:
- Kaartje kiezen.
- Kaartje betalen.
Behalve de klant is de loketmedewerker ook betrokken bij de aankoop van het kaartje. Als de klant niet duidelijk aangeeft wat de bedoeling is, moet de loketmedewerker de goede vragen stellen. Bovendien moet loketmedewerker de financiële transactie tot een goed einde brengen en onder andere wisselgeld teruggeven. Om aan te geven wie welke taken uitvoert worden de use cases in een use case diagram gezet. In het diagram wordt duidelijk welke taak door welke rol wordt uitgevoerd. De taken zelf worden heel globaal beschreven. De uitsplitsing van de taken gebeurt in een aparte tabel.
Klik hier voor de opdracht voor de Use Case voor het restaurant.
3.3 Taakmodel
In het use case diagram worden de belangrijkste taken weergegeven. Bovendien wordt duidelijk welke actoren bij deze taken betrokken zijn.
De use cases zelf zijn nog heel globaal geformuleerd. In een aparte tabel worden zij verder uitgewerkt. Hieronder zie je de uitwerking voor een eerste use case:
- Kaartje kiezen.
- Het vertrekpunt noemen.
- Het eindpunt noemen.
- Aangeven of het eerste of tweedeklas is.
- Aangeven of er recht is op korting.
- Kaartje betalen.
In de de toekomst zullen de kaartjes zonder tussenkomst van de loketmedewerker gekocht moeten worden. Deze rol zal worden overgenomen door een systeem. In de analysefase werd duidelijk dat er stilzwijgende afspraken bestaan. Er wordt meestal vanuit gegaan dat de reiziger vertrekt vanaf het station waar het kaartje wordt gekocht. Hoe is dat bij de kaartjesautomaat?
Bij het kopen van een kaartje aan het loket wordt er meestal vanuit gegaan dat het kaartje dezelfde dag geldig moet zijn. Bij een kaartjesautomaat moet die keuze expliciet worden gemaakt.
Zo kom je vanuit de uitsplitsing van de use cases al tot een weergave van de taken die het systeem moet uitvoeren.
Een taakmodel is een nadere uitwerking van een use case diagram. In een taakmodel kun je, anders dan in een use case diagram, de volgorde van de schermen weergeven. Bovendien kun je de algemene use cases verder uitsplitsen.
Je moet er wel om denken dat je niet alleen maar let op de volgorde. Bij het kopen van een kaartje moet je een bestemming kiezen voordat je kunt betalen. Toch zul je in het taakmodel zien dat het betalen van een kaartje niet volgt op het bepalen van je bestemming. Bij het aangeven van de volgorde moet je de volgorde per hoofdtaak uitbeelden. De belangrijkse taken (de hoofdtaken) worden apart weergegeven.
3.4 Het gebruikersprofiel
Bij het ontwerp van je systeem moet je rekening houden met je gebruikers. De gebruikers moeten zonder al te veel hulp de aanwijzingen op de schermen kunnen volgen. Wat zijn die aanwijzingen? Als je weer even aan de kaartjesautomaat denkt, weet je dat het eerste scherm geen lap tekst is.
De aanwijzingen zitten in de plaats van de knoppen en de tekst op de knoppen.
Het kaartjesautomaat moet begrijpelijk zijn voor iedere reiziger. Dat zijn oude en jonge mensen, met veel en weinig opleiding, met veel ervaring met interactieve systemen of met een grote weerzin tegen de automaten.
Soms zul je een systeem ontwerpen voor een groep gebruikers die onderling minder verschillen. Ze werken bijvoorbeeld allemaal bij hetzelfde bedrijf, of ze hebben allemaal een bepaalde interesse. Zo zullen de bezoekers van Pinkpop een andere profiel hebben dan de abonnementhouders van de opera.
Om je ontwerp goed af te stemmen op je gebruikers, maak je een gebruikersprofiel. In een gebruikersprofiel worden de kenmerken beschreven van de mensen die met het systeem gaan werken. Daarin neem je op of de gebruikers gemotiveerd zijn voor de taak die ze moeten uitvoeren, welk werk ze doen, welk opleidingsniveau ze hebben en welke ervaring ze hebben in het werken met verschillende applicaties.
In een gebruikersprofiel worden verschillende categorieën uitgewerkt. Hieronder zie je een voorbeeld van een gebruikersprofiel. Het profiel is opgesteld op basis van interviews met toekomstige gebruikers van een systeem waarmee maaltijden moeten worden besteld in een verzorgingstehuis. De bedoeling is dat de bewoners vanuit hun kamer een maaltijd bestellen via een interactief scherm.
Het verzorgingstehuis is speciaal opgericht voor mensen die in het middelbaar en hoger onderwijs hebben gewerkt. In de tweede kolom is met vet aangegeven in hoeverre zij overeenkomen met bepaalde kenmerken.
| Kenmerk |
Beschrijving |
| Psychologische kenmerken |
| Cognitieve stijl |
verbaal visueel |
| Houding t.o.v. taak |
positief neutraal negatief |
| Kennis en ervaring |
| Opleidingsniveau |
hoog middel laag |
| Typvaardigheid |
hoog middel laag |
| Ervaring met computers |
hoog middel laag |
| Kennis vreemde talen |
hoog middel laag |
| Werk- en taakeigenschappen |
| Bekendheid met taak |
hoog middel laag |
| Systeemgebruik |
verplicht facultatief |
| Training |
cursus handleiding |
| Lichamelijke kenmerken |
| Geslacht |
man vrouw |
| Leeftijd |
oud middelbaar jong |
| Gezichtsvermogen |
goed redelijk slecht |
| Motoriek |
goed redelijk slecht |
Klik hier voor de opdracht een gebruikersprofiel voor het restaurant op te stellen.
3.5 Het programma van eisen
In de probleemstelling is het doel van het project in één zin beschreven. Nu duidelijk is welke taken het systeem moet gaan uitvoeren en wie de gebruikers zijn kan een programma van eisen worden opgesteld. Het kan zijn dat zowel de probleemstelling, als het taakmodel, als het programma van eisen, na een eerste test van het systeem nog moet worden bijgesteld. Nu gaat het om een eerste poging.
Als uitgangspunt nemen we het menusysteem voor het verzorgingshuis. De probleemstelling is (tegen de zin van de bewoners) als volgt geformuleerd:
Er moet een systeem worden ontwikkeld waarmee de bewoners hun maaltijden op de kamer via een interactief scherm kunnen bestellen.
We gaan ervan uit dat er een use case diagram is gemaakt en een taakmodel is opgesteld. Het gebruikersprofiel heb je net bestudeerd.
In het programma van eisen wordt nu beschreven waarover de opdrachtgever en de ontwerper in een aantal gesprekken het eens zijn geworden.
De eisen kunnen worden onderverdeeld in functionele en niet-functionele eisen. Niet-functionele eisen hebben te maken met de vraag of het scherm is aangesloten op het gesloten circuit van het verzorgingshuis, de snelheid en de kosten van het systeem en de aansluiting van de interface op andere applicaties van het verzorgingshuis. Deze eisen laten we buiten beschouwing.
De functionele eisen hebben bijvoorbeeld te maken met de taken van het systeem en worden mede gebaseerd op de kenmerken van de gebruikers. Elke zin begint met Het systeem moet.. :
- Het systeem moet alle menukeuzes van één dag zichtbaar maken op het scherm.
- Het systeem moet de mogelijkheid hebben dieetwensen aan te geven.
- Het systeem moet het mogelijk maken foute keuzes te herstellen.
- Het systeem moet het mogelijk maken ook voor gasten een bestelling te plaatsen.
- Het systeem moet goed leesbare teksten tonen.
- Het systeem moet bruikbaar zijn voor mensen met een slechte motoriek.
- Het systeem moet het mogelijk maken de grootte van de porties aan te geven.
In een eerste gesprek met de directie en het hoofd van de keuken zijn deze eisen geformuleerd. Als een prototype door de leden van het bewonerscomité is getest, zullen hier misschien eisen aan worden toegevoegd. In ieder geval zijn de eerste afspraken nu goed op een rijtje gezet.
Klik hier voor de opdracht het programma van eisen voor het restaurant te maken.
3.6 Opdrachten
Het restaurant
Opdracht bij 3.1 - A: Interview voor restaurant Kiriakos
Kies één van beide mogelijkheden:
- Stel een lijst met vragen op die je wilt stellen aan de ober van Kiriakos. Uit de antwoorden moet duidelijk worden hoe een ober de bestellingen noteert en doorgeeft aan de keuken.
- Maak een lijst van dingen die je wilt observeren in het restaurant. Uit je observaties moet blijken hoe de ober de bestellingen opneemt en doorgeeft aan de keuken.
Opdracht bij 3.1 - B: Probleemstelling voor het restaurant
De eigenaar heeft duidelijk gemaakt dat de huidige gang van zaken hem niet bevalt. Formuleer nu zelf in één zin de probleemstelling die hoort bij dit project. Deze probleemstelling moet voor zowel de opdrachtgever (de eigenaar van Kiriakos) als voor de ontwerper duidelijkheid verschaffen over het uitgangspunt van het project. Dit globale uitgangspunt wordt later nader uitgewerkt in het programma van eisen.
Een voorbeeld van een probleemstelling voor het automatiseren van de kaartverkoop bij de NS zou kunnen zijn:
Het systeem moet ervoor zorgen dat kaartjes zonder tussenkomst van de loketmedewerker gekocht kunnen worden.
Terug naar 3.1
Opdracht bij 3.2 - Use Cases
Ontwerp nu zelf een use case diagram voor een bestelling plaatsen in restaurant. Doe dit vanuit de bestaande situatie. Je kunt hiervoor gebruik maken van het programma Microsoft Office Visio of het freeware-pakket 
Violet. En desnoods kun je het use case diagram tekenen met potlood en papier. Denk goed na of de taken behoren tot het systeem, en of je ze echt wilt automatiseren.
N.B. In het freewarepakket 
Violet kun je niet met een rechthoek het systeem afbakenen.
Terug naar 3.2
Opdracht bij 3.4 - Gebruikersprofiel voor het restaurant
Om je een beeld te vormen van de mogelijke gebruikers van het systeem kun je ook personae beschrijven. Eenpersona is een dwarsdoorsnede van mogelijke gebruikers. Je kunt je beter inleven in je gebruikers als je een bepaald iemand in gedachten hebt.
Het gebruik van personae en het beschrijven van kenmerken kunnen elkaar aanvullen. Voor de gebruikers van het systeem voor het reataurant zijn twee personae beschreven. Om te oefenen met de checklist van kenmerken kun je nu een tabel maken zoals je hebt gezien voor de bewoners van het verzorgingshuis. Je hoeft niet precies dezelfde kenmerken te beschrijven als in het voorbeeld. Je moet je wel houden aan de vier hoofdcategorïen:
- Psychologische kenmerken.
- Kennis en ervaring.
- Werk- en taakeigenschappen.
- Lichamelijke eigenschappen.
Schrijf een gebruikerprofiel op basis van de volgende personae. In je gebruikersprofiel moet je de overeenkomsten zo goed mogelijk tot uitdrukking laten komen. Zo weet je met welk type gebruikers je rekening moet houden bij het ontwerp van je systeem.
Bediening
Een leerling van 17 jaar werkt sinds kort in het weekend bij Kiriakos en is dol op elektronische gadgets. De leerling is zeer enthousiast over het idee van de eigenaar om een PDA (Personal Digital Assistent) te gaan gebruiken voor het plaatsen van bestellingen. Door de aard van de gerechten zijn de namen nogal complex en lastig te onthouden.
Eigenaar
De eigenaar is 54 jaar en heeft zijn hele leven lang in de horeca gewerkt en is pas op latere leeftijd naar Nederland geëmigreerd. De eigenaar heeft het restaurant opgezet een jaar na aankomst in Nederland. De eigenaar beheerst de Nederlandse taal in beperkte mate. De eigenaar kent alle recepten en prijzen uit zijn hoofd. Het leukste aspect van zijn vak is het contact met de klanten. De eigenaar geeft graag uitleg over de gerechten en de eetgewoonten van zijn land van afkomst.
Terug naar 3.4
Opdracht bij 3.5 - Programma van eisen voor restaurant
Voor het bestelsysteem van het restaurant heb je al een groot aantal stappen gezet. Maak de analysefase nu af. Beschrijf een programma van eisen op grond van je gebruikersprofiel.
Terug naar 3.5
Opdracht extra. Taakmodel voor kaartjesautomaat
Voor extra inzicht in het taakmodel zie hieronder voor een opdracht met de kaartjesautomaat.
