Presentation is loading. Please wait.

Presentation is loading. Please wait.

The importance of requirements Data gathering for requirements Task descriptions:Scenarios Use Cases Essential use cases Task analysis: HTA.

Similar presentations


Presentation on theme: "The importance of requirements Data gathering for requirements Task descriptions:Scenarios Use Cases Essential use cases Task analysis: HTA."— Presentation transcript:

1

2 The importance of requirements Data gathering for requirements Task descriptions:Scenarios Use Cases Essential use cases Task analysis: HTA

3  Your task is to come up with ideas that improve the experience of standing in line - waiting. In other words, re-design the experience of waiting in line.

4 What Two aims: 1.Understand as much as possible about users, tasks, context 2. Produce a stable set of requirements How: Data gathering activities Data analysis activities All of this is iterative

5 What Two aims: 1.Understand as much as possible about users, tasks, context 2. Produce a stable set of requirements How: Data gathering activities Data analysis activities All of this is iterative Who waits in line? Age, interests, beliefs, culture, reading ability, gender, tech skill/interests, profession, etc. Where do they wait in line? Starbucks, book store, doctor’s office, bank, train station, airport, traffic, etc. When do they wait in line? Early morning, morning, mid-day, evening, late night, etc. Why are they waiting? Coffee, pay bills, go on ride, driver test, medical appointment, traveling, business, etc. This information helps tell us the requirements of the project. How do we get this information?

6 Why: Requirements definition: the stage where failure occurs most commonly Getting requirements right is crucial

7 Why: Requirements definition: the stage where failure occurs most commonly Getting requirements right is crucial Sandra belongs to TJAMS (Traffic Jam Are Miserable Stuff). She waist hours in traffic, spends too much on fuel and her cars pollutes the environment. TJAMSers want to know exact costs (in time and money) to each driver, and the amount of harmful emissions per vehicle. TJAMS created a secure web app interface to track driver data, characteristics, location, car type, driving preferences, temporal data, driving patterns etc. Users log-in and enter user profile info, to access a wealth of data. They get analyses on driving patterns, emission trends, articles on pollution, etc. Problem: Driver data they must be entered while in traffic. Difficult because drivers must log in, and make a series of interface selections that are difficult in traffic. What was needed: 1) Large button Start time in traffic, 2) End Time end, 3) Choice of car button – that can be click while in traffic or when car is stopped.

8 What do users want? What do users ‘need’? -Requirements need clarification, refinement, completion, re-scoping Why ‘establish’? -Requirements arise from understanding users’ needs TRJAMS Example: What was needed: 1) Large button Start time in traffic, 2) End Time end, 3) Choice of car button – that can be click while in traffic or when car is stopped.

9 Functional: —What the system should do (Non-functional: memory size, response time...) Data: —What kinds of data need to be stored? —How will they be stored (e.g. database)?

10 Environment or context of use: — physical: dusty? noisy? vibration? light? heat? humidity? …. (e.g. ATM) — social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients (e.g. social network) — organizational: hierarchy, IT department’s attitude and remit, user support, communications structure and infrastructure, availability of training

11 What are the users’ capabilities? Humans vary in many dimensions: size of hands may affect the size and positioning of input buttons motor abilities may affect the suitability of certain input and output devices height if designing a physical kiosk strength - a child’s toy requires little strength to operate, but greater strength to change batteries disabilities (e.g. sight, hearing, dexterity)

12 Users: Who are they? — Characteristics: ability, background, attitudes — System use: novice, expert, casual, frequent — Novice: step-by-step, clear information — Expert: flexibility, access/power — Frequent: short cuts — Casual/infrequent: clear instructions, e.g. menu paths

13  Capture user characteristics  Not real people, but synthesised from real user characteristics  Should not be idealised  Bring them to life with a name, characteristics, goals, personal background  Develop multiple personas

14  Martha is 68 years old grandmother who is very concerned about the environment and what pollutants will do to the world her grandchildren will inherit.  She drives 23 miles to work each day in the city. Each morning and evening she waits approximately 1 hour and 30 minutes in traffic each way.  She drives a 2011 Ford Focus because of it fuel efficiency. Driving makes here very nervous. She dreads long traffic jams. She does not like to talk on her cellphone when driving. She occasionally listens to NPR or WYEP.

15 Interviews: — Props, e.g. sample scenarios of use, prototypes, can be used in interviews — Good for exploring issues — But are time consuming and may be infeasible to visit everyone Focus groups: — Group interviews — Good at gaining a consensus view and/or highlighting areas of conflict — But can be dominated by individuals internet-connected swiss army knife … but where is that thumb?

16 TJAMS Log Start Time Log End Time TJAMS HoursMinutesSeconds

