Presentation is loading. Please wait.

Presentation is loading. Please wait.

Requirements and Affinity Diagrams IS 403 – Fall 2013 4.

Similar presentations


Presentation on theme: "Requirements and Affinity Diagrams IS 403 – Fall 2013 4."— Presentation transcript:

1 Requirements and Affinity Diagrams IS 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) 2

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

4 Requirements “What to make” 4

5 Experience of requirements from other courses? 5

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

7 Types of requirements 7 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) 8

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

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

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

12 Debug this requirement “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]” 12 Concise Specific Unambiguous Easy to measure Tied to data Numbered

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

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 14

15 How to gather requirements? 15

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

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 17

18 Gathering requirements 18

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 19

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

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 23

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 25

26 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

27 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 http://www.youtube.com/watch?v=B4eOyBki3cE Debatable if this is technically an ethnography…

28 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

29 Analyzing data 29

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

31 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 32

33 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 33

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

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

36 36

37 Next time Personas: who to make it for 37


Download ppt "Requirements and Affinity Diagrams IS 403 – Fall 2013 4."

Similar presentations


Ads by Google