New Version
Søren Lauesen
Buy it from Amazon.com
|
Original Version
Sψren Lauesen
|
| The fully-revised version now published by Addison-Wesley is substantially larger, more elegantly presented, completely in English, and of course available to a far wider audience. It also takes in recent developments in engineering thinking and in Prof. Lauesen's own work. | The original version was in English with examples in English and Danish, and the review below talks about that version. However most of it also applies to the new version. |
Despite its title, this book discusses requirements in general, and most of it could perhaps have been called system requirements. It is quite distinctive in its approach, which combines industrial and academic experience. Most interesting are the real extracts from requirement specifications which form about 40% of the book.
The most original feature of the book is the idea of requirement "styles" mentioned in the subtitle. These are basically templates for individual requirements: for instance, the Feature style applies to "functional product properties described in plain text". An example is
R1: The product shall be able to record that a room is occupied for maintenance in a specified period.
The Feature style is a plain text description of a capability or function, though Lauesen says that these could be described in other styles too, for instance as a dataflow diagram.
Similarly, the Performance style is for a performance constraint. More distinctive, perhaps, are Defect and Subjective styles, which Lauesen suggests might be good for usability requirements:
R2: On average, a novice user shall encounter less than 0.2 serious usability defects when ...
R4: 80% of users shall find the system easy to learn ...
The issues around writing requirements in each style are discussed in terms of the risks to the customer and to the developer.
The book covers many basic topics effectively, and has a welcome amount of coverage on goals, tasks, issues, and use cases. Elicitation is rightly seen as something that not only involves many possible techniques ranging from interviewing to QFD but also that can be used to provide anything from a description of present work and problems to conflict resolution and completeness checks.
The table (illustrated) comparing elicitation techniques is a rich source of knowledge and reflection for practising engineers.
The book is not, and does not aim to be, a general textbook on Requirements Engineering. Instead, it seeks to introduce students whether undergraduates studying for degrees, or system engineers on short training courses to a range of practical techniques.
As Lauesen remarks, the book tries to "teach you many techniques, and advise you on when to use them and when not." The inherent danger in this approach is that it tends to present a subject as a maze of tangled paths and pitfalls. Dataflow, for instance, may not a good way of organizing requirements, but it is described nonetheless. Dataflow is rightly criticised in the book, since it either prejudges the software design (should a function become a module?) or makes tracing difficult when the functional decomposition fails to match the design decomposition. Guidance for beginning practitioners is thus weakened.
The book's origins influence it in many ways. Most noticeably, the presentation is a simple A4 format, with the 'slide' figures usually on the right hand page facing the text. Teachers are advised to spend "5 to 30 minutes on a single slide" with their students. This is quite a neat way to arrange study notes, but it results in large areas of white space. Perhaps for the same reason, there is no index or glossary. Helps are reduced to a single well-chosen page of bibliographic 'literature' which sketches the coverage of each of the referenced texts. There are exercises at the end of each chapter, but no answers are provided.
Lecturers and trainers faced with the same task as Professor Lauesen - to introduce groups of students to practical Requirements Engineering may well find this a useful and likeable sourcebook. I would not expect many courses to use the book directly. However, there is much original thinking here, as well as an experienced teacher's careful classification of ideas and explanation of terms.
Practitioners and researchers may be most interested in the real-life examples which "have rarely been published." Lauesen discusses the reasons for this, including confidentiality, the difficulty of obtaining clearance, or that "the parties are somewhat ashamed of the specification style". As it is so unusual to see such examples, let us briefly review and compare them.
The first example is a 50-page specification for a business system for a Danish shipyard, carefully translated into English. It is complete except for the installation and contractual details. The requirements are unnumbered, relying bizarrely instead on page and line numbers. For example:
5.2.2.1.1 Debtor Managementthe debtor management system shall have the following functions:
[Line 15] a) Data entry function for payments received and made in addition to invoicing made outside the contract system.
This approach cannot have made traceability easy.
The second example is "16 selected pages out of about 110" of the requirements for a public health administration system prepared by Deloitte and Touche however did Lauesen get their consent? The requirements are untouched, which means they are in Danish, limiting readership to those of us who have at least some knowledge of related germanic languages. The author claims that "The selected pages are a fair representation of the full spec. The full spec is just 'more of the same'." This claim is of course impossible to judge, without privileged access. The example contains the unforgettable requirement (I translate):
The proposal shall be written in Danish.
The requirements in this example are mostly written in a remarkably familiar "Systemet skal ..." idiom; they are numbered from 1 to 674 and have integer weights, e.g. (I translate):
56. It shall be possible to record free [usage of] telephone (company sponsored telephone, a taxation issue). (Weight: 2)
The third example is 4 selected pages out of about 20, for a noise source location system from Bruel and Kjær. This is in English supported by importance attributes, for instance:
R-44 +++ It must be possible to repeat the measurement of a point at any time.
The requirements are set in context by three levels of headings and explanatory text before each item. The account is as fresh and direct as Lauesen's textbook.
Plainly there could be many fascinating comparisons of these intriguingly diverse examples.
© Ian Alexander 1999-2001
See also Lauesen's excellent User Interface Design
(2004)
and his practical Guide to Requirements (with free
Template) (2008)