17 Questionnaires: — Often used in conjunction with other techniques — Can give quantitative or qualitative data — Good for answering specific questions from a large, dispersed group of people Researching similar products: — Good for prompting requirements

18 Direct observation: — Gain insights into stakeholders’ tasks — Good for understanding the nature and context of the tasks — But, it requires time and commitment from a member of the design team, and it can result in a huge amount of data Indirect observation: — Not often used in requirements activity — Good for logging current tasks

19 Direct observation: — Gain insights into stakeholders’ tasks — Good for understanding the nature and context of the tasks — But, it requires time and commitment from a member of the design team, and it can result in a huge amount of data Indirect observation: — Not often used in requirements activity — Good for logging current tasks TJAMS Example: Driving to work with someone like Martha. Ask her to enter data.

20 Contextual Inquiry An approach to ethnographic study where user is expert, designer is apprentice A form of interview, but — at users’ workplace (workstation) — 2 to 3 hours long Main principles: — Context: see workplace & what happens — Partnership: user and developer collaborate

21 Focus on identifying the stakeholders’ needs Involve all the stakeholder groups Use a combination of data gathering techniques For TJAMS Example Send Questionnaire To Drivers Interview Selected Drivers Observe Drivers Examine Other Products That People Use While Driving.

22 Support the process with props such as prototypes and task descriptions Run a pilot session Consider carefully how to record the data internet-connected swiss army knife … but where is that thumb?

23 Understanding the user tasks

24 Scenarios ―an informal narrative story, simple, ‘natural’, personal Use cases —assume interaction with a system —assume detailed understanding of the interaction Essential use cases —abstract away from the details —does not have the same assumptions as use cases

25 Scenario 1-What is a traffic Jam?: Martha left work at 5:25PM. As Martha leaves the Company XYZ garage, she is stopped by traffic. She begins to reach for her phone to access the TJAMs app so she can log her data. Traffic begins to move so she stops reaching for her phone. Traffic stops abruptly and then begins to move but at a snail’s pace. Scenario 2- Martha is visiting her friend in New York. Regrettably, she arrives in the city at rush hour. It is raining. She is a nervous driver and is unsure of her directions. It is dark outside. The headlights and rain make for poor visibility. Martha turns off NPR radio station. She begins to reach for her phone to access the TJAMs app so she can log her data but impatient driver, with horn sounding, cuts in front of her.

26 1.Turn on phone. 2.User taps TJAMS icon to access app. 3.User taps Begin Traffic Jam button to start recording amount of time in traffic. 4.System periodically prompts user to see if Jam has ended. 5.System prompts user for make of car, if not previoulsy entered. 6.System logs current gas prices in region. 7.System automatically logs user’s location. 8.User taps End Traffic Jam button to end recording amount of time in traffic. 9.System updates data. 10.System makes data available for others to view.

27 System User Begins traffic jam times System logs current gas prices in region System automatically logs user’s location System updates data. System makes data available

28 USER INTENTIONSYSTEM RESPONSIBILITY Turn on phone. Access app. Start recording time in traffic. Log gas prices in region. Logs user’s location. Updates data. Make Data available.

29 Essential use case Describes task at high level of abstraction

30  Task descriptions are often used to envision new systems or devices  Task analysis is used mainly to investigate an existing situation  It is important not to focus on superficial activities What are people trying to achieve? Why are they trying to achieve it? How are they going about it?  Many techniques, the most popular is Hierarchical Task Analysis (HTA)

31  Involves breaking a task down into subtasks, then sub-sub-tasks and so on. These are grouped as plans which specify how the tasks might be performed in practice  HTA focuses on physical and observable actions, and includes looking at actions not related to software or an interaction device  Start with a user goal which is examined and the main tasks for achieving it are identified  Tasks are sub-divided into sub-tasks

32 0.In order to borrow a book from the library 1.go to the library 2.find the required book 2.1 access library catalogue 2.2 access the search screen 2.3 enter search criteria 2.4 identify required book 2.5 note location 3.go to correct shelf and retrieve book 4.take book to checkout counter

33 Borrow a book from the library go to the library find required book retrieve book from shelf take book to counter 3214 0 access catalog access search screen enter search criteria identify required book note location plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4. plan 2: do 2.1-2.4-2.5. If book not identified from information available, do 2.2-2.3-2.4-2.5 2.12.22.32.42.5

34

35

36

37  Write a tasks analysis for an e-commerce Web site that sells T-shirts.  The analysis should encompass login though receipt.


Download ppt "The importance of requirements Data gathering for requirements Task descriptions:Scenarios Use Cases Essential use cases Task analysis: HTA."

Similar presentations


Ads by Google