Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
4.5 The requirements specification 41 enriching their jobs. They may resent any attempt to speed up or intensify their work. They may object to any facilities in the system to monitor their work rate. The management in the bank, however, will probably be concerned with costs, performance and effectiveness. There may very well be a conflict of interest between the cashiers and the managers. This paints an extreme picture, but illustrates that the users will not necessarily present a single, uniform view. Another example of a potential gulf between users and analysts is to do with the level of expectation of users. Some users have seen science fiction films and come to believe that computers can do anything – or at least can offer a high level of artificial intelligence. Others, perhaps, are naive in the opposite direction and believe that computers can carry out only the most mundane tasks. To sum up, the role of the analyst is: ■ to elicit and clarify the requirements from the users ■ to help resolve possible differences of view amongst the users and clients. ■ to advise users on what is technically possible and impossible. ■ to document the requirements (see the next section). ■ to negotiate and to gain the agreement of the users and clients to a (final) requirements specification. The journey from the users’ initial idea to an agreed requirements specification will often be long and tortuous. 4.5 ● The requirements specification The end product of requirements elicitation and analysis is the requirements specification. It is a vital piece of documentation that is crucial to the success of any software development project. If we cannot precisely state what the system should do, then how can we develop the software with any confidence, and how can we hope to check that the end product meets its needs? The specification is the reference document against which all subsequent development is assessed. Three important factors to be considered are: 1. the level of detail 2. to whom the document is addressed 3. the notation used. The first factor is about the need to restrict the specification as much as possible to specify what the system should do rather than how it should do it. As we have seen, the specification should ideally be the users’ view of the system rather than anything about how the system is to be implemented. The second factor arises because the specification has to be understood by two different sets of people – the users and the developers. The people in these two sets have different backgrounds, expertise and jargon. They share the common aim of clearly
42 Chapter 4 ■ Requirements engineering describing what the system should do, but they will each be inclined to use a different language. The users will have a preference for non-technical descriptions expressed in natural language. Unfortunately, while natural language is excellent for poetry and love letters, it is a poor vehicle for achieving a precise, consistent and unambiguous specification. On the other hand, the analysts, being of a technical orientation, will probably want to use precise (perhaps mathematical) notation in order to specify a system. This brings us to the question of the notation. Several notations are available for writing specifications: ■ informal, writing in natural language, used as clearly and carefully as possible. In this chapter we will concentrate on this approach. ■ formal, using mathematical notation, with rigor and conciseness. This approach is outside the scope of this book. Formal methods tend to be used only in safety critical systems. ■ semi-formal, using a combination of natural language together with various diagrammatic and tabular notations. Most of these notations have their origins in methods for software design, that is, in methods for the implementation of software. Thus there is a potential problem of including information about the implementation. These notations are discussed later in this book and include pseudo-code, data flow diagrams and class diagrams. At the present time, most requirements specifications are written in natural language, assisted by use case diagrams. One approach is to draw up two documents: 1. a requirements specification written primarily for users, describing the users’ view of the system and expressed in natural language. This is the substance of the contract between the users and the developers. 2. a technical specification that is used primarily by developers, expressed in some more formal notation and describing only a part of the information in the full requirements specification. If this approach is adopted, there is then the problem of ensuring that the two documents are compatible. 4.6 ● The structure of a specification Given that a requirements specification will usually be written in natural language, it is useful to plan the overall structure of the specification and to identify its component parts. We can also identify those ingredients that, perhaps, should not be included at all, because they are concerned with the implementation rather than the requirement. The remainder of this section presents one way of structuring specifications. One approach to giving a clear structure to a specification is to partition it into parts. Software essentially consists of the combination of data and actions. In specifications,
- Page 13 and 14: xii Detailed contents 14.7 Repetiti
- Page 15 and 16: xiv Detailed contents 19.7 Unit tes
- Page 17 and 18: xvi Detailed contents 26 Agile meth
- Page 19 and 20: xviii Detailed contents 32.4 Softwa
- Page 21 and 22: xx Preface Software Engineering and
- Page 23 and 24: xxii Preface are engaged on a proje
- Page 26 and 27: CHAPTER 1 This chapter: ■ reviews
- Page 28 and 29: 1.3 The cost of software production
- Page 30 and 31: 100% 10% 1970 SELF-TEST QUESTION Ha
- Page 32 and 33: Analysis and design 1 /3 Coding 1 /
- Page 34 and 35: SELF-TEST QUESTION 1.7 Maintenance
- Page 36 and 37: 1.8 Reliability 13 in the first pla
- Page 38 and 39: 1.8 Reliability 15 contain a comma
- Page 40 and 41: Ease of maintenance Reliability Con
- Page 42 and 43: Exercises 19 • Exercises These ex
- Page 44 and 45: Further reading 21 Analyses of the
- Page 46 and 47: ■ documentation ■ maintenance
- Page 48 and 49: 2.2 The tasks 25 An important examp
- Page 50 and 51: 2.4 Methodology 27 reality. Like an
- Page 52 and 53: ■ error free ■ fault ■ tested
- Page 54 and 55: 3.2 ● Technical feasibility 3.3 C
- Page 56 and 57: 3.5 Case study 33 The hardware cost
- Page 58 and 59: Answers to self-test questions 3.1
- Page 60 and 61: 4.2 The concept of a requirement 37
- Page 62 and 63: 4.3 The qualities of a specificatio
- Page 66 and 67: 4.6 The structure of a specificatio
- Page 68 and 69: 4.7 ● Use cases 4.7 Use cases 45
- Page 70 and 71: Summary The ideal characteristics o
- Page 72: Further reading 49 Further reading
- Page 76 and 77: CHAPTER 5 This chapter explains: 5.
- Page 78 and 79: 5.3 Styles of human-computer interf
- Page 80 and 81: 5.5 Design principles and guideline
- Page 82 and 83: 5.5 Design principles and guideline
- Page 84 and 85: SELF-TEST QUESTION 5.2 What problem
- Page 86 and 87: 5.8 Help systems 63 Our plan is to
- Page 88 and 89: Further reading 65 5.5 Design a use
- Page 90 and 91: CHAPTER 6 Modularity This chapter e
- Page 92 and 93: 6.2 Why modularity? 69 observed fau
- Page 94 and 95: Figure 6.1 Two alternative software
- Page 96 and 97: ■ a simple program is more likely
- Page 98 and 99: 6.6 Information hiding 75 The class
- Page 100 and 101: 6.8 ● Coupling 6.8 Coupling 77 We
- Page 102 and 103: 6. Method calls with parameters tha
- Page 104 and 105: 3. Temporal cohesion 6.9 Cohesion 8
- Page 106 and 107: > } public void setY(int newY) { y
- Page 108 and 109: • Exercises 6.1 What is modularit
- Page 110 and 111: CHAPTER 7 Structured programming Th
- Page 112 and 113: 7.2 Arguments against goto 89 If we
42 Chapter 4 ■ Requirements engineering<br />
describing what the system should do, but they will each be inclined to use a different<br />
language. The users will have a preference <strong>for</strong> non-technical descriptions expressed in<br />
natural language. Un<strong>for</strong>tunately, while natural language is excellent <strong>for</strong> poetry and love<br />
letters, it is a poor vehicle <strong>for</strong> achieving a precise, consistent and unambiguous specification.<br />
On the other hand, the analysts, being of a technical orientation, will probably<br />
want to use precise (perhaps mathematical) notation in order to specify a system. This<br />
brings us to the question of the notation.<br />
Several notations are available <strong>for</strong> writing specifications:<br />
■ in<strong>for</strong>mal, writing in natural language, used as clearly and carefully as possible. In<br />
this chapter we will concentrate on this approach.<br />
■ <strong>for</strong>mal, using mathematical notation, with rigor and conciseness. This approach is<br />
outside the scope of this book. Formal methods tend to be used only in safety critical<br />
systems.<br />
■ semi-<strong>for</strong>mal, using a combination of natural language together with various diagrammatic<br />
and tabular notations. Most of these notations have their origins in<br />
methods <strong>for</strong> software design, that is, in methods <strong>for</strong> the implementation of software.<br />
Thus there is a potential problem of including in<strong>for</strong>mation about the implementation.<br />
These notations are discussed later in this book and include pseudo-code, data<br />
flow diagrams and class diagrams.<br />
At the present time, most requirements specifications are written in natural language,<br />
assisted by use case diagrams.<br />
One approach is to draw up two documents:<br />
1. a requirements specification written primarily <strong>for</strong> users, describing the users’ view<br />
of the system and expressed in natural language. This is the substance of the contract<br />
between the users and the developers.<br />
2. a technical specification that is used primarily by developers, expressed in some<br />
more <strong>for</strong>mal notation and describing only a part of the in<strong>for</strong>mation in the full<br />
requirements specification.<br />
If this approach is adopted, there is then the problem of ensuring that the two documents<br />
are compatible.<br />
4.6 ● The structure of a specification<br />
Given that a requirements specification will usually be written in natural language, it is<br />
useful to plan the overall structure of the specification and to identify its component<br />
parts. We can also identify those ingredients that, perhaps, should not be included at<br />
all, because they are concerned with the implementation rather than the requirement.<br />
The remainder of this section presents one way of structuring specifications.<br />
One approach to giving a clear structure to a specification is to partition it into parts.<br />
<strong>Software</strong> essentially consists of the combination of data and actions. In specifications,
Change language