Establishing Requirements

1. Establishing Requirements Dr. Sampath Jayarathna Old Dominion University Credit for some of the slides in this lecture goes to www.id-book.com

2. HW2 • Is posted on the class website • Practice the Contextual Enquiry method we will learn today • Due Feb. 08 (Friday) • Start soon!

3. Agile methods and requirements • Many agile methods argue that producing detailed system requirements is a waste of time as requirements change so quickly. • The requirements document is therefore always out of date. • Agile methods usually use incremental requirements engineering and may express requirements as ‘user stories’. • This is practical for business systems but problematic for systems that require pre-delivery analysis (e.g. critical systems) or systems developed by several teams.

4. Functional and non-functional requirements • Functional requirements • Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. • May state what the system should not do. • Non-functional requirements • Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. • Often apply to the system as a whole rather than individual features or services. • Domain requirements • Constraints on the system from the domain of operation

5. functional Vs non-functional requirements • An example of a functional requirement would be: • A system must send an email whenever a certain condition is met (e.g. an order is placed, a customer signs up, etc). • A related non-functional requirement for the system may be: • Emails should be sent with a latency of no greater than 12 hours from such an activity. • The functional requirement is describing the behavior of the system as it relates to the system's functionality. The non-functional requirement elaborates a performance characteristic of the system.

6. System stakeholders • Any person or organization who is affected by the system in some way and so who has a legitimate interest • Stakeholder types • End users • System managers • System owners • External stakeholders

7. Activity 5: Case Study : Stakeholders Suppose that you have to develop software for cash dispenser. You should develop software for both cash dispenser, i.e. the part for communication with the customers (delivering money and report the account state), the software for communication and software needed in banks for communicate with the bank transaction systems. You have a team of 10 people – all of them can play a role of designers, developers, testers and document writers. You have got a contract to implement the first version in 6 months. All hardware and development tools are available. In the project 5 banks are included that use 2 different transaction systems. The customer wants that you incrementally implement the system – first the cash dispenser software, then the interface to the bank account system, finally the communication. The total system should be delivered after 6 months. Identify the Stakeholders of this system

8. Problems of requirements elicitation • Stakeholders don’t know what they really want. • Stakeholders express requirements in their own terms. • Different stakeholders may have conflicting requirements. • Organisational and political factors may influence the system requirements. • The requirements change during the analysis process. New stakeholders may emerge and the business environment may change.

9. Therequirements elicitation and analysis process

10. Process activities • Requirements discovery • Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. • Requirements classification and organisation • Groups related requirements and organises them into coherent clusters. • Prioritisation and negotiation • Prioritising requirements and resolving requirements conflicts. • Requirements specification • Requirements are documented and input into the next round of the spiral.

11. Requirement Gathering • The importance of requirements • Data gathering for requirements • Data analysis and presentation • Task description:Scenarios Use Cases Essential use cases • Task analysis: HTA

12. What, how and why? • Why bother? • Requirements definition is the stage where failure occurs most commonly Getting requirements right is crucial 12

13. User, Subject, or Participant? • "User" and "Subject" connote a more passive role. • One perspective: “subjects” are “subjected to” experiments as a designer develops understanding • Another: "Participant" instead "participate" in helping the designer develop understanding • "Participant" is more common term in HCI – but also it's a mindset that matters.

14. Establishing requirements • What do users want? What do users ‘need’? • Requirements need clarification, refinement, completion, re-scoping • Input: Requirements document (maybe) • Output: stable requirements • Why ‘establish’? • Requirements arise from understanding users’ needs • Requirements can be justified & related to data

15. Different kinds of requirements • Users: Who are they? • Characteristics: nationality, educational background, attitude to computers • System use: novice, expert, casual, frequent • Novice: prompted, constrained, clear • Expert: flexibility, access/power • Frequent: short cuts • Casual/infrequent: clear menu paths

16. What are the users’ capabilities? • Humans vary in many dimensions: • size of hands may affect the size and positioning of input buttons • motor abilities may affect the suitability of certain input and output devices • height if designing a physical kiosk • strength - a child’s toy requires little strength to operate, but greater strength to change batteries • disabilities (e.g. sight, hearing, dexterity)

17. Personas • Capture a set of user characteristics (user profile) • Not real people, but synthesised from real users • Bring them to life with a name, characteristics, goals, personal background • Develop a small set of personas with one primary

18. Example Persona

19. Activity 6 • Lets build Persona’s for our Startup • Find a partner • Pick a certain demographic and design a Persona using https://app.xtensio.com/ User Persona Template • Male or Female • <18, 18-34, 35-50, 50+ • Submit a Screen Capture of your Persona to Piazza

20. Data gathering for requirements • Interviews: • Props, e.g. sample scenarios of use, prototypes, can be used in interviews • Good for exploring issues • Development team members can connect with stakeholders • Focus groups: • Group interviews • Good at gaining a consensus view and/or highlighting areas of conflict • But can be dominated by individuals

21. Data gathering for requirements • Questionnaires: • Often used in conjunction with other techniques • Can give quantitative or qualitative data • Good for answering specific questions from a large, dispersed group of people • Researching similar products: • Good for prompting requirements

22. Data gathering for requirements • Direct observation: • Gain insights into stakeholders’ tasks • Good for understanding the nature and context of the tasks • But, it requires time and commitment from a member of the design team, and it can result in a huge amount of data • Indirect observation: • Not often used in requirements activity • Good for logging current tasks

