Identifying needs and establishing requirements

10.1 Introduction

10.2 What, How, and Why?

10.3 What are requirements?

10.4 Data gathering for requirements

10.5 Data analysis, interpretation, and presentation

10.6 Task description

10.7 Task analysis

10.1 Introduction

An interaction design project may aim to replace or update an established system, or it may aim to develop a totally innovative product with no obvious precedent. There may be an initial set of requirements, or the project may have to begin by producing a set of requirements from scratch. Whatever the initial situation and whatever the aim of the project, the users' needs, requirements, aspirations, and expectations have to be discussed, refined, clarified, and probably re-scoped. This requires an understanding of, among other things, the users and their capabilities, their current tasks and goals, the conditions under which the product will be used, and constraints on the product's performance.

As we discussed in Chapter 9, identifying users' needs is not as straightforward as it sounds. Establishing requirements is also not simply writing a wish list of features. Given the iterative nature of interaction design, isolating requirements activities from design activities and from evaluation activities is a little artificial, since in practice they are all intertwined: some design will take place while requirements are being established, and the design will evolve through a series of evaluation–redesign cycles. However, each of these activities can be distinguished by its own emphasis and its own techniques.

This chapter provides a more detailed overview of identifying needs and establishing requirements. We introduce different kinds of requirements and explain some useful techniques.

The main aims of this chapter are to:

• Describe different kinds of requirements.
• Enable you to identify examples of different kinds of requirements from a simple description.
• Explain how different data gathering techniques (those introduced in Chapter 7 and others) may be used during the requirements activity.
• Enable you to develop a ‘scenario,’ a ‘use case,’ and an ‘essential use case’ from a simple description.
• Enable you to perform hierarchical task analysis on a simple description.

10.2 What, How, and Why?

10.2.1 What are we Trying to Achieve in the Requirements Activity?

There are two aims. One aim is to understand as much as possible about the users, their work, and the context of that work, so the system under development can support them in achieving their goals; this we call “identifying needs.” Building on this, our second aim is to produce, from the needs identified, a set of stable requirements that form a sound basis to move forward into thinking about design. This is not necessarily a major document nor a set of rigid prescriptions, but you need to be sure that it will not change radically in the time it takes to do some design and get feedback on the ideas. Because the end goal is to produce this set of requirements, we shall sometimes refer to this as the requirements activity.

10.2.2 How can we Achieve This?

This whole chapter is devoted to explaining how to achieve these aims, but first we give an overview of where we're heading.

At the beginning of the requirements activity, we know that we have a lot to find out and to clarify. At the end of the activity we will have a set of stable requirements that can be moved forward into the design activity. In the middle, there are activities concerned with data gathering, analysis, interpretation, and presentation, with the aim of capturing the findings in a form that can be expressed as requirements. Broadly speaking, these activities progress in a sequential manner: first gather some data, then analyze and interpret it, then extract some requirements from it, but it gets a lot messier than this, and the activities influence one another as the process iterates. One of the reasons for this is that once you start to analyze data, you will find that you need to gather some more data to clarify or confirm your findings. Another reason is that the way in which you present your requirements may affect your analysis, since it will enable you to identify and express some aspects more easily than others (as discussed in Section 8.7). For example, using a notation which emphasizes the data characteristics of a situation will lead the analysis to focus on this aspect rather than, for example, on task structure. Remember from Chapter 7 that it is valuable to triangulate data gathering and analysis and to use a complementary set of techniques. As we discuss below, there are different kinds of requirements, and each can be emphasized or de-emphasized by the different techniques.

Identifying needs and establishing requirements is itself an iterative activity in which the subactivities inform and refine one another. It does not last for a set number of weeks or months and then finish. In practice, requirements evolve and develop as the stakeholders interact with designs and see what is possible and how certain facilities can help them. And as shown in the lifecycle model in Chapter 9, the activity itself will be repeatedly revisited.

10.2.3 Why bother? The importance of getting it right

Much has been written about the significant cost of fixing errors late in the software development cycle rather than early, during the requirements activity. For example, Davis (1995) identifies insufficient user communication, poor specifications, and insufficient analysis as contributors to poor cost estimation. Boehm and Basili (2001) present a top ten list of software defect reduction findings, the first of which states that “finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.” Taylor (2000) investigated the causes of IT project failure. The article admits that “there is no single cause of IT project failure,” but requirements issues figured highly in the findings. Others too have identified requirements errors as being a major source of severe problems, e.g. Jones (2000); Weinberg, (1997). Although this research does not specifically focus on interactive products, software is a significant element in most kinds of interactive products, and so these findings are very relevant here. The cartoon below illustrates very well what can go wrong if requirements are not clearly articulated.

10.2.4 Why Establish Requirements?

The activity of understanding what a product should do has been given various labels—for example, requirements gathering, requirements capture, requirements elicitation, requirements analysis, and requirements engineering. The first two imply that requirements exist out there and we simply need to pick them up or catch them. ‘Elicitation’ implies that ‘others’ (presumably the clients or users) know the requirements and we have to get them to tell us. Requirements, however, are not that easy to identify. You might argue that, in some cases, customers must know what the requirements are because they know the tasks that need supporting, and may have asked for a product to be built in the first place. However, they may not have articulated requirements as yet, and even if they have an initial set of requirements, they probably have not explored them in sufficient detail for development to begin.

The term ‘requirements analysis’ is normally used to describe the activity of investigating and analyzing an initial set of requirements that have been gathered, elicited, or captured. Analyzing the information gathered is an important step, since it is this interpretation of the facts, rather than the facts themselves, that inspires the design. Requirements engineering is a better term than the others because it recognizes that developing a set of requirements is an iterative process of evolution and negotiation, and one that needs to be carefully managed and controlled.

We chose the term establishing requirements to represent the fact that requirements arise from data gathering, analysis, and interpretation activities and have been established from a sound understanding of the users' needs. This also implies that requirements can be justified by and related back to the data collected.

10.3 What are Requirements?

