1 / 37

Admin

Requirements and Affinity Diagrams IS 403 – Fall 2013 4. Admin. Assignment 1 due Thursday at 2:30:00pm And A0 must have been submitted Questions? Added a paper prototyping lecture (next Thursday).

sybil
Download Presentation

Admin

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 Affinity DiagramsIS 403 – Fall 2013 4

  2. Admin • Assignment 1 due Thursday at 2:30:00pm • And A0 must have been submitted • Questions? • Added a paper prototyping lecture (next Thursday)

  3. Today • Tools for planning our design • Requirements gathering/brainstorming • Personas

  4. Requirements “What to make”

  5. Experience of requirements from other courses?

  6. What requirements tell us • What features a system should have (functional requirements) • What qualities the system should have (non-functional requirements) • Examples?

  7. Types of requirements http://usabilitygeek.com/requirements-gathering-user-experience-pt1/

  8. Functional vs. non-functional • Functional • Features • What the system does • Non-functional • Qualities (performance, reliability, security, safety, scalability)

  9. Good requirements Concise Specific Unambiguous Easy to measure Tied to data Numbered

  10. Debug this requirement “The main web site page will load quickly”

  11. Debug this requirement • Concise • Specific • Unambiguous • Easy to measure • Tied to data • Numbered “The main web site page will load quickly” “R1. The home page will load (completely, vs. some content) in N seconds”

  12. Debug this requirement • Concise • Specific • Unambiguous • Easy to measure • Tied to data • Numbered “The main web site page will load quickly” “R1. On a broadband connection, the main web site will load within 5 seconds [see interview data XX]”

  13. Remember users vs. stakeholders • Requirements don’t just affect users • Other stakeholders • Business sponsors • “Secondary users” – provide input/output to the system, but don’t actually interact with it • “Tertiary users” – not primary or secondary user, but affected by system • Facilitating users – who else might interact with the system? (designers, maintenance)

  14. Stakeholders • We are designing a new electronic lock for UMBC dorms • Who are our users/stakeholders? • Primary: Students • Secondary: maintenance, RAs/res life • Tertiary: Visitors, emergency personnel, campus police, university admin, parents • Facilitating: developers, designers

  15. How to gather requirements?

  16. Mini-activity: requirements Let’s brainstorm requirements for a web app: UMBC course schedule Functional (features) Non-functional (attributes) 4 minutes

  17. Requirements • How to make them? • Walkthrough/task analysis • Competitor analysis • Functional requirements • Printing, sharing the schedule (by email) • Any user (student or faculty) must be able to log in with the appropriate credentials • Share sign on from other UMBC sites • Add • Drop • Waitlist • Switch between semesters • Multiple use • History past semesters • Calendar view • Interactive map: help students find classes • Reminder/alert • Show view with class, instructor, room, time (table view) • Non-functional requirements • Supports encrypted connections • Cross-platform compatibility (phone, laptop. Compatibility) • Web browser compatibility • Personal information must be stored securely

  18. Gathering requirements

  19. How to gather requirements? • Competitive analysis (view other web sites in category) • User research • But we need to ask the right questions • Once we have data • Brainstorming and affinity diagramming

  20. Working with users Which users to pick? What techniques to generate ideas?

  21. Requirements: Sources Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one that takes few resources. • Customers • Users • Administrators and maintenance staff • Partners • Domain Experts • Industry Analysts • Information about competitors 

  22. Requirements: Techniques After you have identified these sources, there are a number of techniques that may be used to gather requirements. • Conduct a brainstorming session • Interview users • Send questionnaires • Work in the target environment • Study analogous systems • Examine suggestions and problem reports • Talk to support teams • Study improvements made by users • Look at unintended uses • Conduct workshops • Demonstrate prototypes to stakeholders

  23. Interviews/questionnaires • Can take many forms (1:1, focus groups, web surveys) • How to ask the right questions? • Can’t ask “what are your requirements for web site?” • Start with what people like, dislike with current experiences. “pain points” • What do you do with this system? • What works well? • What doesn’t? • Analyze responses

  24. Participatory Design • Stakeholders participate in the design process: “design in the workplace” • Users are active collaborators in the design process • Common activities: • Focus groups, interviews • Brainstorming • Product evaluations and critiques • Storyboarding • Useful when you want to design something not in your field, or something entirely new

  25. Ethnography • Studying actual habits and practices of stakeholders in context • Leave the lab and go find out what is really happening • BECOME part of the community, a “participant observer” • Ethnographer must create detailed records of observations • Notes, discrete video or audio recording • Roots in anthropology and sociology

  26. Extreme Ethnography: Patricia Moore At age 26, she transformed herself into a range of women over the age of 80. Disguises involved more than makeup and clothing: She altered her body with prosthetics that blurred her vision, reduced her ability to hear and limited her motion. She used canes, walkers and a wheelchair. From 1979 to 1982, she was in the roles about every third day for as much as 20 hours at a time. The experiment took her to 116 cities in 14 states and two Canadian provinces. Video: http://www.youtube.com/watch?v=B4eOyBki3cE Debatable if this is technically an ethnography…

  27. Contextual Inquiry • Another technique to study users in context • Much more focused than ethnography • Investigator works with stakeholders to learn about their work, in stakeholder environment • Investigator interviews stakeholder and frequently uses “think aloud technique” • Investigator creates detailed recordings to understand stakeholder’s habits and actions

  28. Analyzing data

  29. Analyzing data • We have feedback from users • How to make sense of it? • Big challenges • Identifying common themes • Sorting and classifying

  30. Affinity diagramming • Clustering related concepts from data • write each element on a card • group or arranging cards • rank objects/actions for task relevance • spot patterns • This is an iterative process: you will find questions and need to revisit your data, or collect more.

  31. Activity Part 0: Feedback Let’s critique myUMBC Pair up with 1 other student Look at homepage Identify positives and negatives Write them on cards 4 minutes

  32. Activity Part 1: Affinity diagrams Split into 2 groups Put comments on wall Organize themes 5 minutes

  33. Activity Part 1: Requirements Come up with requirements Functional and non-functional 5 minutes

  34. Next time Personas: who to make it for

More Related