23. Data gathering for requirements • Studying documentation: • Procedures and rules are often written down in manuals • Good source of data about the steps involved in an activity, and any regulations governing a task • Not to be used in isolation • Good for understanding legislation, and getting background information • No stakeholder time, which is a limiting factor on the other techniques

24. Some examples Cultural probes

25. Interviews • Unstructured - are not directed by a script. Rich but not replicable. • Structured - are tightly scripted, often like a questionnaire. Replicable but may lack richness. • Semi-structured - guided by a script but interesting issues can be explored in more depth. Can provide a good balance between richness and replicability. • Focus groups – a group interview

26. Interview questions • Two types: • ‘closed questions’ have a predetermined answer format, e.g.. ‘yes’ or ‘no’ • ‘open questions’ do not have a predetermined format • Closed questions are easier to analyze • Avoid: • Long questions • Compound sentences - split them into two • Jargon and language that the interviewee may not understand • Leading questions that make assumptions • e.g.. why do you like …? • Unconscious biases e.g.. gender stereotypes

27. Enriching the interview process • Props - devices for prompting interviewee, e.g. use a prototype, scenario

28. Questionnaires • Questions can be closed or open • Closed questions are easier to analyze, and may be distributed and analyzed by computer • Can be administered to large populations • Disseminated by paper, email and the web • Sampling can be a problem when the size of a population is unknown as is common online evaluation

29. Sequencing your questions • Group questions that are similar • Put them in logical order • Place demographic questions at the beginning • Put any sensitive or difficult questions at the end • Put any open-ended questions at the end

30. Sequencing your questions • Group questions that are similar • Put them in logical order • Place demographic questions at the beginning • Put any sensitive or difficult questions at the end • Put any open-ended questions at the end

31. Question and response format • ‘Yes’ and ‘No’ checkboxes • Checkboxes that offer many options (checklist) • Rating scales • Likert scales • Strongly disagree (1), disagree(2), undecided (3), agree(4), strongly agree (5) • semantic scales (fair…..biased), (weak….strong) • 3, 5, 7 or more points • Open-ended responses • Overlapping Response Categories, 1-25, 25-55….

32. Observation • Direct observation in the field • Structuring frameworks • Degree of participation (insider or outsider) • Ethnography • Direct observation in controlled environments • Indirect observation: tracking users’ activities • Diaries • Interaction logging • Video and photographs collectedremotely by drones or other equipment

33. Ethnography • Ethnography is a philosophy with a set of techniques that include participant observation and interviews • Ethnographers immerse themselves in the culture that they study • A researcher’s degree of participation can vary along a scale from ‘outside’ to ‘inside’ • Analyzing video and data logs can be time-consuming • Collections of comments, incidents, and artifacts are made

34. Contextual Inquiry • A design oriented approach to ethnographic study for finding out what users currently do and problems they encounter • A form of interview, but • at users’ workplace (workstation) • 2 to 3 hours long • Four main principles: • Context: see workplace & what happens • Partnership: user and developer collaborate • Interpretation: observations interpreted by user and developer together • Focus: project focus to understand what to look for

35. Contextual Inquiry: Relationship? • The "master/apprentice" relationship is at the heart of contextual inquiry • In master/apprentice relationship: • Master is doing stuff • The master explains what they're doing • The apprentice asks clarification questions • The master answers Obviously, the participant is the master and you are the apprentice 

36. Contextual Inquiry: Relationship? • It is not quite the "master/apprentice" relationship • The goal is not to learn to do the task • Instead, the goal is to learn how the participant does the task in order to learn how to support it • And for the researcher to enlist the participants active assistance understanding the task • Ask participant to think aloud • People summarize, but we want specific details. Keep it concrete when people start to abstract • "Do you have one?, May I see it?"

37. Contextual Inquiry

38. Contextual Inquiry: Relationship? • Keep it as a partnership • Interviewer / Interviewee • You aren't there to get a list of questions answered • Expert / Novice • You aren't there to answer questions • Guest/ Host • Move closer, ask questions, be nosy, fill in holes.

39. Contextual Inquiry: How to Mess it Up • Be sure to explain the rules of how you'll be interacting • If you could have done it in a coffee shop, then you didn't do a contextual inquiry • Slipping into abstraction • Keep it concrete, in the work, in the detail • Not being inquisitive or nosy enough • If you have the impulse to ask, do it right away • Overly disrupting the task • Don't ask too many questions that participants stop doing their tasks

40. Data recording • Notes, audio, video, photographs can be used individually or in combination: • Notes plus photographs • Audio plus photographs • Video • Different challenges and advantages with each combination • Take notes • Write down observations, answers to questions, weird or strange findings • Collect data as you do the contextual enquiry • Plan a focus and some questions so you don't lose your way

41. Online Ethnography • Virtual, Online, Netnography • Online and offline activity • Interaction online differs from face-to-face • Virtual worlds have a persistence that physical worlds do not have due to regular archiving • Ethical considerations and presentation of results are different • Signing informed consent. • Quotes from participants available even anonymized (easily tracked and attributed to a person)

42. Observation in a controlled environment • Direct observation • Think aloud techniques • Indirect observation – tracking users’ activities • Diaries • Interaction logs • Web analytics • Video, audio, photos, notes are used to capture data in both types of observations