1 / 53

Requirements and Task Analysis

Requirements and Task Analysis. Please attend!!. Duke Hutchings : “Window interfaces for multiple monitor systems”: next Monday 2/6, 9:30-11, room 154 student meeting: 2/6 2-2:45, room 338

Download Presentation

Requirements and Task Analysis

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 and Task Analysis

  2. Please attend!! • Duke Hutchings: “Window interfaces for multiple monitor systems”: next Monday 2/6, 9:30-11, room 154 • student meeting: 2/6 2-2:45, room 338 • Jeff Nichols: “Automatically Generating High-Quality User Interfaces for Appliances” next Thursday 2/9 2-3:30, room 356 • student meeting: 2/10 1-1:45, room 338 • George Chin: “Capturing, Representing, and Implementing Scientific Knowledge in Scientific Computing Environments”: 2/13 9:30-11, room 154 • student meeting: 2/13 2-2:45, room 338 • Celine Letulipe: “Symmetric Interaction Techniques”: 2/20 2-3:30, room 356 • student meeting: 2/21 2:30-3:15, room 441

  3. Project Part 1 reminder • Due Feb. 16 (2 weeks!) by class time • READ description and template • Focus on the problem, not the solution • Start gathering your data now! • Ask for help and feedback • Good communication skills are key • And please spell and grammar check

  4. Historically requirements Features, functions that the system should do Properties of the overall system “-ilities” (quality, evolveability, flexibility, etc.) Environment User requirements Usability requirements Functional vs. NonFunctional

  5. Not just “requirements” • Overall goals, success criteria • User characteristics • Task analysis • Environment – physical, social, technical • Constraints • Usability goals, criteria

  6. User Characteristics: Recall • Attitude, morale, willingness to change, motivation, reading level, typing skill, education, frequency of use, training, color-blindness, handedness, gender,… • Novice, intermediate, expert • System experience, task experience, computer literacy • Cultural factors • Uses of icons, colors, words, metaphors

  7. Task Analysis • Process of analyzing and documenting how people perform their jobs or activities • Task-subtask decomposition • Focus on: • Activities • Artifacts • Relations • More in a moment…

  8. Physical Environment • Amount of space to work • Lighting levels / directions • Noise level • Temperature, humidity, dust… • Standing / sitting • Power availability • Dangers Implications?

  9. Technical Environment • Computers/platforms for application • Technology to interact with • Networking • Mobility Implications?

  10. Social Environment • How do users interact? Roles? • How do users interact with others? • Social implications of problem or solution? • Interruption • Privacy Implications?

  11. Stakeholders • Primary – targeted end users • Secondary – receive output or provide input to system • Tertiary – others directly receiving benefits from system success or failure • Facilitating – design, development, maintenance

  12. Stakeholder analysis • Cell phone • Bus stop kiosk • Nuclear power plant control system

  13. Typical Real-World Constraints • Elapsed time to market • Cost/effort to design and implement • Size/footprint/weight/power/price • Computer power/memory (related to cost and power • Consistency with overall product line • Backward compatibility • Differentiation from competitive products

  14. Usability Requirements • Usability goals: such as learnability, consistency, robustness, etc. • Ways to measure and judge success • Time to complete key tasks - min, max • Time to become proficient - do given set of tasks in given time • Subjective satisfaction

  15. Example What factors (environmental, user, usability) would affect the following systems? • Self-service filling and payment system for a gas station • On-board ship data analysis system for geologists searching for oil • Fashion website for buying clothes

  16. Example: bus stop kiosk • User characteristics • Context: Environment, types of users • Constraints: device, market, etc. • Functional requirements • Non-functional requirements

  17. How? • Gather data • Interviews, observation, surveys/questionnaires, documentation, immersion • Organize data • Notes, cards, brainstorming, computer tools • Represent data • Lists, outlines, matrices • Narratives • Hierarchies, Networks, Flow charts

  18. Summative assess an existing system judge if it meets some criteria Formative assess a system being designed gather input to inform design Summative or formative? Depends on maturity of system how evaluation results will be used Same technique can be used for either Formative vs. Summative evaluation

  19. (Not All) Requirements Gathering Methods Observation Thing out Loud & Cooperative Evaluation Interviews Questionnaires Focus groups Study Documentation Look at competitive products Ethnography Contextual Inquiry

  20. Study Documentation • Quick and easy if it exists • Often describe how things should be done rather than how they are done • Try to understand why not done “by the book” • Alternative: interview domain expert

  21. Look at Competitive Products • Looking for both good and bad ideas • Functionality • UI style • Possibly do user task performance metrics to establish bounds on your system

  22. Ethnography • Deeply contextual study • Immerse oneself in situation you want to learn about (has anthropological and sociological roots) • Observing people in their cultural context • Behavior is meaningful only in context • For UI designers: understand current methods, activities, environment, problems to aid design

  23. Ethnography • Things of interest to evaluator • Structure and language used in work • Individual and group actions • Culture affecting work • Explicit and implicit aspects of work • Example: Office work environment • Business practices, rooms, artifacts, work standards, relationships between workers, managers, …

  24. Drawbacks of Ethnographic Methods • Time required • Can take weeks or months for large systems • Scale • Most use small numbers of participants just to keep somewhat manageable • Type of results • Highly qualitative, may be difficult to present/use • Acquired skill – “learn by doing” • Identifying and extracting “interesting” things is challenging

  25. Contextual Inquiry • Practical ethnographic-inspired method for requirements • Master-apprentice relationship • Watch and talk to customer as they do their work • See: Beyer and Holtzblatt. Contextual Design. Morgan Kaufmann Publishers • How compares to other methods?

  26. Which Methods to Use? • Self-service filling and payment system for a gas station • On-board ship data analysis system for geologists searching for oil • Fashion website for buying clothes at large department store

  27. Making Sense • Organize/categorize information • “coding scheme” • Card Sorting • Affinity Diagrams • Task analysis

  28. Affinity Diagram - “Sorted Cards” From Interaction Design, Preece Rogers and Sharp

  29. Task Analysis • Focus on observable behaviors • What are the practices, methods, steps, objects, …, used? • Tasks & Subtasks • Physical • Cognitive • Communication • Conditions under which these tasks are done • Results/outcomes of tasks • Requirements to perform task • Information, artifacts • Communication with others • Equipment Also see: Hackos and Redish, User and Task Analysis for Interface Design. Wiley Publishing.

  30. Describing activities • Scenarios • Use Cases • Task - subtask decomposition • Includes sequencing information • Workflow diagrams • Flow charts • ER or object models

  31. Scenario • Describe tasks and context in sentences • Natural way of describing general idea • Good for demonstrating specific problems, reasons behind actions, atypical activities • Bad for representing branching, parallel activities, various possibilities of one activity

  32. Scenario: Example 1 • Its Friday afternoon and John just got paid. He wants to deposit his check immediately so he can pay his rent. He stops at one branch of his bank on the way home from work. He waits in his car while another person finishes using the ATM in front of the bank since it is drizzling outside. He walks up to the ATM to deposit his check. Only, as he is about to put the check into the envelope at the ATM, he realizes that he has not signed the back of it, and he has no pen and can not find one on or near the ATM machine. He cancels the transaction on the ATM, and enters the bank, which luckily is still open for 5 more minutes. He goes to the counter, finds a pen, and signs his check. He also fills out a deposit slip. He then waits to see a teller in person to deposit his check, and get money for the weekend.

  33. Scenario: Example 2 • Annie walks up to the ATM to deposit her weekly pay check. She puts her ATM card into the slot in the machine. She then enters her PIN number quickly, trying to block the person waiting behind her from viewing the keypad, and knows that she does not have to press “Enter” at this particular machine. She then chooses “Deposit” and “Check.” She enters the amount of the check using the keypad, then takes an envelope from the ATM machine, puts her check inside, seals the envelope and writes the amount of the check on the outside. She feeds the envelope into the slot into the ATM machine. She then selects “No other transactions” to finish, and waits to receive her receipt and ATM card.

  34. Example • Register for classes • What kinds of activities could we write a scenario about? • Let’s write one together

  35. Use Case • Description of a user’s goal in using a system • Focuses on user-system interaction • One path through a use case is sometimes called a scenario • Often presented as a series of steps • Diagram of actors and use cases

  36. Use Case Diagram

  37. Use Case example Arrange Meeting 1. The user chooses the option to arrange a meeting. 2. The system prompts user for the names of attendees. 3. The user types in a list of names. 4. The system checks that the list is valid. 5. The system prompts the user for meeting constraints. 6. The user types in meeting constraints. 7. The system searches the calendars for a date that satisfies the constraints. 8. The system displays a list of potential dates. 9. The user chooses one of the dates. 10. The system writes the meeting into the calendar. 11. The system emails all the meeting participants informing them of them appointment

  38. Hierarchical Task Analysis (HTA) • Graphical notation & decomposition of tasks • Goals – what the user wants to achieve • Tasks – do these to achieve the goals • Not necessarily computer related • Sequential dependencies • Multiple occurrences of tasks • Subtasks – lower-level tasks • Tasks organized into plans • Clusters of subtasks with a preferred order and prerequisite conditions

  39. Task Model - Borrow Book • Sequences added as annotations • Can also show hierarchy as indented text Goal Tasks to complete goal Subtasks to carry out one task From Interaction Design, Preece Rogers and Sharp

  40. HTA: Types of Plans • Fixed sequence • Optional tasks • Waiting events • Cycles • Time-sharing • Discretionary

  41. HTA

  42. Example • Goal: register for classes

  43. Flow Charts • Flow Chart of Task Steps • Complete, can become complex • Sequential flow, branching, parallel tasks. • Includes actions, decisions, logic, by all elements of the system • Mature, well-known, good tools for doing it

  44. Flow Chart Example Start Continue? Document Manual Operation Y Input N Display End

  45. Workflow • Documents going from one person/organization to another • Multiple participants in an activity

  46. Workflow Example - Document Flow Create Travel Request (Traveler) Ensure Funds Available (Accounting) Approval (Dean) Notification of Approval (Dean) No Funds Notification of Approval (Dean) Make Trip (Traveler) Complete Expense Report (Traveler) Approval (Accounting) Etc

  47. From Interaction Design, Preece Rogers and Sharp

  48. Entity Relationship Diagrams • Object Oriented Models • Objects/people with links to related objects • Stress relationship between objects and actions • Links described functionally and in terms of strength • About relations, not procedures • Complements HTA & flow charts

  49. Object Model: ATM • Objects • Account, ATM machine, ATM card, customer • Relations • Customer has one or more accounts • ATM machine accesses account • Actions on objects • Account: deposit($), withdraw($), balance • ATM machine: authenticate, dispense($), print receipt • Etc

  50. Your turn • Create a scenario describing a CURRENT bus stop activity that would help describe requirements information for a bus stop kiosk • Create an HTA of that same activity • Create ER diagram of entities involved in that activity • Is Workflow or Flow chart applicable?

More Related