Requirements gatheringStoryboardingPrototyping

Chapter 6

By the end of this lecture you should be able to...

• Practically apply three phases of the UCD process:– Requirements gathering– Design and storyboarding– Prototype implementation

6.2 Waterfall model of lifecycle (revised)

Requirements specification

Architectural design

Detailed design

Coding

Integration & deployment

Maintenance

6.2 Stages of the Waterfall model (revised)

• Requirements specification– Functional requirements– Data requirements (Inputs and outputs)– Environmental requirements (context)– User requirements– Usability requirements

• Architectural design– Focus on how requirements can be achieved– E.g. OO, UML, ERD

• Detailed design, coding and unit testing– E.g. specification of classes, objects, methods and properties– Produce software

• Integration and testing– Integrate individual components– Put into operation

• Maintenance– Usage may identify further errors

UCSD revised

Task analysis

Requirements gathering

Design and storyboarding

Prototype implementation

Evaluation

Installation

Observation of existing systems

Usability guidelines & heuristics

Problem statement

Technical & legal etc. constraints

HTA

Requirement statement Functional Non-functional

Storyboard

Prototype

Transcript & evaluation report

Final implementation

6.2 Waterfall vs UCSD

• Advantages of Waterfall prior to release– Sequential process reduces cost and makes time management

easier– If problems are discovered after implementation numerous parts of

the system might be redesigned– Costs can spiral after implementation – after release

• Advantages of UCSD after release– User and user needs are central during design– Recognise that systems evolve through a process of iterative

refinement, rather than through linear process• Two key concepts of UCSD that is unfamiliar in W/F

– Formative evaluation: Each stage in UCSD is evaluated– Design iteration: UCSD allows for revisiting and refinement of design

6.4 Requirements gathering

• Describing what the proposed system should do– Not how it should do it, or what it should look like

• In UCSD: requirements cannot be used as contractual basis– Not possible to accurately specify requirements at the start of a

project– May be iteratively refined as design/development progresses– Clients might not ask for a feature because they did not know initially

that it is possible

• Output: The requirements statement– Functional requirements: What the system needs to do to be useful– Usability requirements: What the system needs to do to be usable– For each requirement

• What it is?• Where it comes from? (Justification) • Metric to measure system performance with respect to it (if possible)

Metrics

• A ‘metric’ is a way of measuring things– Metrics can be direct or indirect

• If you weigh something, then you are directly measuring its weight• Measuring the volume and density and then calculating the mass is

an indirect metric

• Most HCI metrics are indirect– Quantitative

• Time & response time• Key presses• Number of errors

– Qualitative• User satisfaction• User enjoyment

– None measure usability directly

Example: Usability Requirement

Usability Requirement

• The system should be learnableJustification

• The system will be used by people with little, if any, previous experience of IT

Metric

• A novice user should be able to successfully complete task X in 20 seconds

Sources (input) for requirements

• The HTA– The HTA should tell you all the tasks that the

system should support

• Usability guidelines & heuristics (principles)– Not the design rules– But you need to explain why the principles are

applicable

• Other constraints– Technical, legal, etc

• E.g. Laws on data protection for privacy

Exports (output) for requirements (continued)

• Functional requirements– Will closely correspond to the sub-tasks of the

HTA– Some sub-tasks will be identical and will

simply be automated

• Usability requirements– Typically things like learnability, recoverability,

flexibility, responsiveness, etc.

Types of requirements

• Functional requirements

• Usability requirements

• Data requirements

• Environmental requirements

• User requirements

Functional and Usability requirements

• Difference between useful and usable:– Useful: can do the task– Usable: easy to do the task

• Functional requirements:– What makes the system useful– Typically quantitative– They are there or not there

• e.g. ‘The system should allow the user to enter credit cards details and debit the user’s account accordingly’

– It is clear whether or not the system does or does not do this

• Usability requirements:– What makes the system usable– More qualitative– Might not be clear how to measure whether a system fulfils a usability

requirement or not

User, Data and Environment requirements

• User requirements– Who the users are?– What capabilities do they have?

• Environment requirements– Where will the system be used?– Under what circumstances?

• Data requirements– What data the system needs to input and output?– (Closely linked to functional requirements)

Catalogue Example: HTA

0.Using catalogues1. Browse items

1.1. Browse by what’s new1.2. Browse by sales1.3. Browse by items that interest1.4. Browse by catalogues

1.4.1. Browse in kitchen1.4.2. Browse while watching TV1.4.3. Browse in bed

2. Mark items

Catalogue exampleFunctional requirements

• Functional requirementsFunctional requirement 1– The user must be able to browse items in the

cataloguesBrowse by what’s newBrowse by salesBrowse by items that interestBrowse by catalogues

– Justification: Sub-task 1 from HTA– Metric: Can the system do it or not?

The catalogue example: Functional requirements (2)

Functional requirement 2– The user must be able to mark items for recall– Justification: Sub-task 2 from HTA.

• But recall that the HTA showed that the ways of marking things in the catalogue was problematic

• Therefore stronger justifications needed here...

The catalogue example: Usability requirements

• Usability requirements

Usability requirement 1– The system should be flexible– Justification: The HTA shows that the user

fits the task of browsing around other tasks. Therefore the system should be flexible to accommodate this.

– Metric: ???

Storyboards• Important that design must relate to

requirements – storyboards helpful here• Storyboards: Rough sketches of what the

system will look like– Good for predominantly graphical interfaces and

web sites

• Cheap to produce, easy to change• Maybe also need a ‘map’ showing how the

‘narrative’ of the storyboard runs• Storyboard = example of paper prototyping• Several articles on network

– H:\courses\ris224\2008\extra material\...

Storyboard example

Storyboardexample (2)

Storyboard example (3)

Storyboard example (4)

Prototypes• Consist of user interfaces that seem to look

and behave like a complete system– Can be tested on real users

• Purpose– To turn an abstract idea into physical form– To communicate your ideas– To iterate and improve

• Elicit information on– the functionality– operation sequences– user support– look and feel

• Characteristics– Should be ‘cheap’– Quick & Easy to change– Designers don’t get adhered to them– Usually cut down functionality

• Types of prototypes– Throw-away– Evolutionary– Incremental

• Several articles on network– H:\courses\ris224\extra material\...

Prototypes: Techniques• Rapid prototyping

– Done in MS Word, PowerPoint, LaTeX, DreamWeaver, etc.

• Sophistication– Hi-fi

• Have a lot of functionality of intended system• Expensive and time-consuming• Piece of software with limited functionality written in the target

language (e.g. Java, Perl) or another language (e.g. director)– Lo-fi

• Partially functional, cheaper• Series of screen sketches• Storyboard, i.e. a cartoon like series of sketches• Cardboard mock-up• Physical model e.g. lump of wood for Palm Pilot

• Horizontal and vertical– Horizontal: Pictures of the interface, no functionality– Vertical: Full functionality for a limited bit of the system– Full prototype: Complete functionality, low performance

• Wizard of Oz– The system is controlled by a designer

• Founder (Jeff Hawkins) carved a block of wood and carried it around with him...

Prototypes Lo-fi example 1:Palm Pilot

• Using paper, post-its, index cards to mock up interface menus

Prototypes: Lo-fi example 2