Before we go any further, we need to explain what we mean by a requirement. Intuitively, you probably have some understanding of what a requirement is, but we should be clear. A requirement is a statement about an intended product that specifies what it should do or how it should perform. One of the aims of the requirements activity is to make the requirements as specific, unambiguous, and clear as possible. For example, a requirement for a website might be that the time to download any complete page is less than 5 seconds. Another less precise example might be that teenage girls should find the site appealing. In the case of this latter example, further investigation would be necessary to explore exactly what teenage girls would find appealing. Requirements come in many different forms and at many different levels of abstraction, but we need to make sure that the requirements are as clear as possible and that we understand how to tell when they have been fulfilled. The example requirement shown in Figure 10.1 is expressed using a format called a ‘shell’ from the Volere process (Robertson and Robertson, 2006), which you'll hear more about later in this chapter and in Suzanne Robertson's interview at the end of this chapter. This shell requires quite a bit of information about the requirement itself, including something called a ‘fit criterion,’ which is a way of measuring when the solution meets the requirement. In Chapter 9 we emphasized the need to establish specific usability criteria for a product early on in development, and this part of the shell encourages this.

Figure 10.1 An example requirement using the Volere shell

10.3.1 Different Kinds of Requirements

In software engineering, two different kinds of requirements have traditionally been identified: functional requirements, which say what the system should do, and nonfunctional requirements, which say what constraints there are on the system and its development. For example, a functional requirement for a word processor may be that it should support a variety of formatting styles. This requirement might then be decomposed into more specific requirements detailing the kind of formatting required, such as formatting by paragraph, by character, and by document, down to a very specific level such as that character formatting must include 20 typefaces, each with bold, italic, and standard options. A non-functional requirement for a wordprocessor might be that it must be able to run on a variety of platforms such as PCs, Macs, and Unix machines. Another might be that the target platform is expected to have at least 1.0 GB RAM. A different kind of non-functional requirement would be that it must be delivered in six months' time. This represents a constraint on the development activity itself rather than on the product being developed.

If we consider interactive products in general, other kinds of non-functional requirements become relevant such as physical size, weight, color, and production feasibility. For example, when the PalmPilot was developed (Bergman and Haitani, 2000), an overriding requirement was that it should be physically as small as possible, allowing for the fact that it needed to incorporate batteries and an LCD display. In addition, there were extremely tight constraints on the size of the screen, and that had implications for the number of pixels available to display information. For example, formatting lines or certain typefaces may become infeasible to use if they take up even one extra pixel. Figure 10.2 shows two screen shots from the PalmPilot development. As you can see, removing the line at the left-hand side of the display in the top window released sufficient pixels to display the missing ‘s’ in the bottom window.

Figure 10.2 Every pixel counts

