Ingenieria De Requerimientos

©2004 Steve Easterbrook.

DRAFT – PLEASE DO NOT CIRCULATE

page 2

C H A PTER 1

What is Requirements Engineering?
The field of Requirements Engineering (RE) is relatively new, so it seems appropriate to begin by asking some very basic questions: What is RE all about? When is it needed? What kinds of activities are involved in doing RE? Our answers to these questions provide both amotivation and a scope for the techniques introduced in the remainder of the book. We will begin with the idea of a software-intensive system, by which we mean an interrelated set of human activities, supported by computer technology. The requirements express the purpose of such a system. They allow us to say something meaningful about how good a particular system is, by exposing how well it suitsits purpose. Or, more usefully, they allow us to predict how well it will suit its purpose, if we design it in a particular way. The idea of human-centered design is crucial – the real goal of an engineering process is to improve human activities in some way, rather than to build some technological artifact. Requirements engineering applies to the development of all software-intensive systems, butnot necessarily to the development of all software, as we shall see. There are a huge range of different kinds of software-intensive system, and the practice of RE varies across this range. Our aim throughout this book is to explore both what is common and what varies across these different types of system. We will set the scene in this chapter by offering some examples of different types ofsystem development, and indicate the role of RE in each. Finally, we will end the chapter with a quick tour of the kinds of activity that comprise RE, as a preview of the rest of the book. By the end of the chapter you should be able to:  Define the term software-intensive system.  Summarize the key techniques used in requirements engineering for dealing with complexity.  Explain what is meant bya “wicked problem”, and give examples of wicked problems.  Use the definition of quality as “fitness for purpose” to explain why software quality cannot be measured unless the requirements are properly understood.  Give examples of different types of engineering project to which requirements engineering applies.  Suggest some types of software for which requirements engineering is unnecessary. Explain the risks of an inadequate exploration of the requirements.  Account for the reasons that requirements change over time.  Distinguish between the hard and soft systems perspectives.  Judge whether a human-centered perspective is appropriate for a particular project.  Describe the typical activities of the requirements analyst.

1.1. Basic Concepts
Software-intensive systems havepenetrated nearly all aspects of our lives, in a huge variety of ways. Information technology has become so powerful and so adaptable, that the opportunities for new uses seem boundless. However, our experience of actual computer systems, once they have

©2004 Steve Easterbrook.

DRAFT – PLEASE DO NOT CIRCULATE

page 3

been developed, is often disappointing. They fail to work in theway we expect, they are unreliable, and sometimes dangerous, and they may create more problems than they solve. Why should this be? Computer systems are designed, and anything that is designed has an intended purpose. If a computer system is unsatisfactory, it is because the system was designed without an adequate understanding of its purpose, or because we are using it for a purpose different fromthe intended one. Both problems can be mitigated by careful analysis of purpose throughout a system’s life. Requirements Engineering provides a framework for understanding the purpose of a system and the contexts in which it will be used. Or, put another way, requirements engineering bridges the gap between an initial vague recognition that there is some problem to which we can apply computer...