Author: R. J. Wieringa
John Wiley, 1996
Author: R. J. Wieringa
John Wiley, 1996
ISBN 0471958840 (paper)
February 2000 (may be out of print but available from Amazon resellers)
Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
This is a well-written and highly readable book: Wieringa possesses the same clarity, intelligence, and good humour as his Dutch academic colleague Andy Tanenbaum.
Just what, though, is requirements engineering? Evidently its meanings cover topics as different as systems analysis (JSD, dataflow, and entity-relationship models) and requirements capture from end-users. Interestingly, Wieringa describes the system life-cycle as beginning with "Needs Analysis" (immediately after the contractual phase). But surely analysis must follow on from something, namely the gathering of needs in the first place? It is a limited view of the world that sees everything as starting with analysis and proceeding to design: users have many views of what might be useful. The transformation of a mass of unsystematic material into something which users can agree that they want, and which could possibly be analysed, is requirements engineering writ large. That process is, in a way, discussed here, but it is not named as such, so the concepts remain rather woolly. Requirements capture, for instance, is mentioned in the cover blurb but not in the index! Similarly, the need to obtain agreement among users is mentioned, but without any suggestion of how.
Even so, few pages are devoted to needs analysis: most of the text focuses on alternative ways of building models of systems. Even that is far from complete because the author has chosen to exclude object-oriented requirements analysis: it will be the subject of a companion volume, so the current book avoids the problem of trying to show how to identify (design) objects before the user requirements are known. However, the preface makes clear that object-orientation is seen as too new and fashionable to be accepted lock, stock and barrel: progress is said to depend on re-evaluation of older ideas, not on simply replacing them.
Wieringa does break one of his own rules by not making clear just who the book is intended for - the preface hints at a student audience, possibly also practitioners. This begs the question of who is supposed to be doing requirements engineering in the first place: users or developers? Without such a focus, the book inevitably straggles into many areas of software and systems engineering, in particular covering development methods such as JSD and Entity-Relationships which frankly are not very relevant to requirements as understood by end-users.
The author sometimes makes odd decisions. For example, having acknowledged that "in software engineering, software product properties are often called attributes" the text continues "we will not use this terminology because the term 'attribute' is used in Entity-Relationship models..." (to describe entities). This, while true, is hardly likely to confuse, and the treatment of reliability, portability and so on as system attributes (qualifying system requirements) is both useful and well established.
I think it is a fair criticism of this text that it is distinctly academic; I am unsure whether the author would consider this a mere statement of fact or even as praise. For a text constructed so carefully (almost 400 listed references) it is very easy to pick up and read, and in places such as the comparison of software development with the design of new packaging for 'TANA' shoe polish, almost funny. It is less clear that the book will be directly helpful to practitioners, though the discussion of the inter-relationships of methods (for example Figure 14.4) is original and worth detailed study.
The book is generally very well presented, though the tables (p360 ff) contain awkwardly narrow columns with hiccupy labels such as 'Soft-/ware ar-/chitec-/ture de-/sign' which should really have been done better (perhaps by abbreviating or by writing vertically).
That said, there is much worth reflecting upon here, and requirements engineers both in organizations procuring software, and in those developing it, should at least find Wieringa useful as a reference. It will be interesting to see the object-oriented companion volume.
© Ian Alexander 1996