CS459559 HumanComputer Interaction

1
CS459/559Human-Computer Interaction

• Requirements
• 9-19-2007
• Prof. Searleman, jets_at_clarkson.edu

2
Announcements

• Career Fair this week
• IBM Info Night Wed., 845 945, SC160
• Greg Lacey from IBM will talk on software
  development Thurs., 400, SC162
• Innovative ideas wanted
• Last week, President Collins asked that the
  campus community "think outside the box" to
  generate innovative ideas that could accelerate
  our future accomplishments. Your ideas could
  concern any aspect of campus activity academic
  programs, student life, academic facilities,
  residential facilities, etc.
• There is a survey tool to collect your ideas at
  http//www.clarkson.edu/ideas.

a horrible death to die
3
Outline

• Lifecycle Models (cont.)
• Identifying needs establishing requirements
• Personas
• finish reading Chapter 9 and Chapter 10
• also see Cooper (www.cooper.com personas)
• and HCI dictionary entry on personas
• Activity 3 look at the list of HCI presentation
  topics and bring in 3 choices for Friday (rank
  order as your 1st, 2nd 3rd choice) make
  webpage for your project

4
Recap Lifecycle models

• Show how activities are related to each other
• Lifecycle models are
• management tools
• simplified versions of reality
• Last time we looked at
• Waterfall, Spiral, RAD DSDM
• Today well discuss
• Xtreme Programming (XP, an agile methodology)
• Usability Engineering Model, Star

5
Extreme Programming (XP)

• Most prominent of the Agile methodologies
• Developed in late 1990s
• Adaptability emphasized over predictability
• expect requirements to change, so must adapt to
  them
• different from methods which attempt to define
  all requirements early in the life cycle
• Communication frequent verbal communication to
  ensure users and developers are on the same page
• Simplicity Start with simplest solution
  increase complexity as needed
• Feedback Unit tests, acceptance tests (testing
  utility), quick estimates

6
Extreme Programming (XP)

• Principles
• Design for today, not for tomorrow
• Throw code away if necessary
• Rapid feedback from customers
• Incremental rather than major changes
• Expect changes in requirements
• Less documentation
• Less emphasis on design
• May get tempted to keep adding features
• May concentrate user acceptance tests on utility
  neglecting other usability goals

7
The Star Model (Hartson and Hix, 1989)
8
ISO 13407
9
Four Basic Activities of Interaction Design

• Identifying needs and establishing requirements
• Developing alternative designs
• Building interactive versions of the designs
• Evaluating designs

10
What, how and why

• What
• Two aims
• Understand as much as possible about users, task,
  context
• Produce a stable set of requirements
• How
• Data gathering activities
• Data analysis activities
• Expression as requirements
• All of this is iterative

11
What, how and why?

• Why
• Requirements definition the stage where failure
  occurs most commonly

Getting requirements right is crucial
12
Establishing requirements

• What do users want? What do they need?
• Requirements need clarification, refinement,
  completion, re-scoping
• Input requirements document (maybe)
• Output stable requirements
• Why establish?
• Requirements arise from understanding users
  needs
• Requirements can be justified related to data

13
Different kinds of requirements

• Functional
• What the system should do
• Historically the main focus of requirements
  activities
• (Non-functional memory size, response time,
  physical constraints, ... )
• Data
• What kinds of data need to be stored?
• How will they be stored (e.g. database)?

14
Different kinds of requirements

• Environment or context of use
• physical dusty? noisy? vibration? light? heat?
  humidity? . (e.g. ATM)
• social sharing of files, of displays, in paper,
  across great distances, work individually,
  privacy for clients
• organizational hierarchy, IT departments
  attitude and remit, user support, communications
  structure and infrastructure, availability of
  training

15
An extreme example
16
Different kinds of requirements

• Users Who are they?
• Characteristics ability, background, attitude
  to computers
• System use novice, expert, casual, frequent
• Novice step-by-step (prompted), constrained,
  clear information
• Expert flexibility, access/power
• Frequent short cuts
• Casual/infrequent clear instructions, e.g. menu
  paths

17
Different kinds of requirements

• Usability learnability, throughput,
  flexibility, attitude
• Note again that user requirements and usability
  requirements refer to different things

18
Activity

• Suggest one key functional, data, environmental,
  user and usability requirement for each of the
  following
• A system for use in a universitys self-service
  cafeteria that allows users to pay for their food
  using a credit system.
• Cheel information kiosk

19
Know thy user

• Most users are neither beginners nor experts
  instead, they are intermediates. Cooper, About
  Face 2.0, p. 33
• Optimize for intermediates
• Rapidly and painlessly help beginners achieve
  intermediacy.
• Avoid putting obstacles in the way of those
  intermediates who want to become experts.
• Keep perpetual intermediates happy as they stay
  in the middle of the skill spectrum.

20
What beginners need

• Nobody wants to remain a beginner.
• Imagine that users are simultaneously very
  intelligent and very busy. They need some
  instruction or aid, but the process must be rapid
  and targeted.
• A newbie must grasp the concepts and scope of the
  program quickly gt ensure that the software
  reflects the users mental model of the tasks
• standard on-line help is insufficient for this
• a separate dialog box may be helpful to
  communicate overview, scope and purpose
• beginners rely heavily on menus to learn commands

21
What perpetual intermediates need

• Perpetual intermediates need access to tools
• tooltips
• online help
• Intermediates develop a frequently used working
  set of features
• May know that advanced features exist, but may
  not need them or know how to use them