Gathering User Requirements

1
CS2341

• Lecture 4
• Gathering User Requirements
• Robert Stevens

2
Introduction

• Making models of users
• Gathering initial information
• Questionnaires
• The UML process
• Interviews

3
Gathering Requirements

• Talking to users and thinking hard
• We need consistency, replication and recording
• Use a methodology
• Various kinds of technique
• Soft System Methodology
• Socio-technical models
• Participatory design
• UMLs own flavour

4
Basics of Requirements Gathering

• Talk to users and ask what they do and how they
  do it
• A difficult task
• Questionnaires
• Interviews
• When systems already exist
• When systems do not exist at all
• Situated cognition

5
Business Process

• Business processes are graphs of activities that
  carry out some meaningful business operation.
• Purchasing an airline ticket, managing inventory
  in a warehouse, and ordering furniture for a home
  or office
• You will model business processes
• How human and artefacts use and are used in a
  business process

6
Questionnaires

• Used for remote users
• Paper or electronic forms
• Easy to administer
• Poor quality, superficial information
• Good for overviews
• Good for simple quantitative information Kinds
  of drinks consumed

7
Questionnaires (2)

• Internal questions What you wish to answer
• Questionnaire questions What the user sees
• One Internal may map to many questionnaire
  questions
• Funnelling From the general to the specific
• Logical order No forward references or
  dependencies
• Break into topic sections

8
Going to the Pub

• Internal Question Making a plan to go to the
  pub
• Questionnaire Questions
• Who do you go to the pub with?
• Is it always the same people?
• Which pubs do you visit?
• Do you stay at one pub?
• At what tiime do you usually go to the pub?
• At what time do you usually return from the
  pub?

9
Question Types

• Multiple-choice
• limited response
• free response
• With whom do you go to the pub?
• By yourself
• With Friends
• Work colleagues
• Family
• Other

10
Questionnaire Tips

• Tick boxes and multi-choice are well answered
• Free response questions rarely answered
• Time is precious 30 minutes maximum
• Facts easier to gather than behaviour
• Time perception and memory are faulty
• Readability is important
• Make instructions clear tick, cross, underline,
  choose one, many, at least one, etc.

11
Question Wording

• Avoid two questions in one Do you buy food and
  drink at the bar y/n
• Avoid the word not Does the article not have
  an adequate abstract and introduction? Y/N
• Why questions are difficult to answer offer
  concrete examples Tick any of the following
  reasons you may use to visit the pub
• Use statements I go to the pub to meet friends
  Strong agree neither agree or disagree disagree
• No leading questions Do you want Soviet style
  womens equality laws?

12
Limitations of Questionnaires

• Difficult to interpret
• Cannot follow digressions
• Ensuring correct respondant interpretation
• Quantitative, numeric responses means narrow
  questions
• Qualitative, free responses give more
  information, but are difficult to analyse

13
Uses of Questionnaires

• Can quickly cover a large number of users
• Useful for gathering basic information
• Need to follow up with single user interviews
• Can sketch out basic models

14
The UML Process

• Participatory design the users are involved
• Iterative Segments are re-visited
• User knowledge captured in a series of models and
  transformed to give an application design
• Models shown to users for testing and modification

15
Users and Activities

• Users take part in Activities Going for a drink
• Activities involve objects People, pub, chairs,
  table, beer, coca-cola
• An objects behaviour is invoked to take part in
  an activity if (person.hasMoney()) then
  person.buyDrink()

16
UML Modelling Diagrams

• Activity diagrams
• Class diagrams
• Use cases
• Sequence diagrams
• Employment diagrams
• These and others all capture (model) some aspect
  of task and/or system

17
The plan

• Initial interview to gain overview
• Should know main actors Customers, bar staff,
  Landlord/lady, brewery rep,
• Organise in depth interviews with different
  actors
• Find what activities they perform and how they
  are performed
• Will take many sessions over extended time
  client must commit

18
The Bartender

• As a bartender, I do many jobs the main one
  being serving customers. This can be any number
  of any type of drink. I also, check stock,
  collect glasses, wash glasses and eject
  drunkards.

19
The Personnel

• The user
• Note takers
• Modellers
• Facilitator
• Remember ethics!
• Plenty of pencils and paper come with diagrams
  prepared from initial interviews adapt as you go

20
Using Interviews

• Create Models and show to usersThis is
  participatory design
• Responses will promt more interview questions
• Iterative design and model refinement
• You mentioned dealing with a large number of
  drinks
• yes, if theyre all the same its easy, but if
  theyre different, I KEEP FORGETTING

21
Structured Interviews

• Same general rules as questionnaires
• Performed face to face
• Digressions allowed, but controlled
• A set of questions based on initial interview
• Use users terminology
• Tailor questions to types of user

22
Bar Staff Interview

• Describe, in general terms, your job
• How many bar staff are there?
• Do you work together or separately?
• Do you share responsibilities?
• Which other employees do you interact with?
• How often do you colect glasses? How do you
  decide when to do this?
• How many customers can you serve?
• When do you refuse to serve?

23
General Tips

• Use a plan
• You are not testing the users they are helping
  you
• One hour repeat rather than tire
• The users are helping
• Do not interrogate users
• Allow interesting diversions, but guide to the
  plan
• Model as you go Concrete is good

24
Summary

• Gathering user requirements is important
• It is the input phase to your engineering task
• There are many kinds of user, ncluding other
  systems
• Plan your interaction and do it iteratively
• Talking to users is difficult