User-Centered Design and DevelopmentCopyright Notice484-W05 QuarterChapter 7Chapter OverviewMotivationObjectivesIdentifying needs and establishing requirementsOverviewWhat, how and why?Slide 11Establishing requirementsDifferent kinds of requirementsSlide 14Slide 15Slide 16Exercise: Kinds of requirementsActivity: RequirementsActivity: Task SuggestionsData Gathering TechniquesQuestionnairesInterviewsWorkshops and Focus GroupsObservationStudying DocumentationChoosing between techniquesActivity: Data Gathering TechniquesData Gathering Problems (1)Data Gathering Problems (2)Data Gathering Problems (3)Some basic guidelines (1)Some basic guidelines (2)Data interpretation and analysisTask descriptionsScenario for shared calendarUse case for shared calendarAlternative courses for shared calendarActivity: Task DescriptionsExample use case diagram for shared calendarExample essential use case for shared calendarTask analysisHierarchical Task AnalysisExample Hierarchical Task AnalysisExample Hierarchical Task Analysis (plans)Example Hierarchical Task Analysis (graphical)Activity: Task AnalysisSummaryUser-Centered Design and Development Instructor: Franz J. KurfessComputer Science Dept.Cal Poly San Luis ObispoFJK 2005Copyright Notice•These slides are a revised version of the originals provided with the book “Interaction Design” by Jennifer Preece, Yvonne Rogers, and Helen Sharp, Wiley, 2002.•I added some material, made some minor modifications, and created a custom show to select a subset.–Slides added or modified by me are marked with my initials (FJK), unless I forgot it …FJK 2005484-W05 Quarter•The slides I use in class are in the Custom Show “484-W05”. It is a subset of the whole collection in this file.•Week 4 contains slides from Chapters 6 and 7 of the textbook. •The original slides are a bit of a mess, and I cleaned up various issues–outline view ddidn’t show body text–quite a bit of “manual” formatting (bulleted/numbered lists)FJK 2005Chapter 7Needs and RequirementsFJK 2005Chapter Overview•Needs•Requirements•Data Gathering•Data Interpretation and Analysis•Task Description•Task AnalysisFJK 2005FJK 2005Motivation•for user-centered design, it is critical to know the needs of the user•these needs are often described more formally through requirements•since users are not always able to express their needs directly, data gathering techniques are used to collect information•the collected information needs to be interpreted and analyzedFJK 2005Objectives•gain experience identifying user needs and transforming them into requirements•be familiar with various techniques for data gathering, interpretation, and analysis•learn to utilize methods for developing task descriptionsIdentifying needs and establishing requirementsOverview •The importance of requirements •Different types of requirements•Data gathering•Task descriptions:–Scenarios–Use Cases–Essential use cases•Task analysis: HTAWhat, how and why? •What:–Two aims: 1. Understand as much as possible about users, task, context2. Produce a stable set of requirements•How:–Data gathering activities–Data analysis activities–Expression as ‘requirements’–All of this is iterativeWhat, how and why? •Why:–Requirements definition: the stage where failure occurs most commonly–Getting requirements right is crucial• Establishing requirements •What do users want? What do users ‘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 dataDifferent kinds of requirements•Functional: –What the system should do–Historically the main focus of requirements activities•Non-functional–memory size, response time... • Data:–What kinds of data need to be stored?–How will they be stored (e.g. database)?Different kinds of requirements•Environment or context of use:–physical: dusty? noisy? vibration? light? heat? humidity? …. (e.g. OMS insects, ATM)–social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients–organisational: hierarchy, IT department’s attitude and remit, user support, communications structure and infrastructure, availability of trainingDifferent 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 pathsDifferent kinds of requirements•Usability: –learnability–throughput–flexibility–attitudeNote that user requirements and usability requirements refer to different thingsExercise: Kinds of requirementsWhat factors (environmental, user, usability) would affect the following systems?•Self-service filling and payment system for a petrol (gas) station•On-board ship data analysis system for geologists searching for oil•Fashion clothes websiteActivity: Requirements•Select a task, and try to identify different kinds of requirements–functional/non-functional–data–context–environment–user characteristics–usabilityFJK 2005Activity: Task Suggestions•video downloading application•voice interaction with household devices•touch-screen ordering system for cafeteria ordering•navigation system for motorcyclesFJK 2005Data Gathering Techniques•Questionnaires•Interviews•Workshops and Focus Groups•Naturalistic Observation•Studying DocumentationQuestionnaires•A series of questions designed to elicit specific information –questions may require different kinds of answers: •simple YES/NO•choice of pre-supplied answers; comment•Often used in conjunction with other techniques•Can give quantitative or qualitative data•Good for answering specific questions from a large, dispersed group of peopleInterviews•Forum for talking to people •Structured, unstructured or semi-structured •Props can be used in interviews–e.g. sample scenarios of use, prototypes•Good for exploring issues •But are time consuming and may be infeasible to visit everyoneWorkshops and Focus Groups•Group interviews •Good at gaining a consensus view and/or highlighting areas of