Quality Assurance Criteria
User Interface Prototype
-
The Purpose is to describe the manner in which the human user will interact
with the software system.
-
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.
-
Complete directions are included which explain where the prototype is located
and how to run it.
-
Every functional aspect of the software is depicted.
-
The prototype contains a depiction of every window, dialog, menu, button,
error message, etc in the system.
-
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.
-
The prototype should be self-explanatory. The prototype is incomplete if
the author has to explain how particular aspects will operate.
-
Follow the Interface Design Guidelines in your textbook and the UI
Design Criteria.
-
Make sure your design doesn't violate any of Dr. Dalbey's pet
peeves.
-
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.)