Requirements gathering Storyboarding Prototyping Chapter 6 Requirements gathering Storyboarding Prototyping

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

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

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 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 1.4.1. Browse in kitchen 1.4.2. Browse while watching TV 1.4.3. Browse in bed 2. Mark items

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?

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

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: ???

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

Storyboard example (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

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

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