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

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

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.

Functional and non-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

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.

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

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

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.

The requirements elicitation and analysis process

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.

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

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

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.

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

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

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)

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

Example Persona

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

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

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

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

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

Some examples Cultural probes

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

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

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

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

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

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

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….

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 collected remotely by drones or other equipment

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

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

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 

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?"

Contextual Inquiry

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.

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

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

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)

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