3. Anvendelse

Vores tidligere beskrivelse af anvendelsesområdet var følgende:
Systemet skal styre abonnentregistreringen og deres abonnementer.
Endvidere skal der kunne skabe sammenhæng mellem lageret og bestillinger, således at abonnenter kan få udleveret en bestilt tegneserie direkte, såfremt den findes på lageret.
Det skal kunne generere en mere komplet bestillingsliste, således at Michaels arbejde med at kontrollere og ændre denne liste minimeres. Herunder skal det være muligt at se hvad butikken allerede har bestilt.
Systemet skal effektivisere registreringen af abonnementer, således at det er istand til at udskrive en komplet liste når de ankomne tegneserier skal puttes i poser, hvorved Michaels tilstedeværelse ikke er påkrævet.
Systemet skal kunne håndtere usædvanlige ønsker og crossovers bedre end det nuværende, samt give forskellige former for statistik over abonnenter, abonnementer og lager.

En kortfattet oversigt over anvendelsesområdet ses nedenfor:

Tilføjelser til anvendelsesområdet
En bestillingsseddel består af en liste af alle de tegneserier, der skal bestilles fra en bestemt distributør. Den genereres ud fra de abonnementer kunderne har oprettet. Dertil udskrives en liste med kundernes specielle ønsker, der ikke kan modelleres af en computer (eks: alle tegneserier med grønt cover).
En put-i-pose liste indeholder alle de tegneserier, der er ankommet til butikken. Disse tegneserier skal fordeles i et antal poser. Hver kunde har en pose med kundens nummer. Hvis Batman nr. 47 eksempelvis er ankommet til butikken vil der stå "Batman nr. 47: 43, 63, 123" på put-i-pose listen, hvilket betyder at kunderne med numrene 43, 63 og 123 skal have et eksemplar i deres pose.
Ved rettelse af butiksabonnement ønsker Michael at kunne se hvor mange tegneserier af en enkelt type der abonneres på fra kundernes side.
Vores tidligere beskrivelse af brugsmiljøet var som følger:
Brugssituationen er hypotetisk, da systemet ikke kommer til at virke nede i Stribeladen. Systemet anvendes et par gange om dagen til registrering af abonnenter med dertil hørende abonnementer. Dette skal helst ikke tage for lang tid, da abonnenterne står og venter på at oplysningerne ændres. Dertil anvendes det et par gange om måneden til henholdsvis bestilling af tegneserier og udskrivning af Læg-i-pose seddel. Brugerne af systemet er medarbejdere i forretningen. Tre af disse er erfarne computerbrugere og en enkelt lider af teknologiskræk og har derfor ingen erfaring med computere.
Tilføjelser til brugsmiljøet
Michael krævede pludselig (den 28/3) at der skulle være 2 typer af brugere: En der måtte det hele og en der kun måtte oprette nye abonnenter og ændre i kundernes abonnementer. Dette skyldes at begreberne kunde og ansat til tider er lidt flydende i den lille butik. Vi har eksempelvis set en kunde betjene en anden, da Michael havde travlt. Åbenbart kommer kunderne også ind til computeren, hvor de lægger programmer ind og ændrer i diverse data.

4. Mockup

På nuværende tidspunkt er vores mock-up ikke kørende, hvilket vil sige at vi kun vil præsentere skærmbillederne. Vi regner dog ikke med at dette vil have større indflydelse på vores kundes kommentarer til GUI, da han generelt har accepteret vores forslag uden at komme med større forslag til ændringer. Vi mener også at han er mere interesseret i at se et produkt, der kan gøre noget, istedet for blot vinduer, der åbnes og lukkes.

Vi har valgt at præsentere vores vinduer/mock-up ved at lægge hvert vindue på et bilag (Bilag 3a, 3b, 3c, 3d, 3e, 3f, 3g, 3h, 3i og 3j). Ved hvert bilag er der en beskrivelse af vinduets relation til OOA-modellen, samt hvad de forskellige elementer i vinduet viser/medfører. For at simulere en kørsel, startes på bilag 3a. Vi har ikke beskrevet alle knapper, da nogle af disse er trivielle. Knapper der går igen i alle vinduer er hjælp, der bringer et hjælpevindue frem og afslut, der lukker det aktuelle vindue (og slutter programmet helt i hovedmenuen).
Medmindre andet er nævnt er funktionen tilgængelig for alle (der skal ikke indtastes password).

5. Brugerreaktioner

Den 18/4 havde vi aftalt et møde med vores bruger, hvor han skulle evaluere vores foreløbige GUI. Desværre blev han syg og kom ikke til mødestedet.
Begynderbrugeren Jens var tilstede, men da vi ikke tidligere har diskuteret detaljer i projektet med ham, mente vi at det ville være til mere skade end gavn at begynde at inddrage ham i processen. Vi aftalte dog med Michael at han var rask og tilstede i butikken i uge 17, så han kan evaluere GUI'en.
Imidlertid har kunden (den 27/3) set og kommenteret/rettet vores skitser til GUI. Disse skitser var lavet i hånden, men har rimelig lighed med det "endelige" udkast. Udover kundens reaktioner har vi fremlagt skærmbillederne for holdet, der gav deres bud på eventuelle ændringer. Vi har ikke indført disse ændringer, da vi har tænkt os at snakke med kunden først. Han har måske andre ønsker.
Under vores forskellige møder med kunden har vi observeret at han er meget mere interesseret i funktionalitet end udseende. Det har været svært at få ham til at komme med udspil til brugergrænseflader, så det meste har vi "fundet på" selv.