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

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
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 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:
s 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. The requirements 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? Getting requirements right is crucial 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 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, 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 collected remotely 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