User-Centred Requirements Engineering

Requirements are a ubiquitous part of our lives, so it may seem strange that they have been singled out for study in computer science. Requirements and communication are inextricably intertwined. We start making our requirements clear soon after we are born by crying, usually for food. Parents soon become expert requirements engineers in inferring what their children want; but even in the cradle the dilemma of requirements is exposed. A baby’s cry is ambiguous. Does he or she want food, warmth or a cuddle? How do we translate our interpretation into the right food, degree of warmth, or appropriate rocking motion?

To understand the requirements process we need some knowledge about our own processes of understanding problems and communicating with people. Requirements analysis is a cognitive process in which we understand problems, learn about domains and negotiate to achieve what we want. We have to understand details describing the real world and then abstract these to create models of the domain. The process of abstraction, in cognitive terms, involves perception and comprehension (making sense of what we hear and see) and learning. Requirements analysis can be seen as discovery-based learning. We start with a vague understanding of what is required and of the domain in which the new system is to be designed. By gathering information and requirements we gradually learn about the goals the new system should fulfil. Requirements is also a form of problem solving. Once the desired state of the world has been understood, i.e. the requirements for a new system, the designer has to solve the problem of achieving them. The inevitable intertwining of requirements and design is a problem-solving process in which the designer uses memory of previous successful solutions, software engineering methods and creative thought to achieve a new design.

RE is a flexible process where activities and tasks can be mixed in many different combinations. So while there is no one “cook-book” method for requirements, the basic steps can be described and composed into a process depending on the application context being investigated. However, a single all-embracing RE cook-book method would not be desirable. RE has to fit into a range of different contexts, and integrate with existing development methods such as SSADM, the more recent object-oriented development methods and the unified modelling process. Consequently, this chapter will review the activities in RE as a set of tasks, and then present them as processes for different requirements contexts, i.e. variations according to the application being developed and the starting point of the requirements investigation.

One of the most important, yet error-prone, aspects of RE is language. Users, analysts and designers have to communicate to discover a mutually agreed solution that the users want and the designers can build. Understanding language is therefore an important part of understanding RE. The following text draws on the science of linguistics and conversation analysis that belongs to the discipline of sociology. One branch of linguistics, pragmatics or discourse, is particularly relevant. Researchers in pragmatics are concerned with how meaning is constructed in context and how conversations are controlled between parties. In RE we need to understand the pitfalls in misunderstandings and develop effective procedures to manage requirements conversations.

The previous chapter discussed dialogues for requirements, and processes for discovering them. This chapter focuses on how requirements are represented and recorded. Representation and requirements dialogues are, of course, closely linked. Representations become part of the conversation when we refer to and point at specifications and models during the process of analysis. Representations have been a somewhat neglected part of RE, although this problem has received increasing attention in several literatures (Muller, 1991). Requirements tend to be documented as lists of things that need to be implemented, such as functions or goals. However, requirements may be expressed in models as requirements specifications rather than just lists; alternatively, requirements may be embedded in a prototype design. Clearly lists, specifications, designs and prototypes all represent requirements in some manner; the question is, what are the merits of different types of requirements expression? This chapter addresses this question and looks at how different representations fit within the RE process.

Requirements not only have to deal with events that are unexpected, they also need to anticipate the consequences of things going wrong. The unexpected can arise from many sources. Environmental events, often attributed incorrectly to “acts of God”, create problems through adverse weather and physical conditions, causing machinery to break down so that normal system functions cannot be assumed. Furthermore, people make mistakes. Even though many accidents are blamed on people making mistakes, human error is usually only one of many contributing factors. Safety critical systems should prevent, or at least reduce the chance of, human error. Requirements analysis has to try to anticipate these problems, but this is a difficult task. The problem is one of 20/20 foresight, or trying to anticipate all the possible combinations of future events that might occur in a designed system, and then trying to ensure that the design prevents or at least counteracts possible failures. Given the large number of possible errors people can make, in combination with extremes in weather and the many components in complex systems that could fail, we have a combinatorial explosion. So anticipating the future is a very difficult task; however, that does not mean we should not attempt it. Even standard methods such as object-oriented analysis and use cases draw attention to alternative as well as normal courses of action.

In this final chapter I will speculate on the future courses that requirements engineering may take. This is not a matter of imagining the impact that future technology may have on RE, however; rather, it is motivated by revisiting the fundamental problems of RE: communicating, understanding and transforming needs into designs. RE will face more pressing problems as systems become more complex, distributed and ubiquitous. It will become increasingly difficult for any one person to understand such complexity and then specify requirements for it. We therefore have a dilemma of what I call the horizon of knowability: as technology advances so does our ability to design more complex systems, yet our ability to understand such systems is finite. We are limited by our cognitive capacity and the time taken to understand complex systems; this capacity can only change slowly as we devise better methods. In contrast, the rate of technological change is exponential, as it feeds progressively on its own baseline. We tend to acknowledge this as the accelerating pace of change in society. So where does the answer lie? I will argue that we should look in two possible directions: first toward artificial intelligence and learning machines, and secondly towards automated design environments that communicate with us in natural language and graphics. Both have a common implication: in the future, requirements engineering will become progressively concerned with the design environment, while what we currently consider to be requirements analysis will either be learned automatically or achieved by conversation with an application generator machine.