Data gathering and requirements


This module covers week 9 of the course.

Data gathering

Five issues in data gathering

Data recording: Notes, audio, video, and photographs all useful.

Interviews

Different ways of conducting interviews:

Questionnaires

Questionnaire structure

Format

Consider which formats - such as ranges or check boxes are appropriate for the type of data you want to collect.

Likert scales (an example here from N/N group) are a useful way of measuring opinions, beliefs, attitudes, and so on.

Participants

As a student, you aren’t expected to conduct a survey of hundreds of participants! In interaction design research, it isn’t unusual to have fewer than 20 participants.

Online questionnaires are relatively easy and quick to distribute—common to use Google Forms or Microsoft Forms.

Observation

Can occur directly (for example, as an ethnographic study, where the researcher interacts with participants), or indirectly (through the use of diaries, video equipment, online tracking/logging, etc.). Ethnography can now occur online (See “Netnography”).

Data

There are also mixed methods that rely on both quantitative and qualitative data and analyses.

Data analysis tools

The System Usability Scale (SUS)

Though created by John Brooke in 1986, the SUS is still used frequently because it's a "quick and dirty" way of measuring usability. It's used to measure usability of all kinds of software and hardware systems and applications.

usability.gov (n.d.). System Usability Scale (SUS). https://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html

The original System Usability Scale (SUS):

  1. I think that I would like to use this system frequently.
  2. I found the system unnecessarily complex.
  3. I thought the system was easy to use.
  4. I think that I would need the support of a technical person to be able to use this system.
  5. I found the various functions in this system were well integrated.
  6. I thought there was too much inconsistency in this system.
  7. I would imagine that most people would learn to use this system very quickly.
  8. I found the system very cumbersome to use.
  9. I felt very confident using the system.
  10. I needed to learn a lot of things before I could get going with this system (Brooke, 1986).

What is a requirement?

"A statement about an intended product that specifies what it is expected to do or how it will perform" (Sharp et al. 2019, p. 387).

User stories are a useful way of creating requirements. Often stated as:
“As a <role>, I want <behaviour> so that <benefit>” (Sharp et al., 2019, p. 388)

Different kinds of requirements

Requirements

Requirements can be presented in a number of ways, such as the requirements shell in the reading.

See also this simple software requirement document template from Asana (2023):

  1. Introduction
    Who is this document intended for and why?
    How will it be used?
  2. Product scope
    What are the overall business goals of your product?
  3. Product value
    Why is your product important?
    How will it help your intended audience?
  4. Intended audience
    Who is your product for?
  5. Intended use
    What will this product be used for?
  6. General description
    Give a summary of the functions the software would perform and the features to be included.

Further reading: Team Asana (2023). How to write a software requirement document (with template). https://asana.com/resources/software-requirement-document-template

Data gathering for requirements

Bringing requirements to life through personas and scenarios

Personas: Rich descriptions of typical users, not specific people

Scenarios: An informal narrative story, simple, ‘natural’, personal, and not generalizable (Sharp et al., 2019).

Example personas: Users of a bushfire information map application in rural Western Australia.

example personas from a fire mapping project

Illustration by Medley (2013). Note that the following details were elaborated for each in the research project they were used in:

Several more example personas at Smashing Magazine.

Use cases focus on functional requirements and interactive elements. See these example use cases.

  


Back to top | © Paul Haimes at Ritsumeikan University | View template on Github