Skip to main content
main-content

Über dieses Buch

If you have picked up this book and are browsing the Preface, you may well be asking yourself"What makes this book different from the large number I can find on amazon. com?". Well, the answer is a blend of the academic and the practical, and views of the subject you won't get from anybody else: how psychology and linguistics influence the field of requirements engineering (RE). The title might seem to be a bit of a conundrum; after all, surely requirements come from people so all requirements should be user-centred. Sadly, that is not always so; many system disasters have been caused simply because requirements engineering was not user-centred or, worse still, was not practised at all. So this book is about putting the people back into com­ puting, although not simply from the HCI (human-computer interaction) sense; instead, the focus is on how to understand what people want and then build appropriate computer systems.

Inhaltsverzeichnis

Frontmatter

1. Introduction

Abstract
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?
Alistair Sutcliffe

2. Understanding People

Abstract
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.
Alistair Sutcliffe

3. RE Tasks and Processes

Abstract
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.
Alistair Sutcliffe

4. Understanding Requirements Conversations

Abstract
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.
Alistair Sutcliffe

5. Representing the Problem

Abstract
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.
Alistair Sutcliffe

6. Scenario-Based Requirements Engineering (SCRAM)

Abstract
So far I have discussed the more theoretical aspects of RE, interspersed with some practical advice; in this chapter a practical method of scenario-based RE is described that incorporates many of the ideas expounded in previous chapters. The chapter also draws on experience in requirements evaluation with prototypes (Sutcliffe et al., 2000; Sutcliffe, Economou and Markis, 1999). The method started life in research projects and has since been improved through several iterations to accumulate the lessons of practice. SCRAM has been validated by empirical study to test its strengths and weaknesses (Sutcliffe, 1995c, 1998; Sutcliffe and Ryan, 1998).
Alistair Sutcliffe

7. Requirements Analysis for Safety Critical Systems

Abstract
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.
Alistair Sutcliffe

8. Future Directions

Abstract
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.
Alistair Sutcliffe

Backmatter

Weitere Informationen