How to carry out a CoU Analysis

CoU is best done during a meeting of project stakeholders. There should be one person in the meeting who has experience of CoU, and this person should be allowed to run the meeting. All the delegates to the meeting should have been circulated beforehand with briefing information about the process, such as these introductory notes, for instance. It is helpful if there is another person present who can type the information into the spreadsheet, leaving the leader free to manage the meeting. It is useful if the computer is attached to a data display device so that all can see what is on the screen; however, even with this aid, the meeting leader should take periodic pauses to summarise what has been agreed on.

The meeting should first of all, do an overview to scope the size of the task. How many different user types are there, what kinds of tasks do they carry out? Do they all interact with the computer in the same environment or does this vary? It is not necessary to get into detail at this point: if there are differences in emphasis they should be noted and left to the detailed part of the meeting to resolve. The list of users, tasks, and environments is the preliminary agenda for the meeting, which may be modified as time goes by.

Timing the meeting is important. Especially with a group not familiar with CoU, the first few users may take a while to describe; but familiarity in our experience soon sets in and the group begins to work to a rhythm. If too much time is being spent on a detail, it is best to note it as a potential problem and to move on, returning to the detail at the end if necessary. It is important not to rush the description of the environments at the end of the CoU.

If it is difficult or not suitable for a full project stakeholder meeting to take place, then CoU may be carried out by a smaller group of people, in conjunction when necessary with interviews of key persons such as user representatives, other technical staff, project managers and so on. In such a scenario it is useful to circulate the resulting CoU form among the stakeholders for comment and amplification if necessary afterwards.

The CoU will change as the product evolves. It is therefore important to keep the different CoU versions separately in order to establish an 'audit trail.' Organisations which have configuration control mechanisms in force should enter the CoU forms as configuration items and track them accordingly.

The current version of CoU

This is an introduction to an instantiation of CoU that has been evolved and tested in numerous industrial environments over a period of 10 years. It should be used in conjunction with an Excel spreadsheet on which the information appertaining to the CoU should be stored. The HFRG will provide the spreadsheet and guide as required. In the body of the introductory guide, the questions asked on the CoU spreadsheet are repeated, with an accompanying textual explanation of the question which goes beyond the notes provided on the spreadsheet itself.

In our implementation of the CoU, beside each question in the spreadsheet, there is a space for a textual answer and a number.

Not all questions will apply to any one project and there is considerable latitude in how the number information may be used. Always try to write down in the spreadsheet text part as much information relating to the CoU prompt as is available. Use the number space to assess the criticality of the information.

When using CoU for requirements capture some CoU information is much more important than other information, and at this stage, it is recommended that the number information be used to monitor the criticality of the design constraints emerging from the analysis of end user needs. Critical aspects of the context of use should be assigned smaller numbers, so that the most important constraints are the 'number one' entries. It is up to the development team to decide on what numbering scheme to use, but the following is suggested:

1. Critical requirement or feature, should not or cannot be changed, non-negotiable
2. Important, but may be traded against technical or organisational requirements if necessary
3. 'Dream machine' requirement or feature which indicates future scenario expectations
4. Requirement or feature which does not have to be strongly defended and may be circumvented in practice

When using CoU to derive a testing plan, it is clear that elements of the CoU which rated as 1 or 2 in the requirements stage need to be tested carefully, because they represent critical success factors for the project. At this latter stage it is useful to review the number information, change some of the numbers, and to use the number scale with the following anchors:

1. Must form part of testing scenario; project will not be tested properly otherwise,/li>
2. Should form part of testing scenario but may be over-ridden by practical considerations without loss of applicability of findings
3. Useful to have if can be included into testing scenario at low cost
4. Not to be tested or impractical to test.

Level 4 is particularly important if the generality of the evaluation findings is ever brought into question.

Items that are rated at level 1 must be present in some usability evaluations during project development: the earlier they are introduced the better.

he meeting should first of all, do an overview to scope the size of the task. How many different user types are there, what kinds of tasks do they carry out? Do they all interact with the computer in the same environment or does this vary? It is not necessary to get into detail at this point: if there are differences in emphasis they should be noted and left to the detailed part of the meeting to resolve. The list of users, tasks, and environments is the preliminary agenda for the meeting, which may be modified as time goes by.

Timing the meeting is important. Especially with a group not familiar with CoU, the first few users may take a while to describe; but familiarity in our experience soon sets in and the group begins to work to a rhythm. If too much time is being spent on a detail, it is best to note it as a potential problem and to move on, returning to the detail at the end if necessary. It is important not to rush the description of the environments at the end of the CoU.

If it is difficult or not suitable for a full project stakeholder meeting to take place, then CoU may be carried out by a smaller group of people, in conjunction when necessary with interviews of key persons such as user representatives, other technical staff, project managers and so on. In such a scenario it is useful to circulate the resulting CoU form among the stakeholders for comment and amplification if necessary afterwards.

The CoU will change as the product evolves. It is therefore important to keep the different CoU versions separately in order to establish an 'audit trail.' Organisations which have configuration control mechanisms in force should enter the CoU forms as configuration items and track them accordingly.