Fundamentals of Requirements Engineering 2003 4 Steve Easterbrook and Bashar Nuseibeh Section A Introduction Chapter 1 What is Requirements Engineering Chapter 2 What are Requirements Chapter 3 What is Engineering Chapter 4 What is a System Section B Eliciting and Planning Chapter 5 Elicitation Sources and Targets Chapter 6 Elicitation Techniques Chapter 7 The Feasibility Study Chapter 8 Risk Section C Modeling and Analyzing Chapter 9 An introduction to modeling Chapter 10 Enterprises Chapter 11 Information Structures Chapter 12 Behaviour Chapter 13 Quality Requirements Section D Communicating and Agreeing Chapter 14 Validation Demystified Chapter 15 Specifications and Documentation Chapter 16 Prototyping and Walkthroughs Chapter 17 Inspection and Review Chapter 18 Negotiation and Prioritization Section E Realizing and Evolving Chapter 19 Requirements Evolution Chapter 20 Requirements and Architectures Chapter 21 Traceability and Rationale Chapter 22 Consistency Management Section F Advanced Topics Chapter 23 Formal Methods in RE Chapter 24 Research Methodology in RE Appendices 2004 Steve Easterbrook DRAFT PLEASE DO NOT CIRCULATE page 1 C H A PTER 2 What are requirements The simple question what are requirements turns out not to have a simple answer In this chapter we will explore many of the key ideas that underlie requirements engineering We will spend some time looking at two fundamental principles in requirements engineering 1 that if we plan to build a new system it is a good idea to describe the problem to be solved separately from particular solutions to the problem and 2 that for most systems this separation is impossible to achieve in practice The tension between these two principles explains some wildly different perceptions of RE We will break down the idea of a problem description into three components the requirements which are things in the world we would like to achieve the domain properties which are things that are true of the world anyway and specifications which are descriptions of what the system we are designing should do if it is to meet the requirements and show how these are inter related Throughout the chapter we will emphasize that we are primarily concerned with systems of human activities rather than software or computers Our aim in this chapter is to introduce a number of key ideas and distinctions that will help you understand what requirements engineering is all about By the end of the chapter you should be able to Distinguish between requirements and specifications and describe the relationship between them Explain how a system can meet its specification but still fail Give examples of how misunderstanding of the domain properties can cause a system not to meet its requirements Explain why any specification is likely to be imperfect Distinguish between verification and validation and give criteria for performing each Explain the different perspectives of the systems engineer and the software engineer Give examples of how the systems engineer can move the boundary between the application domain and the machine to change the design problem List the principal parts of a design pattern and explain why a clear understanding of the requirements is needed to select appropriate design patterns Use problem frames to describe the differences between major problem types such as control systems information systems and desktop application software 2 1 Requirements Describe Problems In chapter 1 we introduced the idea of capturing the purpose of a software intensive system To identify the purpose we need to study the human activities that the system supports because it is these activities that give a system its purpose Suppose we are setting out to design a new system or perhaps to modify an existing system Presumably we have perceived an opportunity to use software technology to make some activities more efficient or more effective or perhaps to enable some new activities that are not currently feasible But what precisely is the problem we are trying to solve If we want to understand the purpose of the new system then we need to be clear about what problem it is intended to solve 2004 Steve Easterbrook DRAFT PLEASE DO NOT CIRCULATE page 2 Problem Situation Problem Statement Implementation Statement System Figure 1 Separating the problem statement from the solution statement adapted from Blum 1992 2 1 1 Separating the Problem from the Solution The first key insight of requirements engineering is that it is worthwhile to separate the description of a problem from the description of a solution to that problem For a software intensive system the solution description includes anything that expresses the design the program code design drawings the system architecture user manuals etc The problem description is usually less well documented for some projects it may be captured in a concept of operations document or a requirements specification For other projects it may exist only in notes taken from discussions with customers or users or in a collection of user stories or scenarios And for some projects there is no explicit statement of what the problem is just a vague understanding of the problem in the minds of the developers A basic principle of Requirements Engineering is that problem statements should be made explicit Separating the problem from potential solutions and writing an explicit problem statement is useful for a number of reasons To create a problem statement we need to study the messy real world ask questions about the activities that the new system should support decide a suitable scope for the new system and then write a precise description of the problem This allows a designer to properly understand the nature of the problem before considering how to solve it The exercise of analyzing the real world problem situation will reveal many subtleties that might be missed if the developer launches straight into designing a solution It might reveal that the most obvious problem is not really the right one to solve The problem statement can be shared with various stakeholders to initiate a discussion about whether their needs have been adequately captured The problem statement can be used when comparing different potential designs and when comparing design trade offs 2004 Steve Easterbrook DRAFT PLEASE DO NOT CIRCULATE page 3 Problem situation change System Abstract model of problem situation implementation statement problem statement Figure 2 Delivering
View Full Document
Unlocking...