DOC PREVIEW
Toronto CSC 340 - What are Requirements

This preview shows page 1-2-3-4-5 out of 16 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

©2004 Steve Easterbrook. DRAFT – PLEASE DO NOT CIRCULATE page 1C H A P T E R 2What 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 requirementsengineering. We will spend some time looking at two fundamental principles inrequirements engineering: (1) that if we plan to build a new system, it is a good idea todescribe 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 tensionbetween these two principles explains some wildly different perceptions of RE. We willbreak 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 arethings that are true of the world anyway), and specifications (which are descriptions ofwhat the system we are designing should do if it is to meet the requirements), and showhow these are inter-related. Throughout the chapter we will emphasize that we areprimarily 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 willhelp you understand what requirements engineering is all about. By the end of the chapteryou should be able to: Distinguish between requirements and specifications, and describe the relationshipbetween them. Explain how a system can meet its specification but still fail. Give examples of how misunderstanding of the domain properties can cause asystem not to meet its requirements. Explain why any specification is likely to be imperfect. Distinguish between verification and validation, and give criteria for performingeach. Explain the different perspectives of the systems engineer and the softwareengineer. Give examples of how the systems engineer can move the boundary between theapplication domain and the machine, to change the design problem. List the principal parts of a design pattern, and explain why a clear understandingof the requirements is needed to select appropriate design patterns. Use problem frames to describe the differences between major problem types suchas control systems, information systems, and desktop application software.2.1. Requirements Describe ProblemsIn chapter 1 we introduced the idea of capturing the purpose of a software-intensive system. Toidentify the purpose, we need to study the human activities that the system supports because it isthese activities that give a system its purpose. Suppose we are setting out to design a new system, orperhaps to modify an existing system. Presumably, we have perceived an opportunity to usesoftware technology to make some activities more efficient, or more effective, or perhaps to enablesome new activities that are not currently feasible. But what, precisely, is the problem we are tryingto solve? If we want to understand the purpose of the new system, then we need to be clear aboutwhat problem it is intended to solve.©2004 Steve Easterbrook. DRAFT – PLEASE DO NOT CIRCULATE page 22.1.1. Separating the Problem from the SolutionThe first key insight of requirements engineering is that it is worthwhile to separate thedescription of a problem from the description of a solution to that problem. For a software-intensivesystem, 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 lesswell-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 discussionswith customers or users, or in a collection of ‘user stories’ or ‘scenarios’. And for some projectsthere is no explicit statement of what the problem is, just a vague understanding of the problem inthe minds of the developers. A basic principle of Requirements Engineering is that problemstatements should be made explicit.Separating the problem from potential solutions, and writing an explicit problem statement isuseful for a number of reasons. To create a problem statement, we need to study the messy “realworld”, ask questions about the activities that the new system should support, decide a suitablescope for the new system, and then write a precise description of the problem. This allows adesigner to properly understand the nature of the problem, before considering how to solve it. Theexercise of analyzing the real world problem situation will reveal many subtleties that might bemissed 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 aboutwhether their needs have been adequately captured. The problem statement can be used when comparing different potential designs, and whencomparing design trade-offs.ProblemStatementImplementationStatementSystemProblemSituationFigure 1: Separating the problem statement from thesolution statement (adapted from Blum 1992)©2004 Steve Easterbrook. DRAFT – PLEASE DO NOT CIRCULATE page 3 Making the problem statement explicit makes it much easier to test the system – a candidatesolution is only correct if it solves the problem as stated.Of course, the solution might still be unsatisfactory, because we might have made a poor job ofwriting down the problem statement, or we might have focused on the wrong problem. In otherwords we need to check both that the solution is correct according to the problem statement, andthat the solution statement corresponds to the real-world needs of the stakeholders (see figure 1).But we have gained something by breaking this down into two separate steps – we can ask thequestion of whether the problem statement is adequate, independently from the question of testingwhether a proposed design solves the problem as stated.2.1.2. Intertwining of Problems and SolutionsThe second key insight of requirements engineering is


View Full Document

Toronto CSC 340 - What are Requirements

Documents in this Course
Scoping

Scoping

10 pages

Load more
Download What are Requirements
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view What are Requirements and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view What are Requirements 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?