©2004 Steve Easterbrook. DRAFT – PLEASE DO NOT CIRCULATE page 1Part AIntroductionIn this first part of the book we explore the foundations of Requirements Engineering,and introduce many of the key ideas. Chapter 1 explains what we mean by requirementsengineering, and defines software-intensive systems as a suitable scope for application ofRE. Chapter 2 explores the idea of a requirement, and introduces some key distinctions forunderstanding requirements. For example, a key distinction is between describing aproblem to be solved and describing a particular design for solving it. We also distinguishbetween two very different worlds: the world of human activity in which problems that needsolving can be found, and the world of computer technology in which programs are writtenand tested to run on particular hardware configurations. A requirements analyst mustunderstand both of these worlds, and seek ways to bridge between them. This explainswhy requirements analysts concern themselves with people, and with the organizationaland social contexts that surround them, as well as the technical aspects of designing andimplementing computer systems.Chapter 3 examines the context in which requirements engineering takes place – aspart of a larger engineering process. We will define what we mean by engineering, andexplore the role of RE in an engineering project lifecycle. Because of the huge variety ofways in which computers are used, the processes of requirements engineering varytremendously from one domain to another. Developing software for an aircraft flight controlsystem is a very different task from developing the software for a new web browser. Wewill explore the commonalities and the differences by considering the nature of differenttypes of engineering project.Finally, requirements engineering is concerned with complex problems, and so weneed a way of dealing with complexity. Chapter 4 explores how to understand complexproblems by identifying and describing systems: fragments of the world that make sensewhen treated as a coherent set of activities. As will become clear, many of the systems weneed to study are human activity systems. To understand such systems we will need todraw on ideas from a variety of disciplines, ranging from social and cognitive sciencesthrough to logic, mathematics and the engineering sciences. Chapter 1: What is Requirements Engineering? Chapter 2: What are Requirements? Chapter 3: What is Engineering? Chapter 4: What is a System?©2004 Steve Easterbrook. DRAFT – PLEASE DO NOT CIRCULATE page 2C H A P T E R 1What is Requirements Engineering?The field of Requirements Engineering (RE) is relatively new, so it seems appropriateto 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 provideboth a motivation 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 inter-related set of human activities, supported by computer technology. The requirementsexpress the purpose of such a system. They allow us to say something meaningful abouthow good a particular system is, by exposing how well it suits its purpose. Or, moreusefully, they allow us to predict how well it will suit its purpose, if we design it in aparticular way. The idea of human-centered design is crucial – the real goal of anengineering process is to improve human activities in some way, rather than to build sometechnological artifact.Requirements engineering applies to the development of all software-intensivesystems, but not necessarily to the development of all software, as we shall see. There area huge range of different kinds of software-intensive system, and the practice of RE variesacross this range. Our aim throughout this book is to explore both what is common andwhat varies across these different types of system. We will set the scene in this chapter byoffering some examples of different types of system development, and indicate the role ofRE in each. Finally, we will end the chapter with a quick tour of the kinds of activity thatcomprise 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 withcomplexity. Explain what is meant by a “wicked problem”, and give examples of wickedproblems. Use the definition of quality as “fitness for purpose” to explain why software qualitycannot be measured unless the requirements are properly understood. Give examples of different types of engineering project to which requirementsengineering applies. Suggest some types of software for which requirements engineering isunnecessary. 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 ConceptsSoftware-intensive systems have penetrated nearly all aspects of our lives, in a huge variety ofways. Information technology has become so powerful and so adaptable, that the opportunities fornew uses seem boundless. However, our experience of actual computer systems, once they have©2004 Steve Easterbrook. DRAFT – PLEASE DO NOT CIRCULATE page 3been developed, is often disappointing. They fail to work in the way 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 acomputer system is unsatisfactory, it is because the system was designed without an adequateunderstanding of its purpose, or because we are using it for a purpose different from the intendedone. 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 thecontexts in which it will be used. Or, put another way,
View Full Document
Unlocking...