1 / 27

Chapter 6

Requirements gathering Storyboarding Prototyping. 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. Architectural design. Detailed design. Coding.

shana
Download Presentation

Chapter 6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements gathering Storyboarding Prototyping Chapter 6

  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. Architectural design Detailed design Coding Integration & deployment Maintenance 6.2 Waterfall model of lifecycle (revised) Requirements specification

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

  16. Catalogue exampleFunctional requirements • Functional requirements Functional requirement 1 • 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) 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...

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

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

More Related