Interaction design involves understanding the functionality required and the constraints under which the product must operate or be developed. However, instead of referring to all requirements that are not functional as simply ‘non-functional’ requirements, we prefer to refine this into further categories. The following is not an exhaustive list of the different requirements we need to be looking out for (see the figure in Suzanne Robertson's interview at the end of this chapter for a more detailed list), nor is it a distinct categorization, however, it does illustrate the variety of requirements that need to be captured.

Functional requirements capture what the product should do. For example, a functional requirement for a robot working in a car assembly plant might be that it should be able to accurately place and weld together the correct pieces of metal. Understanding the functional requirements for an interactive product is fundamental.

Data requirements capture the type, volatility, size/amount, persistence, accuracy, and value of the required data. All interactive products have to handle greater or lesser amounts of data. For example, if the system under consideration is to operate in the share-dealing application domain, then the data must be up-to-date and accurate, and is likely to change many times a day. In the personal banking domain, data must be accurate, must persist over many months and probably years, is very valuable, and there is likely to be a lot of it.

Environmental requirements or context of use refer to the circumstances in which the interactive product will be expected to operate. Four aspects of the environment must be considered when establishing requirements. First is the physical environment, such as how much lighting, noise, and dust is expected in the operational environment. Will users need to wear protective clothing, such as large gloves or headgear, that might affect the choice of interface type? How crowded is the environment? For example, an ATM operates in a very public physical environment. Using speech to interact with the customer is therefore likely to be problematic.

The second aspect of the environment is the social environment. The issues raised in Chapter 4 regarding the social aspects of interaction design, such as collaboration and coordination, need to be explored in the context of the current development. For example, will data need to be shared? If so, does the sharing have to be synchronous, e.g. does everyone need to be viewing the data at once, or asynchronous, e.g. two people authoring a report take turns in editing and adding to it? Other factors include the physical location of fellow team members, e.g. do collaborators have to communicate across great distances?

The third aspect is the organizational environment, e.g. how good is user support likely to be, how easily can it be obtained, and are there facilities or resources for training? How efficient or stable is the communications infrastructure? How hierarchical is the management? And so on.

Finally, the technical environment will need to be established: for example, what technologies will the product run on or need to be compatible with, and what technological limitations might be relevant?

User characteristics capture the key attributes of the intended user group. In Chapter 9 we mentioned the relevance of a user's abilities and skills, and these are an important aspect of user requirements. But in addition to these, a user may be a novice, an expert, a casual, or a frequent user. This affects the ways in which interaction is designed. For example, a novice user will require step-by-step instructions, probably with prompting, and a constrained interaction backed up with clear information. An expert, on the other hand, will require a flexible interaction with more wide-ranging powers of control. Other attributes that may affect the design are: the users' nationality, educational background, preferences, personal circumstances, physical or mental disabilities, and so on. Boxes 10.2 and 10.3 provide more information on national culture and accessibility. The collection of attributes for a ‘typical user’ is called a user profile. Any one product may have a number of different user profiles.

In order to bring the user profiles to life, they are often transformed into a number of ‘personas’ (Cooper, 1999). Personas are rich descriptions of typical users of the product under development that the designers can focus on and design the product for. They don't describe real people, but are synthesized from a number of real users who have been involved in data gathering exercises. Personas are described with rigor and with detail, and they are defined by the goals of that persona, so each persona has a unique set of goals. Basing a persona on a job description or a job title is not appropriate as goals often differ between people even within the same job role, and people with very different job roles may have the same goals for this particular product. For example, personas for a device to alert an amateur runner when he has burned a certain number of calories would focus on different exercising routines, fitness levels, fashion preferences, and so on rather than on the runner's job role.

As well as goals, a persona will include a description of the pretend user's skills, attitudes, tasks, and environment. These are all defined specifically, so instead of describing someone simply as a competent sailor, include detail such as that he has completed a Day Skipper qualification and has over 100 hours of sailing experience in and around European waters. Each persona has a name, often a photograph, and some personal details such as what they do in the evening. It is the addition of precise, credible details that helps designers to see the personas as real potential users, and hence as people they can design for.

Including user experience goals for personas is useful too as it adds context, bringing the intended user to life. For example, imagine you're designing an educational game to help teenagers learn about science, and have chosen user experience goals of ‘exciting’ and ‘enjoyable.’ Introducing a specific character called Damian as a possible end-user, with details of his likes and dislikes, strengths and weaknesses, and aspirations, allows the designer to relate the new game to a concrete situation, and imagine how Damian might react to a particular feature, or game character, and so on. The persona should not be idealized, but include realistic characteristics, such as that Damian suffers from Attention Deficit Disorder, and the challenges that brings.

Usually a product will require a small set of personas rather than just one. It is difficult to give a specific number for how many personas are needed, but it may be helpful to choose one primary persona who represents a large section of the intended user group. The persona in Box 10.4 was developed for an intranet project and illustrates the kind of information that might be included.

Usability goals and user experience goals were described in Chapter 1. These are another kind of requirement, and should be captured together with appropriate measures. In Chapter 9 we introduced the idea of usability engineering, an approach in which specific measures for the usability goals of the product are established and agreed upon early in the development process and are then revisited, and used to track progress as development proceeds. This both ensures that usability is given due priority and facilitates progress tracking. Usability goals include: effectiveness, efficiency, safety, utility, learnability, and memorability. If we are to follow the philosophy of usability engineering and meet these usability goals, then we must identify the appropriate requirements. The same is true for some user experience goals, such as making products that are fun, enjoyable, pleasurable, aesthetically pleasing, and motivating. It is harder to identify quantifiable measures that allow us to track these qualities, but an understanding of how important each of these is to the current development should emerge as we learn more about the intended product.

There are two different perspectives that can be taken when identifying measures for these goals—one focuses on objective measures of the user's performance while the other focuses on the user's perceptions of the interaction. This difference will be discussed further in Chapter 14.

10.4 Data Gathering for Requirements

The overall purpose of data gathering in the requirements activity is to collect sufficient, relevant, and appropriate data so that a set of stable requirements can be produced. Even if a set of initial requirements exists, data gathering will be required to expand, clarify, and confirm those initial requirements. Data gathering needs to cover a wide spectrum of issues because the different kinds of requirement we need to establish are quite varied, as we saw above. We need to find out about the tasks that users currently perform and their associated goals, the context in which the tasks are performed, and the rationale for the current situation.

You met three common forms of data gathering in Chapter 7: interviews, questionnaires, and observation. Below, we first consider how these three techniques are used in the requirements activity, and then we introduce two other techniques—studying documentation and researching similar products—and their use in establishing requirements. Box 10.5 describes a very different approach aimed at prompting inspiration rather than simple data gathering.

Interviews. Interviews are good at getting people to explore issues, and semi-structured or unstructured interviews are often used early on to elicit scenarios (see Section 10.6.1 below). In the context of establishing requirements, it is equally important for development team members to meet stakeholders and for users to feel involved. This on its own may be sufficient motivation to arrange interviews.

Focus groups. Focus groups are good at gaining a consensus view and highlighting areas of conflict and disagreement during the requirements activity. On a social level it also helps for stakeholders to meet designers and each other, and to express their views in public. It is not uncommon for one set of stakeholders to be unaware that their understanding of an issue or a process is different from another's even though they are in the same organization.

The generic idea of a focus group has been tailored for use within the requirements activity and requirements workshops have grown in popularity. The workshops themselves have been developed to have significant structure, evolving in some cases from the earlier JAD idea (see Chapter 9). This does not mean that each requirements workshop is the same, but the workshop structure is carefully planned attendees are carefully chosen, and specific deliverables are produced. Gottesdiener (2002) suggests a very useful, practical approach to requirements workshops that emphasizes planning and deliverables but also collaboration and facilitation. Another form of workshop that has emerged to help identify requirements is described in Box 10.6.

Questionnaires. Questionnaires may be used for getting initial responses that can then be analyzed to choose people to interview or to get a wider perspective on particular issues that have arisen elsewhere. For example, a questionnaire might be used in order to gauge whether a new university helpline would be welcomed by students. This questionnaire could ask for impressions and opinions about current support services and whether the respondent is prepared to be interviewed further. Or the questionnaire might be used to get opinions and views about specific suggestions for the kind of help that would be most appreciated.

Direct observation. In the requirements activity, observation of participants in their natural setting is used to understand the nature of the tasks and the context in which they are performed. Sometimes the observation is carried out by trained observers who record their findings and report them back to the design team, and sometimes the observation is carried out by or with a member of the design team.

Indirect observation. Diaries and interaction logging are used less often within the requirements activity. Interaction logging on an existing system may be used to provide some data about how a task is performed currently, but the information is too tightly coupled with details of the existing computer support to be particularly helpful if a completely new system is planned.

Studying documentation. Manuals and other documentation are a good source of data about the steps involved in an activity and any regulations governing a task. Such documentation should not be used as the only source, however, as everyday practices may augment them and may have been devised by those concerned to make the procedures work in a practical setting. Taking a user-centered view of development means that we are interested in the everyday practices rather than an idealized account.

Studying documentation is good for understanding legislation and getting some background information on the work. It also doesn't involve stakeholder time, which is a limiting factor on the other techniques.

Researching similar products. In Chapter 9 we talked about looking at similar products in order to generate alternative designs. Another reason to look at similar products is to help prompt requirements. For example, when developing an image editor for a mobile device, Kangas and Kinnunen (2005) report that they looked at PC image editing software in order to gain an understanding of the kinds of features and interaction that such a package might offer. Similarly, Chisnell and Brown (2004) performed competitive evaluation of other health plan websites to see what they were doing.

The choice of data gathering techniques for the requirements activity is influenced by several factors including the nature of the task, the participants, the analyst, and the resources available (see Chapter 7 for a more detailed discussion of these factors). It is usual for more than one data gathering technique to be used in order to triangulate the findings. For example, observation to understand the context of task performance, interviews to target specific user groups, questionnaires to reach a wider population, and focus groups to build a consensus view. There is no ‘right’ choice or combination as this will depend on the specific circumstances and resources. Many different combinations are used in practice. Box 10.7 provides examples of just some of these. Note that some examples include evaluating prototypes as part of the requirements activity. This serves to highlight the close relationship between requirements, design, and evaluation, as illustrated in our interaction design process in Chapter 9—the distinction between these phases is blurred and depends mainly on emphasis.

10.4.1 Contextual Inquiry

Contextual inquiry (Holtzblatt and Jones, 1993) is one of seven parts of contextual design (Beyer and Holtzblatt, 1998), which is a structured approach to the collection and interpretation of data from fieldwork with the intention of building a software-based product. Contextual design involves the production of five different models of work.

We include contextual inquiry in this chapter as it is a popular technique for uncovering requirements, and in particular in uncovering requirements relating to the context of use. It is not always used along with the complete contextual design method, and in addition focused contextual inquiry sessions can be conducted more rapidly than extensive user research. For example, Kangas and Kinnunen (2005) conducted interviews with only six to eight people before moving to create a prototype for their mobile application.

Contextual inquiry is an approach that emerged from the ethnographic approach to data gathering. It is tailored to gather data that can be used in design and it follows an apprenticeship model: the designer works as an apprentice to the user. The most typical format for contextual inquiry is a contextual interview, which is a combination of observation, discussion, and reconstruction of past events. Contextual inquiry rests on four main principles: context, partnership, interpretation, and focus.

The context principle emphasizes the importance of going to the workplace and seeing what happens. The partnership principle states that the developer and the user should collaborate in understanding the work; in a traditional interviewing or workshop situation, the interviewer or workshop leader is in control, but in contextual inquiry the spirit of partnership means that the understanding is developed through cooperation.

The interpretation principle says that the observations must be interpreted in order to be used in design, and this interpretation should also be developed in cooperation between the user and the developer. For example, I have a set of paper cards stuck on my screen at work. They are covered in notes; some list telephone numbers and some list commands for the software I use. Someone coming into my office might interpret these facts in a number of ways: that I don't have access to a telephone directory; that I don't have a user manual for my software; that I use the software infrequently; that the commands are particularly difficult to remember. The best way to interpret these observations is to discuss them with me. In fact, I do have a telephone directory, but I keep the numbers on a note to save me the trouble of looking them up in the directory. I also have a telephone with a memory, but it isn't clear to me how to put the numbers in memory, so I use the notes instead. The commands are there because I often forget them and waste time searching through menu structures.

The fourth principle, the focus principle, is related to our discussions in Chapter 7 about keeping the data gathering focused on your goals. In contextual inquiry, as in an unstructured interview, for example, it is easy for the discussion to wander off target. To help avoid this, a project focus is established to guide the interviewer, which will then be augmented by the individual's own focus that arises from their perspective and background.

10.4.2 Data Gathering Guidelines for Requirements

General advice for data gathering was given in Chapter 7, but there are a few more specific guidelines worthy of note when gathering data for requirements.

• Focus on identifying the stakeholders' needs. This may be achieved by studying their existing behavior and support tools, or by looking at other products, such as a competitor's product or an earlier release of your product under development.
• Involve all the stakeholder groups. It is very important to make sure that you get the views of all the right people. This may seem an obvious comment, but it is easy to overlook certain sections of the stakeholder population if you're not careful. We were told about one case where a large distribution and logistics company reimplemented their software systems and were very careful to involve all the clerical, managerial, and warehouse staff in their development process, but on the day the system went live, the productivity of the operation fell by 50%. On investigation it was found that the bottleneck was not in their own company, but in the suppliers' warehouses that had to interact with the new system. No one had asked them how they worked, and the new system was incompatible with their working routines.
• Involving only one representative from each stakeholder group is not enough, especially if the group is large. Everyone you involve in data gathering will have their own perspective on the situation, the task, their job, and how others interact with them. If you only involve one representative stakeholder then you will only get a narrow view.
• Support the data gathering sessions with suitable props, such as task descriptions and prototypes if available. Since the requirements activity is iterative, prototypes or descriptions generated during one session may be reused or revisited in another with the same or a different set of stakeholders. Using props will help to jog people's memories and act as a focus for discussions.

10.5 Data Analysis, Interpretation, and Presentation

Methods and approaches for analysis, interpretation, and presentation of data were discussed in Chapter 8. These are applicable during the requirements activity. However, the aim here is to structure and record descriptions of requirements. Using a format such as the Volere shell (Figure 10.8) highlights the kinds of information to look for and is a good first step in data analysis for requirements. Note that many of the entries are concerned with traceability. For example, who raised the requirement and where can more information about it be found. This information may be captured in documents or in diagrams drawn during analysis. Providing links with raw data as captured on video or audio recordings can be harder, although just as important. Haumer et al. (2000) have developed a tool that records concrete scenarios using video, speech, and graphic media, and relates these recorded observations to elements of a corresponding design. This helps designers to keep track of context and usage information while analyzing and designing for the system.

In parallel with producing Volere shells, the different kinds of requirements will start to emerge. These are best investigated using other, more formal techniques and notations. For example, functional requirements have traditionally been analyzed and documented using data-flow diagrams, state charts, work-flow charts, etc. (see, e.g. Sommerville, 2006). Data requirements can be expressed using entity-relationship diagrams, for example. If the development is to take an object-oriented approach, then functional and data requirements are combined in class diagrams, with behavior being expressed in state charts and sequence diagrams, among others. Examples of two such diagrams representing a portion of a holiday booking system are given in Figure 10.9. These diagrams can be linked to the requirements through the “Event/use case” field in the shell in Figure 10.8.

Figure 10.8 The Volere shell for requirements

We don't go into the detail of how specialized diagrams such as these might be developed, as whole books are dedicated to them. Instead, we describe four techniques that have a user-centered focus and are used to understand users' goals and tasks: scenarios, use cases, essential use cases, and task analysis. All of them may be produced as a result of data gathering sessions, and their output used as props in subsequent data gathering sessions.

The requirements activity is iterated a number of times before a set of stable requirements evolves. As more analysis techniques are applied, a deeper understanding of requirements will emerge and the requirements descriptions will expand and clarify.

Figure 10.9 (a) Class diagram and (b) sequence diagram that might be used to analyze and capture static structure and dynamic behavior (respectively) if the system is being developed using an object-oriented approach

10.5.1 Brainstorming for Innovation

So far we have focused on how requirements may emerge directly from the data gathered. However, establishing a suitable set of requirements is likely to also involve innovation. Brainstorming is not a technique specific to interaction design, or to any other discipline, and is a generic technique used to generate, refine, and develop ideas. It is widely used in interaction design specifically for generating alternative designs (as discussed in Chapter 9) or for suggesting new and better ideas for supporting users.

Various ‘rules’ have been suggested for making a brainstorming session successful, some of which we list below. For requirements, two key success factors are firstly that the participants should know the users' goals that the product is to support, and secondly that no ideas should be criticized or debated (Robertson and Robertson, 2006; Kelley, 2001). Some other suggestions for successful requirements brainstorms are:

1. Include participants from a wide range of disciplines, with a broad range of experience (Robertson and Robertson, 2006; Kelley, 2001).
2. Don't ban ‘silly stuff’ (Kelley, 2001). Unconventional ideas often turn into really useful requirements (Robertson and Robertson, 2006).
3. Use catalysts for further inspiration. Build one idea on top of another (Robertson and Robertson, 2006). Kelley (2001) also suggests jumping back to an earlier idea, or considering alternative interpretations when energy levels start to flag. If you get stuck, use a word pulled randomly from a dictionary to prompt ideas related to the product (Robertson and Robertson, 2006).
4. Keep records. Robertson and Robertson (2006) suggest that every idea should be captured, without censoring. Kelley (2001) suggests that you number them so that you can jump around and refer back to ideas more easily. He also suggests that the walls and tables in the room be covered in paper and that participants be encouraged to sketch, mind-map, and diagram ideas, including keeping the flow of ideas, as spatial memory is very strong and this can facilitate recall.
5. Sharpen the focus (Kelley, 2001). Start the brainstorm with a well-honed problem. This will get the brainstorm off to a good start and makes it easier to pull people back to the main topic if the session wanders.
6. Use warm-up exercises. The group will require ‘warming up’ if they haven't worked together before, most of the group don't brainstorm regularly, or the group is distracted by other pressures (Kelley, 2001). Warm-up exercises might take the form of word games, or the exploration of physical items related or unrelated with the problem at hand. For example, see the use of the TechBox discussed in Chapter 9.

10.6 Task Description

Descriptions of business tasks have been used within software development for many years. During the 1970s and 1980s, ‘business scenarios’ were commonly used as the basis for acceptance testing, i.e. the last testing stage before the customer paid the final fee installment and ‘accepted’ the system. In more recent years, due to the emphasis on involving users earlier in the development lifecycle and the large number of new interactive products now being developed, task descriptions are used throughout development, from early requirements activities through prototyping, evaluation, and testing. Consequently, more time and effort has been put into understanding how best to structure and use them.

As shown by Alexander and Maiden's (2004) collection of scenarios, stories, and use cases, there are many different flavors of task descriptions, and they can be used for different purposes, emphasizing different elements of the product being developed. For example, Alexander and Maiden use a structuring framework that distinguishes task descriptions according to four views which are made up of nine facets including method of description (e.g. text, graphics, image or prototype, and formal, informal, or semi-formal notation), context (e.g. organizational environment and system interaction), and role (descriptive, exploratory, or explanatory).

We shall introduce three of the more common description types here: scenarios, use cases, and essential use cases. Each of these may be used to describe either existing tasks or envisioned tasks with a new product. They are not mutually exclusive and are often used in combination to capture different perspectives or to document different stages during the development lifecycle.

In this section and the next, we use two main examples to illustrate the application of techniques. These are a library catalog service and a shared travel organizer. The library catalog is similar to any you might find in a public or university library, and allows you to access the details of books held in the library: for example, to search for books by a particular author, or by subject, to identify the location of a book you want to borrow, and to check on a member's current loans and status.

The shared travel organizer is to support a group of people in exploring a joint holiday. This might be used by groups of friends or family members and could be located in a travel agent's office or other public space. The travel organizer would help the users to explore different kinds of destination, travel, and accommodation options, offer advice for visa and vaccination requirements, and identify a set of possible holidays that meet the group's requirements.

10.6.1 Scenarios

A scenario is an “informal narrative description” (Carroll, 2000). It describes human activities or tasks in a story that allows exploration and discussion of contexts, needs, and requirements. It does not explicitly describe the use of software or other technological support to achieve a task. Using the vocabulary and phrasing of users means that the scenarios can be understood by the stakeholders, and they are able to participate fully in the development process. In fact, the construction of scenarios by stakeholders is often the first step in establishing requirements.

Imagine that you have just been invited along to talk to a group of users who perform data entry for a university admissions office. You walk in, and are greeted by Sandy, the supervisor, who starts by saying something like:

Telling stories is a natural way for people to explain what they are doing or how to achieve something. It is therefore something that stakeholders can easily relate to. The focus of such stories is also naturally likely to be about what the users are trying to achieve, i.e. their goals. Understanding why people do things as they do and what they are trying to achieve in the process allows us to concentrate on the human activity rather than interaction with technology.

This is not to say that the human activity should be preserved and reflected in any new product we are trying to develop, but understanding what people do now is a good starting point for exploring the constraints, contexts, irritations, facilitators, and so on under which the humans operate. It also allows us to identify the stakeholders and the products involved in the activity. Repeated reference to a particular form, book, behavior, or location indicates that this is somehow central to the activity being performed and that we should take care to understand what it is and the role it plays.

A scenario that might be generated by potential users of a library catalog service is given below:

In this limited scenario of existing system use, there are some things of note: the importance of getting the author's name right, the annoyance concerning the need to enter a password, the lack of flexible search possibilities, and the usefulness of showing a list of similar entries when an exact match isn't clear. These are all indicators of potential design choices for the new catalog system. The scenario also tells us one (possibly common) use of the catalog system: to search for a book by an author when we don't know the title.

The level of detail present in a scenario varies depending on where in the development process they are being used. During requirements it is a good idea for scenarios to emphasize the context, the usability and user experience goals, and the tasks the user is performing. The inclusion of dramatic or emotional elements in scenarios has been found to increase software developers' understanding of context (Strøm, 2006). When used in combination with detailed personas, this kind of scenario can improve the developers' appreciation of the user experience.

Often scenarios are generated during workshop, interview, or brainstorming sessions to help explain or discuss some aspect of the user's goals. They can be used to imagine potential uses of a product as well as to capture existing behavior. They are not intended to capture a full set of requirements, but are a very personalized account, offering only one perspective.

A longer scenario for the shared travel organizer that was elicited in an informal interview is included below. This describes how one function of the system might work: to identify potential holiday options. Note that this scenario includes details about some typical users and their needs. This is the kind of information that you might glean from a requirements interview.

An example of a futuristic scenario, devised by Symbian, showing one vision of how wireless devices might be used in the future is shown in Figure 10.10.

Figure 10.10 A scenario showing how two technologies, a Smartphone and wCommerce (wireless commerce), might be used

In this chapter, we refer to scenarios only in their role of helping to establish requirements. They have a continuing role in the design process that we shall return to in Chapter 11. Indeed, as Alexander and Maiden (2004) show, scenarios have a role to play throughout the lifecycle, and Rosson and Carrol (2002) explain an approach called scenario-based usability engineering that illustrates the use of scenarios within a usability engineering framework.

Capturing scenarios of existing behavior and goals helps in determining new scenarios and hence in gathering data useful for establishing the new requirements. The next activity is intended to help you appreciate how a scenario of existing activity can help identify the requirements for a future application to support the same user goal.

10.6.2 Use Cases

Use cases also focus on user goals, but the emphasis here is on a user–system interaction rather than the user's task itself. They were originally introduced through the object-oriented community in the book Object-Oriented Software Engineering (Jacobson et al., 1992). Although their focus is specifically on the interaction between the user (called an ‘actor’) and a software system, the stress is still very much on the user's perspective, not the system's. The term ‘scenario’ is also used in the context of use cases. In this context, it represents one path through the use case, i.e. one particular set of conditions. This meaning is consistent with the definition given above in that they both represent one specific example of behavior.

A use case is associated with an actor, and it is the actor's goal in using the system that the use case wants to capture. In this technique, the main use case describes what is called the ‘normal course,’ i.e. the set of actions that the analyst believes to be most commonly performed. So, for example, if through data gathering we have found that most users of the library go to the catalog to check the location of a book before going to the shelves, then the normal course for the use case would include this sequence of events. Other possible sequences, called alternative courses, are then listed at the bottom of the use case.

A use case for retrieving the visa requirements using the travel organizer, with the normal course being that information about the visa requirements is available, might be:

1. The system displays options for investigating visa and vaccination requirements.
2. The user chooses the option to find out about visa requirements.
3. The system prompts user for the name of the destination country.
4. The user enters the country's name.
5. The system checks that the country is valid.
6. The system prompts the user for her nationality.
7. The user enters her nationality.
8. The system checks the visa requirements of the entered country for a passport holder of her nationality.
9. The system displays the visa requirements.
10. The system displays the option to print out the visa requirements.
11. The user chooses to print the requirements.

Alternative courses:

6. If the country name is invalid:

1. 6.1 The system displays an error message.
2. 6.2 The system returns to step 3.

8. If the nationality is invalid:

• 8.1 The system displays an error message.
• 8.2 The system returns to step 6.

9. If no information about visa requirements is found:

• 9.1 The system displays a suitable message.
• 9.2 The system returns to step 1.

Note that the number associated with the alternative course indicates the step in the normal course that is replaced by this action or set of actions. Also note how specific the use case is about how the user and the system will interact.

Use cases may be described graphically. Figure 10.11 shows the use case diagram for the travel organizer example. The actor ‘Travel agent’ is associated with the use case ‘Update holiday details.’ Another actor for the travel organizer is the ‘Holidaymaker,’ such as the Thomson family members above. Actors may be associated with more than one use case, so for example the actor ‘Holidaymaker’ is associated with a use case ‘Identify potential holiday options’ as well as the ‘Retrieve visa requirements’ use case. Each use case may also be associated with more than one actor. Note that an actor represents a role, so when Jasmine, who works for the travel agency, is looking for holidays for herself, she adopts the actor role of Holidaymaker, but in her role as travel agent she will adopt the Travel agent actor role.

Figure 10.11 Use case diagram for the travel organizer showing four use cases and two actors

This kind of description has a different style and a different focus from the scenarios described in Section 10.6.1. The layout is more formal, and the structure of ‘good’ use cases has been discussed by many, e.g. Cockburn (2000); Bittner and Spence (2002); Ben Achour (1999). The description also focuses on the user–system interaction rather than on the user's activities; thus a use case presupposes that technology is being used. This kind of detail is more useful at conceptual design stage than during requirements or data gathering, but use cases have been found to help some stakeholders express their views on how existing systems are used and how a new system might work.

To develop a use case, first identify the actors, i.e. the people or other systems that will be interacting with the system under development. Then examine these actors and identify their goal or goals in using the system. Each of these will be a use case.

10.6.3 Essential Use Cases

Essential use cases were developed by Constantine and Lockwood (1999) to combat what they see as the limitations of both scenarios and use cases as described above. Scenarios are concrete stories that concentrate on realistic and specific activities. They therefore can obscure broader issues concerned with the wider organizational view. On the other hand, traditional use cases contain certain assumptions, including the fact that there is a piece of technology to interact with, and also assumptions about the user interface and the kind of interaction to be designed.

Essential use cases represent abstractions from scenarios, i.e. they represent a more general case than a scenario embodies, and try to avoid the assumptions of a traditional use case. An essential use case is a structured narrative consisting of three parts: a name that expresses the overall user intention, a stepped description of user actions, and a stepped description of system responsibility. This division between user and system responsibilities can be very helpful during conceptual design when considering task allocation and system scope, i.e. what the user is responsible for and what the system is to do.

An example essential use case based on the visa requirements example given above is shown in Figure 10.13. Note that the steps are more generalized than those in the use case in Section 10.6.1, while they are more structured than the scenario in Section 10.6.2. For example, the second user intention does not say anything about choosing options or system prompts, it simply states that the user supplies the required information. This could be achieved in a variety of ways including scanning a passport, accessing a database of personal information based on fingerprint recognition, and so on. The point is that at the time of creating this essential use case, there is no commitment to a particular interaction design. Essential use cases would normally be developed before the more detailed use case.

Figure 10.13 An essential use case for retrieving visa requirements in the travel organizer

Instead of actors, essential use cases are associated with user roles. One of the differences is that an actor could be another system, whereas a user role is just that: not a particular person, and not another system, but a role that a number of different people may play when using the system. Just as with actors, though, producing an essential use case begins with identifying user roles.

10.7 Task Analysis

Task analysis is used mainly to investigate an existing situation, not to envision new products. It is used to analyze the underlying rationale and purpose of what people are doing: what are they trying to achieve, why are they trying to achieve it, and how are they going about it? The information gleaned from task analysis establishes a foundation of existing practices on which to build new requirements or to design new tasks.

Task analysis is an umbrella term that covers techniques for investigating cognitive processes and physical actions, at a high level of abstraction and in minute detail. In practice, task analysis techniques have had a mixed reception. The most widely used version is Hierarchical Task Analysis (HTA), and this is the technique we introduce in this chapter. Another well-known task analysis technique called GOMS (Goals, Operations, Methods, and Selection rules) that models procedural knowledge (Card et al., 1983) is described in Chapter 15.

10.7.1 Hierarchical Task Analysis

Hierarchical Task Analysis (HTA) was originally designed to identify training needs (Annett and Duncan, 1967). It involves breaking a task down into subtasks and then into sub-subtasks and so on. These are then grouped together as plans that specify how the tasks might be performed in an actual situation. HTA focuses on the physical and observable actions that are performed, and includes looking at actions that are not related to software or an interactive product at all. The starting point is a user goal. This is then examined and the main tasks associated with achieving that goal are identified. Where appropriate, these tasks are subdivided into subtasks.

Consider the library catalog service, and the task of borrowing a book. This task can be decomposed into other tasks such as accessing the library catalog, searching by name, title, subject, or whatever, making a note of the location of the book, going to the correct shelf, taking it down off the shelf (provided it is there), and finally taking it to the check-out counter. This set of tasks and subtasks might be performed in a different order depending on how much is known about the book, and how familiar the user might be with the library and the book's likely location. Figure 10.14. shows these subtasks and some plans for different paths through those subtasks. Indentation shows the hierarchical relationship between tasks and subtasks.

Note how the numbering works for the task analysis: the number of the plan corresponds to the number of the step to which the plan relates. For example, plan 2 shows how the subtasks in step 2 can be ordered; there is no plan 1 because step 1 has no subtasks associated with it.

An alternative expression of an HTA is a graphical box-and-line notation. Figure 10.15 shows the graphical version of the HTA in Figure 10.14. Here the subtasks are represented by named boxes with identifying numbers. The hierarchical relationship between tasks is shown using a vertical line. If a task is not decomposed any further then a thick horizontal line is drawn underneath the corresponding box.

Figure 10.14 An HTA for borrowing a book from the library

Plans are also shown in this graphical form. They are written alongside the vertical line emitting from the task being decomposed. For example, in Figure 10.15 plan 2 is specified next to the vertical line from box 2: “find required book.”

Figure 10.15 A graphical representation of the task analysis for borrowing a book

INTERVIEW: with Suzanne Robertson

Suzanne Robertson is a principal of The Atlantic Systems Guild, an international think tank producing numerous books and seminars whose aim is to make good ideas to do with systems engineering more accessible. Suzanne is particularly well known for her work in systems analysis and requirements related activities including the development of the Volere requirements techniques.

HS: What are requirements?

SR: Well the problem is that ‘requirements’ has turned into an elastic term. Requirements is an enormously wide field and there are so many different types of requirements. One person may be talking about budget, somebody else may be talking about interfacing to an existing piece of software, somebody else may be talking about a performance requirement, somebody else may be talking about the calculation of an algorithm, somebody else may be talking about a data definition, and I could go on for hours as to what requirement means. What we advise people to do to start with is to look for something we call ‘linguistic integrity’ within their own project. When all people who are connected with the project are talking about requirements, what do they mean? This gets very emotional, and that's why we came up with our framework. We gathered together all this experience of different types of requirements, tried to pick the most common organization, and then wrote them down in a framework.

HS: Please would you explain your framework? (The version discussed in this interview is shown in the figure on page 526. The most recent version may be downloaded from www.systems-guild.com)

SR: Imagine a huge filing cabinet with 27 drawers, and in each drawer you've got a category of knowledge that is related to requirements. In the very first drawer for example you've got the goals, i.e. the reason for doing the project. In the second drawer you've got the stakeholders. These are roles because they could be played by more than one person, and one person may play more than one role. You've got the client who's going to pay for the development, and the customer who's making the decision about buying it. Then you've got stakeholders like the project leader, the developers, the requirements engineers, the designers, the quality people, and the testers. Then you've got the less obvious stakeholders like surrounding organizations, professional bodies, and other people in the organization whose work might be affected by the project you're doing, even if they're never going to use the product.

HS: So do you find the stakeholders by just asking questions?

SR: Yes, partly that and partly by using the domain model of the subject matter, which is in drawer 9, as the driver to ask more questions about the stakeholders. For example, for each one of the subject matter areas, ask who have we got to represent this subject matter? For each one of the people that we come across, ask what subject matter are we expecting from them?

Drawer 3 contains the end users. I've put them in a separate drawer because an error that a lot of people make when they're looking for requirements is that the only stakeholder they talk about is the end user. They decide on the end user too quickly and they miss opportunities. So you end up building a product that is possibly less competitive or relevant. I keep them a bit fuzzy to start with, and as you start to fix on them then you can go into really deep analysis about them: What is their psychology? What are their characteristics? What's their subject-matter knowledge? How do they feel about their work? How do they feel about technology? All of these things help you to come up with the most competitive non-functional requirements for the product.

HS: How do you resolve conflict between stakeholders?

SR: Well, part of it is to get the conflicts out in the open up front, so people stop blaming each other, but that certainly doesn't resolve it. One of the ways is to make things very visible all the way through and to keep reminding people that conflict is respectable, that it's a sign of creativity, of people having ideas. The other thing that we do is that in our individual requirements (that is atomic requirements), which end up living in drawers 9 to 17 of this filing cabinet, we've got a place to say “Conflict: Which other requirement is this in conflict with?” and we encourage people to identify them. Sometimes these conflicts resolve themselves because they're on people's back burners, and some of the conflicts are resolved by people just talking to one another. We have a continuing process of cross-checking requirements and looking for conflicts and if we find some that are just not sorting themselves out, then we stop and have a serious negotiation.

In essence, it's bubbling the conflicts up to the surface. Keep on talking about them and keep them visible. De-personalize it as much as you can. That helps.

HS: What other things are associated with these atomic requirements?

SR: Each one has a unique number and a description that is as close as you can get to what you think the thing means. It also has a rationale that helps you to figure out what it really is. Then the next component is the fit criterion, which is, “If somebody came up with a solution to this requirement, how would you know whether or not it satisfies the requirement?” So this means making the requirement quantifiable, measurable. And it's very powerful because it makes you think about the requirement. One requirement quite often turns into several when you really try and quantify it. It also provides a wonderful opportunity for involving testers, because at that point if you write the fit criterion you can get a tester and ask whether this can be used as input to writing a cost-effective test. Now this is different from the way we usually use the testers, which is to build tests that test our solutions. Here I want to get them in much earlier, I want them to test whether this requirement really is a requirement.

HS: So what's in drawers 18 through 27?

SR: Well here you can get into serious quarrels. The overall category is ‘project issues,’ and people often say they're not really requirements, and they aren't. But if the project is not being managed according to the real work that's being done, in other words the contents of the drawers, then the project goes off the rails. In project issues we create links so that a project manager can manage the project according to what's happening to the requirements.

In the last drawer we have design ideas. People say when you're gathering requirements you should not be concerned with how you're going to solve the problem. But mostly people tell you requirements in the form of a solution anyway. The key thing is to learn how to separate the real requirements from solution ideas, and when you get a solution idea, pop it in this drawer. This helps requirements engineers, I think, because we are trained to think of solutions, not to dig behind and find the real problem.

HS: How do you go about identifying requirements?

SR: For too long we've been saying the stakeholders should give us their requirements: we'll ask them and they'll give them to us. We've realized that this is not practical—partly because there are many requirements people don't know they've got. Some requirements are conscious and they're usually because things have gone wrong or they'd like something extra. Some requirements are unconscious because maybe people are used to it, or maybe they haven't a clue because they don't see the overall picture. And then there are undreamed-of requirements that people just don't dream they could ever have, because we've all got boundaries based on what we think technology is capable of doing or what we know about technology or what our experience is. So it's not just asking people for things, it's also inventing requirements. I think that's where prototyping comes in and scenario modeling and storyboarding and all of those sorts of techniques to help people to imagine what they could have.

If you're building a product for the market and you want to be more competitive you should be inventing requirements. Instead of constricting yourself within the product boundary, say, “Can I push myself out a bit further? Is there something else I could do that isn't being done?”

HS: So what kinds of techniques can people use to push out further?

SR: One of the things is to learn how to imagine what it's like to be somebody else, and this is why going into other fields, for example family therapy, is helpful. They've learned an awful lot about how to imagine you might be somebody else. And that's not something that software engineers are taught in college normally and this is why it's very healthy for us to be bringing together the ideas of psychology and sociology and so on with software and systems engineering. Bringing in these human aspects—the performance, the usability features, the ‘look and feel’ features—that's going to make our products more competitive.

I always tell people to read a lot of novels. If you're having trouble relating to some stakeholders, for example, go and read some Jane Austen and then try to imagine what it would have been like to have been the heroine in Pride and Prejudice. What would it have been like to have to change your clothes three times a day? I find this helps me a lot, it frees your mind and then you can say, “OK, what's it really like to be that other person?” There's a lot to learn in that area.

HS: So what you're saying really is that it's not easy.

SR: It's not easy. I don't think there's any particular technique. But what we have done is we have come up with a lot of different ‘trawling’ techniques, along with recommendations, that can help you.

HS: Do you have any other tips for gathering requirements?

SR: It's important for people to feel that they've been heard. The waiting room (drawer number 26) was invented because of a very enthusiastic high-level stakeholder in a project we were doing. She was very enthusiastic and keen and very involved. Wonderful! She really gave us tremendous ideas and support. The problem was she kept having ideas, and we didn't know what to do. We didn't want to stop her having ideas, on the other hand we couldn't always include them because then we would never get anything built. So we invented the waiting room. All the good ideas we have we put in there and every so often we go into the waiting room and review the ideas. Some of them get added to the product, some are discarded, and some are left waiting. The psychology of it is very good because the idea's in the waiting room, everyone knows it's in there, but it's not being ignored. When people feel heard, they feel better and consequently they're more likely to cooperate and give you time.

The Template

PROJECT DRIVERS

1. 1. The Purpose of the Product
2. 2. Client, Customer and other Stakeholders
3. 3. Users of the Product

PROJECT CONSTRAINTS

1. 4. Mandated Constraints
2. 5. Naming Conventions and Definitions
3. 6. Relevant Facts and Assumptions

FUNCTIONAL REQUIREMENTS

1. 7. The Scope of the Work
2. 8. The Scope of the Product
3. 9. Functional and Data Requirements

NON-FUNCTIONAL REQUIREMENTS

1. 10. Look and Feel Requirements
2. 11. Usability Requirements
3. 12. Performance Requirements
4. 13. Operational Requirements
5. 14. Maintainability and Portability Requirements
6. 15. Security Requirements
7. 16. Cultural and Political Requirements
8. 17. Legal Requirements

PROJECT ISSUES

1. 18. Open Issues
2. 19. Off-the-Shelf Solutions
3. 20. New Problems
4. 21. Tasks
5. 22. Cutover
6. 23. Risks
7. 24. Costs
8. 25. User Documentation and Training
9. 26. Waiting Room
10. 27. Ideas for Solutions

The Volere Requirements Specification Template © Atlantic Systems Guild.