人机交互技术 Week 11

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:

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

Data gathering techniques differ in two ways:

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