UC IRVINE - ICS 121 Software Tools and Methods

Assignment 2: Mockup (10%)


Due in class Tuesday, November 9, 1999

Instructions

We continue the same problem of re-specifying the Siemens Cordless Phone. In this assignment, your managers have provided more details about requirements of interest to them. There are still many questions about functionality. Read the requirements. Create mockups and scenarios to help your managers better communicate their requirements to you or at least better understand what you intend to specify.

Your mockups and scenarios should consider the factors from the Cognitive Walkthrough discussion, namely issues of users' tasks and experience and how that compares with actions in the interface. However, your mockups and scenarios may be more narrative (story-like) than the formal Walkthrough procedure. You should have about 8 to 12 interface (screen) mockups with a paragraph explaining each as part of a scenario using your proposed interface. You should write a one to two page introduction to summarize your understanding of the Cordless Phone System. You may not be able to describe every function or requirement you would like in your scenarios. Explain such extensions in a one page summary at the end.Turn in completed assignments in class on November 9, 1999. Late assignments lose 10% (of the 10%).

In this project, scenarios and specifications will apply both to the physical interface components of the phone (dial buttons, additional funtion buttons) as well as its display. You may make a liberal interpretation of the device. In other words, you can decide what buttons, how many lines of display, etc. the new version of the phone will have.

Remember that text should be typed or formatted while graphics may be drawn by hand neatly. Also, include your name, student number, and the tittle of the Assignment, "Assignment 2: Mockup."

Requirements

  1. Functionality - Address Book. An address book capability should allow users of the phone to input a few hundred names and telephone numbers. The address book should be searchable. When a name and number is returned from a search, there should be an option to dial that number automatically. If the number is busy, the phone should offer to redial.
  2. Functionality - Caller ID. The phone should display the caller ID when available. If a number is available, the phone needs to check that number against the address book. The address book can supply the name of the individual(s) at that number. A profile might also be kept. Perhpas it is associated with the address book. The profile will allow such functionality as different ring sounds for different individuals.
  3. Functionality - Additional. You can think of lots of scenarios!
  4. Minimal Correctness (Reliability). The phone should work at least to make calls as long as there is a dial tone! If there is a dial tone, it should always be possible, whatever other function the phone is engaged in, to place a 911 call.
  5. Robustness. Ussers might hit the wrong keystrokes during lots of functions. There should always be an escape key to get out of functions. If users hit unexpected keys or other inputs, the phone shoudl "do the right thing." For instance, there should never be a default action of deleting a name from the address book or a default response that disconnects the line.
  6. Performance. There should be no delays to actions. Even inputing addresses and names, there should always be an instantaneous reponse, even if only to echo a key touch.
  7. Usability. Functionality should be as simple and as learnable as possible!
  8. Security. It should be possible for users to have security in use of the phone. For example, it shoudl be possible that only authorized users can read or alter the address book, lock out the phone, or selectively lock out functionality such as calls to long distance area codes or exchanges.

ICS121 FQ99
David F. Redmiles ­ Home Page
Department of Information and Computer Science
University of California, Irvine CA 92717-3425