人机交互技术 Week 11_Data gathering

Summary: Different Kinds of Requirements

• Functional requirements
• Data requirements
• Environmental requirements
  • Physical requirements
  • Social requirements
  • Organizational requirements
  • Technical requirements
• User requirements
• Usability requirements

Class activity

Suggest one key functional, data, environmental, user and usability requirement for each of the following scenarios:

• A system for use in a university's self-service cafeteria that allows users to pay for their food using a credit system
  • Functional: the system will calculate the total cost of purchases.
  • Data: The system must have access to their price of products.
  • Environmental: The physical environment will be noisy and bysy, and users may be talking with friends and colleagues while using the system.
  • User: The majority of users are likely to be under 25 and comfortable dealing with technology.
  • Usability: The system needs to be simple so that new users can use the system immediately, and memorable for more frequent users. Users won't want to wait around for the system to finish processing, so it needs to be efficient and to be able to deal easily with user errors.
• A system to control the functioning of a nuclear power plant
• A system to support distributed design teams, e.g. for car design
  • Functional: the system will be able to communicate information between remote sites.
  • Data: The system must have access to design information that will be captured in a common file format (such as AutoCAD).
  • Environmental: Physically distributed over a wide area. Files and other electronic media need to be shared.The system must comply with available communication protocols and be compatible with network technologies.
  • User: Professional designers, who may be worried about technology but who are likely to be prepared to spend time learning a system that will help them perform their jobs better. The design team is likely to be multi-lingual.
  • Usability: Keep transmission error rate low is likely to be of high priority.

Data gathering

• an important part of requirements activity and also of evolution
• Purpose: to collect sufficient, relevant, and appropriate data so that a set of stable requirements can be produced.
  • expand, clarify, and confirm the Initial requirements
• Needs to cover a wide spectrum of issues due to quite varied requirements
• Need to find out user tasks, goals, context...

Data gathering techniques

Essentially a small number of basic techniques for data gathering

• questionnaires
• interviews
• focus groups and workshops
• naturalistic observation
• studying documentation

Data gathering techniques are flexible and can be combined and extended in many ways.

(1) Questionnaires

• Can give quantitative or qualitative data
• Good for answering specific questions from a large, dispersed group of people
  • Infeasible to visit them all
• Often used in conjunction with other techniques
  • Information obtained through interviews might be corroborated (确证) by sending a questionnaire to a wider group of stakeholders to confirm the conclusions.

(2) Interviews

• Forum for talking to people
  • face-to-face vs telephone
• Structured, unstructured or semi-structured
  • how rigorously the interviewer sticks to a prepared set of questions
• Context
  • home setting
  • Props, prototypes, can be used In Interviews
• Good for exploring issues
  • more encouraging
• But are time consuming and may be infeasible to visit everyone

(3) focus groups and workshops

• Group interviews
• Structured or unstructured, facilitator
• Good at gaining a consensus view and/or highlighting areas of conflict and disagreement.
• On a social level it also helps for stakeholders to meet designers and each other, and to express their views in public.
  • The sessions need to be structured carefully and the participants need to be chosen carefully.
  • It is easy for one or a few people to dominate discussions.

(4) Naturalistic observation

• Why?
  • It can be very difficult for humans to explain what they do or to even describe accurately how they achieve a task.
• Observation provides a richer view.
• Spend time with stakeholders in their day-to-day tasks, observing work as it happens, in a natural setting.
• A member of the design team shadows a stakeholder, making notes, asking questions, and observing what is being done in the natural context of the activity.
• Gain insights into stakeholders' tasks

(5) Studying documentation

• Procedures and rules are often written down in manuals
• Other documentation: diaries or job logs that are written by the stakeholders during the course of their work
• 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

Choosing between techniques

• The kind of information your want will probably be determined by where you are in the cycle of iterations.
  • at the beginning of the project
    • interviews
• The resources available will influence the choice.
  • sending questionnaires nationwide
    • time, money, good design, pilot it, issue it, collate (比较) the results and analyze them.
  • has only 3 weeks? No one in the team has designed a survey before?
• The location and accessibility of the stakeholders need to be considered.
  • attractive to run a workshop
  • spread across a wide geographical area?

Choosing between data-gathering techniques rests on two issues:

1. The nature of the data gathering technique itself
2. The task to be studied

Data gathering techniques differ in two ways:

1. Amount of time, level of detail and risk associated with the findings
   • naturalistic observation: 2 days effort and 3 months of training
   • Interviews: 1 day effort and 1 month of training
2. Knowledge the analyst requires

Problems with data gathering

• Identifying and involving stakeholders: users, managers, developers, customer reps?, union reps?, shareholders?
• Involving stakeholders: workshops, interviews, workplace studies, co-opt(指派) stakeholders onto the development team
• ‘Real’ users, not managers: traditionally a problem in software engineering, but better now
• Requirements management: version control, ownership
• Communication between parties:
  • within development team
  • with customer/user
  • between users...different parts of an organisation use different terminology
• Domain knowledge distributed and implicit:
  • difficult to dig up and understand
  • knowledge articulation: how do you walk?
• Availability of key people
• Political problems within the organisation
• Dominance of certain stakeholders
• Economic and business environment changes
• Balancing functional and usability demands

Some basic guidelines

• Focus on identifying the stakeholders' needs
• Involve all the stakeholder groups
• Involve more than one representative from each stakeholder group
• Use a combination of data gathering techniques
• Support the process with props such as prototypes and task descriptions
• Run a pilot session
• You will need to compromise on the data you collect and the analysis to be done, but before you can make sensible compromises, you need to know what you'd really like
• Consider carefully how to record the data

Data interpretation and analysis

• Aim: to begin structuring and recording descriptions of requirements. Start soon after data gathering session
  • The experience will be fresh in the minds of the participants and this can help overcome any bias caused by the recording approach.
• A good idea is to discuss the findings with others to get a variety of perspectives on the data.
• Using a template highlights the kinds of information you should be looking for and guides the data interpretation and analysis.

Class Diagram

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.

Class Activity

For each of the situations below, consider what kinds of data gathering would be appropriate and how you might use the different techniques. Assume that you are at the beginning of the development and that you have sufficient time and resources.

• (a) You're developing a new software system to support a small accountant's office. There is a system running already with which the users are reasonably happy, but it is looking dated and needs upgrading.
• (b) You are looking to develop an innovative device for diabetes sufferers to help them record and monitor their blood sugar levels. There are some products already on the market, but they tend to be large and unwieldy(不实用的). Many diabetes sufferers rely on manual recording and monitoring methods involving a ritual with a needle, some chemicals, and a written scale.
• (c) You are developing a website for a young person's fashion e-commerce site.