Ekstra plancher til Anskaffelse og kravspecifikation, Forår 2007 Kompendiet del A: User Interface Design 5. Visions and Tasks De fleste af plancherne vedrører kompendiet. De er nummeret sådan: KA: Fig 5.1 Visions for... dvs. Kompendiet, del A, Fig 5.1. (Står nummeret i parentes, er planchen en tilføjelse til denne del af kompendiet). Enkelte plancher er fra lærebogen, Software Requirements, men diskuteres sammen med kompendiet. De er nummereret sådan: SR: Fig 3.11 High-level tasks

KA: Fig 5.1 Visions for the hotel system Task list T1.1Book room T1.2Check in T1.3Check out T1.4Change room T1.5Record services and breakfast list Data model D1.Guests D2.Rooms D3.Services Business goals: -Small hotel market -Much easier to use and install than current systems. -Interface to existing Web-booking systems. Requirements: R1:Store data according to data model. R2:Support tasks T1 to T5.... R7:Usable with 10 minutes of instruction.

KA: Fig 5.2 Data model for the hotel system Stay Room State Room Service Received Service Type date, personCount, state (booked | occupied | repair) name, address1, address2, address3, phone passport roomID, bedCount, type price1, price2 name, price date, quantity Guest stayID, paymethod, state (booked | in | out | canceled)

KA: Fig 5.3A Annotated task list for the hotel system Task list 1. Reception T1.1Book room. May involve many rooms. T1.2 Check in. Some guests have booked in advance, some not. T1.3 Check out. Review account, then invoice. Problem: Checkout queue in the morning. Solution? Self-service checkout. T1.4 Change room. Possible any time during the stay. T1.5 Record services and breakfast list. Breakfast list daily, service notes at any time. Clever: Special screen for breakfast list. 2. Staff scheduling T2.1 Record leave T Work area Possible future Present way Task: Domain-level, now and future Imperative language

Problem: Guest wants neighbor rooms; price bargain. Problem: Guest forgets to return the key; guest wants two keys. Subtasks: 1.Find room. 1a.Guest has booked in advance. 1b.No suitable room. 2.Record guest data. 2a.Guest recorded at booking. 2b.Regular guest. 3.Record that guest is checked in. 4.Deliver key. T1.2:Check in Start:A guest arrives. End:The guest has got room(s) and key. Accounting started. Frequency:Total: Around 0.5 check ins per room per night. Per user: Difficult:A bus with 50 guests arrive Missing subtask? KA: Fig 5.3B Task description template Past: Problems VariantsUndo? Domain-level, now and future. Imperative language Full reference to a subtask: T1.2-4

KA: Fig 5.3C Session task with optional subtasks T1.6:Change booking Start:Guest calls End: Subtasks: 1.Find booking 2.Modify guest data, e.g. address (optional) 3.Modify room data, e.g. two rooms (optional) 4.Cancel booking (optional) Separate tasks? No, session task. The customer may want any of these. We don't know up front.

Problem: Guest wants neighbor rooms; price bargain. Problem: Guest forgets to return the key; guest wants two keys. Subtasks: 1.Find room. 1a.Guest has booked in advance. 1b.No suitable room. 2.Record guest data. 2a.Guest recorded at booking. 2b.Regular guest. 3.Record that guest is checked in. 4.Deliver key. T1.2:Check in Start:A guest arrives. End:The guest has got room(s) and key. Accounting started. Frequency:Total: Around 0.5 check ins per room per night. Per user: Difficult:A bus with 50 guests arrives Example solution: System shows free rooms on floor maps. System shows bargain prices, time and capacity dependent. (Simple data entry, see data model) (Search with many criteria, e.g. name, booking number, phone) System prints electronic keys. New key for each customer. Future: Computer part KA: Fig 5.3D Task & support approach Past: Problems Explicit actor

KA: Fig 5.4 Work area and user profile Work area: 1. Reception Service guests - small and large issues. Normally standing, for instance facing the guest. Frequent interrupts. Often alone, e.g. during night. User profile: Novice. Often a temporary job. IT knowledge: Simple text processing. Younger persons have surfed a bit on the Web. IT attitude: Part of the job, but not fascinating in itself. Domain knowledge: Knows only the very basics, for instance what check in is in the simplest case. Domain attitude: OK but not the career of life. It is just a temporary job. Discretionary use: Mandatory. Physical abilities: Normal sight, hearing, size, etc. User profile: Experienced. Often a life-time job. IT knowledge: Simple text processing. Some know more, of course. IT attitude: Curious about how it works in the job. Domain knowledge: Knows all the procedures and the special cases. Domain attitude: Likes the job. Likes to be an expert.

KA: Fig 5.5A Good and bad tasks Good tasks: Closed: From trigger to closure - “coffe break deserved” Session: Small, related tasks without breaks in one description Domain level: Hide who does what with imperative language Don’t program - “if the customer has booked then...” Examples: 1Manage rooms? 2Enter guest name and address? 3Book a guest? 4Check in a bus of tourists? More examples: 9Arrange a meeting? 10Monitor a power plant? 11Wonderland Web site? 12Computer game? 8Stay at the hotel? 5Change the guest’s address etc? 6Change booking? 7Cancel entire booking?

SR: Fig 3.11 High-level tasks Sub-tasks: 1.Select a hotel. Problem: We aren’t visible enough. 2.Booking. Problem: Language and time zones. Guest wants two neighbor rooms 3.Check in. Problem: Guests want two keys 4. Receive service 5. Check out Problem: Long queue in the morning 6. Reimburse expenses Problem: Private services on the bill Example solution: ? Web-booking. Choose rooms on web at a fee. Electronic keys. Use electronic key for self- checkout. Split into two invoices, e.g. through room TV. Task:1. A stay at the hotel Actor:The guest Purpose:... From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

SR: Fig 3.9. Scenarie (af den livlige slags) Scenarie: Aftenvagten Jan Larsen havde læst flittigt hele eftermiddagen og var noget udmattet da han kom kl. 18 for at tage sin vagt i receptionen. Den første opgave var at forberede modtagelsen af turistbussen, der kom kl. 19. Han printede alle check-ind blanketterne og lagde dem på skranken med værelsesnøglen på hver. Midt i det hele kom der en familje og spurgte efter værelser. De prøvede at tinge om prisen og Jan følte sig altid utilpas ved det. Skulle han give dem rabat? Heldigvis kom Maria ud fra kontoret. Med sit overbevisende smil tilbød hun dem 10% rabat på børnenes værelse. De sagde ja, og hun overlod resten til Jan. De ville have et naboværelse til børnene, og som sædvanlig kunne han ikke huske hvilke værelser der var naboer til hvad. Omkring 22 var alt endelig stille, og han begyndte at lave nogle af sine hjemmeopgaver. Men han blev straks søvnig. Shit - han måtte ikke sove på vagten førend kl. 1. Heldigvis kunne han surfe lidt på computeren. Det holdt ham vågen og hjalp ham også lidt med hjemmeopgaverne.

SR: Fig 3.12A Use cases vs. tasks Hotel system Booking Checkin Checkout Receptionist Account system UML use case diagram: Transfer actor Human and computer separated: Hotel system... Booking Hotel system Booking... Task descriptions. Split postponed: Account system Transfer From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002