1. Requirements gathering Storyboarding Prototyping
Chapter 6
Requirements gathering
Storyboarding
Prototyping

2. 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

3. 6.2 Waterfall model of lifecycle (revised)
Requirements specification
Architectural design
Detailed design
Coding
Integration & deployment
Maintenance

4. 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

5. UCSD revised

6. 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

7. 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)

8. 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

9. Example: Usability Requirement
The system should be learnable
Justification
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

10. 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

11. 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.

12. Types of requirements Functional requirements Usability requirements
Data requirements
Environmental requirements
User requirements

13. 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

14. 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)

15. Catalogue Example: HTA
0. Using catalogues
1. Browse items
1.1. Browse by what’s new
1.2. Browse by sales
1.3. Browse by items that interest
1.4. Browse by catalogues
Browse in kitchen
Browse while watching TV
Browse in bed
2. Mark items

16. Catalogue example Functional requirements
The user must be able to browse items in the catalogues
Browse by what’s new
Browse by sales
Browse by items that interest
Browse by catalogues
Justification: Sub-task 1 from HTA
Metric: Can the system do it or not?

17. The catalogue example: Functional requirements (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...

18. The catalogue example: Usability requirements
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: ???

19. 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\...

20. Storyboard example

21. Storyboard example (2)

22. Storyboard example (3)

23. Storyboard example (4)

24. 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\...

25. 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

26. Prototypes Lo-fi example 1: Palm Pilot
Founder (Jeff Hawkins) carved a block of wood and carried it around with him...

27. Prototypes: Lo-fi example 2
Using paper, post-its, index cards to mock up interface menus