人机交互技术 Week 12_Task descriptions

Recap: Different Kinds of Requirements

• Functional requirements
• Data requirements
• Environmental requirements
  • Physical requirements
  • Social requirements
  • Organizational requirements
  • Technical requirements
• User requirements
• Usability requirements

Data gathering techniques: Recap

Essentially a small number of basic techniques for data gathering

• questionnaires
• interviews
• focus groups and workshops
• naturalistic observation
• studying documentation

Data gathering techniques are flexible and can be combined and extended in many ways.

Choosing between techniques: Recap

Choosing between data-gathering techniques rests on two issues:

1. The nature of the data gathering technique itself
2. The task to be studied

The choice of technique is also affected by the kind of task to be studied:

• Sequential steps or overlapping series of subtasks?
• High or low information content -> complex or simple displays
• Task for a layman or a skilled practitioner?

Task descriptions

Business Scenarios

• commonly used as the basis for acceptance testing

• Task descriptions are used throughout development, from early requirements activities through prototyping, evaluation, and testing due to the emphasis on involving users earlier in the development lifecycle
• Different flavors of task descriptions
  • Scenarios
  • Use cases
  • Essential use cases
  • may be used to describe either existing tasks or envisioned tasks with a new device.
  • not mutually exclusive

Scenarios

• an informal narrative story, simple, ‘natural‘: describes human activities or tasks in a story that allows exploration and discussion of contexts, needs, and requirements
• the constructions of scenarios by stakeholders is often the first step In establishing requirements
• Understanding why people doings as they do and what they are trying to achieve in the process allows us to concentrate on the human activity rather than interaction with technique
• personal, not generallsable: the LOD present varies, and there is no particular guidance about how much or how little should be Included, (workshop or interview sessions)

Scenario for library catalog service

"Say I want to find a book by George Jeffries. I don‘t remember the title but I know it was published before 1995.I go to the catalog and enter my user password.I don‘t understand why I have to do this, since I can‘t get into the library to use the catalog without passing through security gates. However, Once my password has been confirmed, I am given a choice of searching by author or by date, but not the combination of author and date. I tend to choose the author option because the date search usually identifies too many entries. After about 30 seconds the catalog returns saying that there are no entries for George Jeffries and showing me the list of entries closest to the one I‘ve sought. When I see the list, I realize that in fact I got the author‘s first name wrong and it‘s Gregory, not George.I choose the entry I want and the system displays the locations to tell me where to find the book."

Use cases

• assume interaction with a system
  • also focus on user goals, but the emphasis here Is on a user-system Interaction rather than the user‘s task itself.
• The stress is still very much on the user‘s perspective, not the system‘s.

• A use case is associate with an actor, and it is the actor‘s goal in using the system that the use case wants to capture.

• The main use case describes what is called the "normal course" through the use case, i.e., the set of actions that the analyst believes to be most commonly performed.

• Other possible sequences, called alternative courses, are then listed at the bottom of the use case.

Use case diagram for library catalog service

One use case is "Locate book", and this would be associated with the "library member" actor. The other main actor is the "Librarian." A use case for the "librarian" would be "update catalog"

Use case of Locate Book

1. The system prompts for user name and password.
2. The user enters his or her user name and password into the catalog system.
3. The system verifies the user‘s password.
4. The system displays a menu of choices.
5. The user chooses the search option.
6. The system displays the search menu.
7. The user chooses to search by author.
8. The system displays the search author screen.
9. The user enters the author‘s name.
10. The system displays search results.
11. The user chooses the required book.
12. The system displays details of chosen book.
13. The user notes location.
14. The user quits catalog system.

Alternative courses for Locate Book

Some alternative courses:

1. If user password is invalid
   • The system displays an error message.
   • The system returns to step 1.
2. If the user knows the book details
   • The user chooses to enter book details
   • The system displays book details screen
   • The user enters book details
   • The system goes to step 1 2

• Scenarios: concentrate on realistic and specific activities.Can obscure broader issues concerned with the wider organizational view.
• Use cases contain certain assumptions, including the fact that there is a piece of technology to interact with, and also assumptions about the user interface and the kind of interaction to be designed.
• Essential use cases
  • abstract away from the details
  • does not have the same assumptions as use cases
  • Division between user and system responsibilities, very helpful during conceptual design

Example essential use case for library catalog service

LocateBook

USER INTENTION	SYSTEM RESPONSIBILITY
identify self	verify identity
offer known details	request appropriate details
note search results	offer search results
quit system	close

Task analysis

• Task descriptions are often used to envision new systems or devices
• Task-analysis is used mainly to investigate an existing situation
• It is important not to focus on superficial activities, but to analyze the underlying rational and purpose of what people are doing:
  • What are people trying to achieve?
  • Why are they trying to achieve it?
  • How are they going about it?
• Task analysis is an umbrella term that covers techniques for investigating cognitive processes and physical actions, at a high level of abstraction and in minute detail
• Many techniques, the most popular is Hierarchical Task Analysis (HTA)
• Another well-known task analysis technique called GOMS (goals, operations, methods, and selection rules) models procedural knowledge.

Example Hierarchical Task Analysis

1. In order to borrow a book from the library
2. go to the library
3. find the required book
   • 2.1 access library catalogue
   • 2.2 access the search screen
   • 2.3 enter search criteria
   • 2.4 identify required book
   • 2.5 note location
4. go to correct shelf and retrieve book
5. take book to checkout counter

• plan 0: do 1 - 3 - 4. If book isn‘t on the shelf expected, do 2 - 3 - 4
• plan 2: do 2.1 - 2.4 - 2.5. If book not identified do 2.2 - 2.3 - 2.4 - 2.5

Class Activity

Write a scenario of how you would currently go about choosing a brand new car.

Summary

• Getting requirements right is crucial
• There are different kinds of requirement, each is significant for interaction design
• The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups and workshops, naturalistic observation, studying documentation
• Scenarios, use cases and essential use cases can be used to articulate existing and envisioned work practices.
• Task analysis techniques such as HTA help to investigate existing systems and practices

人机交互技术 Week 12_Task descriptions

原文：https://www.cnblogs.com/whale90830/p/11028719.html