1. AVI/Psych 358/IE 340: Human Factors Data Gathering October 1, 2008

2. 2 Overview The importance of requirements Different types of requirements Data gathering for requirements

3. 3 What, how and why? (1/3) Requirements gathering: What Two aims: 1. Understand as much as possible about users, task, context 2. Produce a stable set of requirements

4. 4 What, how and why? (2/3) How: Data gathering activities Data analysis activities Expression as ‘requirements’ All of this is iterative

5. 5 What, how and why? (3/3) Why: the stage where failure occurs most commonly

6. 6 Establishing requirements What do users want? What do users ‘need’? Requirements need clarification, refinement, completion, re-scoping Input: requirements document (maybe) Output: stable requirements

7. 7 Why “establish”? Requirements arise from understanding users’ needs Requirements can be justified & related to data

8. 8 Different kinds of requirements (1/4) Functional: —What the system should do —Historically the main focus of requirements activities

9. 9 Example Interactive product for self-service cafeteria that allows users to pay for their food using their student ID card Functional requirement: The product/interface will “calculate the total cost of purchases” Interactive product to support virtual teams, e.g,. For car design Functional requirement: The product will be able to “communicate information between remote sites”

10. 10 Different kinds of requirements (2/4) Non-functional: memory size, response time Data: —What kinds of data need to be stored? —How will they be stored (e.g. database)?

11. 11 Example Interactive product for self-service cafeteria that allows users to pay for their food using their student ID card Data: The product must have “access to the price of products in the cafeteria” Interactive product to support virtual teams, e.g,. For car design Data: The product must have “access to design information that will be captured in a common file format (e.g., AutoCAD)”

12. 12 Different kinds of requirements (3/4) Environment or context of use: — physical: dusty? noisy? vibration? light? heat? humidity? — social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients — organizational: hierarchy, IT department’s attitude and remit, user support, communications structure and infrastructure, availability of training

13. 13 Example Interactive product for self-service cafeteria that allows users to pay for their food using their student ID card Environment: Students will be in a rush, noise and busy, and may be talking with friends while using the product Interactive product to support virtual teams, e.g,. For car design Environment: Files will be distributed and would need to be shared, network compatibility

14. 14 Different kinds of requirements (4/4) Users: Who are they? — Characteristics: ability, background, attitude to computers — System use: novice, expert, casual, frequent — Novice: step-by-step (prompted), constrained, clear information — Expert: flexibility, access/power — Frequent: short cuts — Casual/infrequent: clear instructions, e.g., menu paths

15. 15 Example Interactive product for self-service cafeteria that allows users to pay for their food using their student ID card Users: Majority of users are likely to be under 25 and comfortable dealing with technology Interactive product to support virtual teams, e.g,. For car design Users: Professional designers who may be worried about technology but are likely to spend time learning a system to help them perform their job better

16. 16 In-class activity Functional requirements: What the system should do New system Enhancements to existing system Brainstorm at least three functional requirements for an interactive product/interface to control the functioning of a nuclear power plant! (Write these down) (EXAMPLE FROM BEFORE) Interactive product for self-service cafeteria that allows users to pay for their food using their student ID card Functional requirement: The product will “calculate the total cost of purchases” Interactive product to support virtual teams, e.g,. For car design Functional requirement: The product will be able to “communicate information between remote sites”

17. 17 Functional requirements for a nuclear power plant The product will be able to “monitor the temperature of the reactors” The product will be able to “detect nuclear breakdowns (e.g., spills) and appropriate remedial action” The product will be able to “inform workers of optimal evacuation procedures”

18. 18 Next Class Data gathering for requirements