Laura Leventhal Julie Barnes Joe Chao Bowling Green State University Bowling Green, OH 43403

1. Term Project User Interface Specifications in a Usability Engineering Course: Challenges and Suggestions Laura Leventhal Julie Barnes Joe Chao Bowling Green State University Bowling Green, OH 43403

2. Overview of Presentation • Our course in HCI • Term projects • Requirements analysis and specification in our term project • Four (and a half) challenges to the instructor • Experiences and summary

3. Our course in HCI - Structure • One semester, three-credit course, usually taken by second-semester sophomores and juniors. • Prerequisite - 2 course sequence in C++. • Satisfies the eight core hour Human-Computer Interaction requirements (HC1 and HC2) as in CC2001, as well as many optional HCI elements. • We also cover some software engineering core hours.

4. Course Content and Makeup • Topics • “User interface” and “usability” • The process of UE • Evaluation and usability testing • Comparison of interaction styles • Term project completed by a team • Prerequisite for our software engineering course

5. Term Project • Teams of size three to six students. • Students go from the initial problem statement to the development of a prototype for the user interface (UI). • Students are required to specify the project requirements in terms of user tasks, select and justify an interaction style, design and develop a prototype, and perform user testing on their prototype. • Projects are typically file management type of problems. • Examples. Audio Catalog UI, High School Yearbook UI, Cookbook UI.

6. Term Project Requirements Analysis and Specification • Goals of analysis and specification activities in project. • Teach a way to analyze and specify a problem. • To familiarize students with the general problem of analysis and specification. • About 13% of the total points for the semester are for the analysis and specification of the tasks that the user will perform with the UI. • We do not require students to analyze and specify other aspects of requirements, such as user profiles due to time limitations. These are covered in class.

7. Why bother? • Why worry about whether students can perform requirements analysis and specification? • Generally little experience since teachers usually provide a specification for class assignments. • A common activity across a number of engineering disciplines. • Exposes students to a critical activity in software engineering. Although the specifics for UE and SE are different, in the abstract, both are about understanding the problem, usually from a variety of levels of abstraction and perspectives, and providing a detailed document that describes that understanding.

8. Term Project Requirements Analysis and Specification - Instructor Challenges • Presenting the project requirements in such a way that the students can understand the problem and generate a specification. • Defining the form and format for student work. • Teaching the process of specification. • Assessing the students’ work.

9. Challenge1: Presenting Project Requirements • Goal is for students to take project assignment, understand the tasks that the UI is to support in detail and generate documentation to describe their understanding. • How to present this information? • Have student extract from existing software • Scenarios (specific exemplars) • Function list • Description of entities and attributes • We use a combination of scenarios, function lists and description of entities and attributes. No one element is complete unto itself.

10. Challenge 2: Defining the Form and Format for Problem Specification • Students generate a notebook with • A title page and table of contents. • A graphical hierarchical diagram of the task analysis with subtrees color-coded. • Using the high level tasks to break the the document into sections, each major subtree will have its own (color-coded) section. Within the section, a diagram plus a narrative description of each task. • Tasks follow a hierarchical numbering scheme. • Use case analysis of scenarios. • Task checklist. Used during design to guarantee each task is represented in the design.

11. Task Narration Questions • Task description and position in hierarchy • User inputs and system responses (anticipated and exceptions) • Task characteristics such as frequency and constraints • Task sequencing • Usability expectations

12. Challenge 3: Teaching the Process of UI Specification • Spend about two weeks of class time going over examples of task analysis, including a number of in-class, small examples. In-class examples emphasize identifying user tasks from various presentation styles. • Students have access to old projects. • Teams have about three weeks to complete their specifications for the project. • Require two meeting with the GA during the analysis and specification phase.

13. Challenge 3.5: Getting students started • Although we do examples in class, many students don’t know how to get started. • Symptoms • Blank looks • Tree diagram for each scenario - no synthesis in the analysis • Non-productive group meetings • Need to give students a tool to help get them started - use case model.

14. Challenge 4: Assessing Student Work • Analysis and specification worth 70 points. The whole project is worth 160 points. • 20 points for presentation. These points are used to assess the format of the report. • 50 points for completeness, correctness, non-ambiguity.

15. Simple Example • See overheads

16. Some Observations • Students find the task of requirements analysis and specification to be difficult. • Students • want to get to the solution (coding). • want to use their own experiences and expertise to define the requirements rather than the project description. • have a very difficult time getting started. • don’t believe that they need a lot of detail. After all THEY understand what they are describing.

17. Addressing these issues • Going to the solution before understanding the problem • We enforce a methodology and timeline. A major part of our project points are for the analysis and specification. • Using their own expertise • Groups are required to meet with our GAs. • Not enough detail • Students have access to a library of old projects. • GA meetings can help to address this issue. • Having a standard format that emphasizes verbal detail. • Getting started • Synthesizing specific exemplars into abstract tasks, using some elements of Use Case models.

18. Summary and Conclusions • In general, students are able to perform task analysis and specification. • The Use Case model element of our approach seems to have helped students develop better specifications because it gives them a tool to get started. • We continue to use this approach in 2004.