Requirements and Affinity Diagrams IS 403 Fall 2013

Requirements and Affinity Diagrams IS 403 – Fall 2013 4

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

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

Requirements • “What to make” 4

Experience of requirements from other courses? 5

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

Types of requirements http: //usabilitygeek. com/requirementsgathering-user-experience-pt 1/ 7

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

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

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

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

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

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) 13

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 14

How to gather requirements? 15

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

Requirements • How to make them? – – • Functional requirements – – – – • Walkthrough/task analysis Competitor analysis 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 17

Gathering requirements 18

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 19

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

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

Requirements: Techniques After you have identified these sources, there 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

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 23

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

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=B 4 e. Oy. Bki 3 c. E • Debatable if this is technically an ethnography…

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

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.

32

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

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

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

36

Next time • Personas: who to make it for 37