Quality Assurance Criteria
User Interface Prototype
  1. The Purpose is to describe the manner in which the human user will interact with the software system.

  2.  
  3. The style of the prototype (storyboard, Wizard of Oz, or others) is agreed upon with the instructor.  In general the simpler the better.  Don't spend a lot of time creating a functioning prototype without the instructor's approval. You will be demonstrating your prototype in the lab so any prototyping tools you use must work on the platform available in the lab.

  4. Complete directions are included which explain where the prototype is located and how to run it.

  5.  
  6. Every functional aspect of the software is depicted.

  7.  
  8. The prototype contains a depiction of every window, dialog, menu, button, error message, etc in the system.

  9.  
  10. Appropriate annotations describe any aspects which are not obvious. Navigational cues give directions that enable the reader to simulate a walkthrough of the system functions.

  11.  
  12. The prototype should be self-explanatory. The prototype is incomplete if the author has to explain how particular aspects will operate.

  13.  
  14. Follow the Interface Design Guidelines in your textbook and the UI Design Criteria.

  15.  
  16. Make sure your design doesn't violate any of Dr. Dalbey's pet peeves.

  17. Importantly, the customer or sponsor must sign off on the prototype.  The UI must meet the customer's needs, so the prototype isn't finished until the customer is happy with it. (If your project doesn't have an external customer, then perform a usability evaluation (Lethbridge 274-276) and post the results on your team web site.)