1 / 18

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

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. Overview of Presentation. Our course in HCI Term projects

baris
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related