Bill Wiley
Addison Wesley Longman, 1999
ISBN: 0201616068 (paper)
Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
First of all, it is encouraging to see a requirements book that is avowedly for systems rather than software. It may be true that all requirements techniques are applicable to different domains, but an emphasis on software tends to focus attention away from systems issues, such as project management, contracts, cost, estimation, large and complex projects, and so on. All of these in truth apply to software systems as well.
Wiley is from a practical background in aerospace and manufacturing, unusually also with experience in facilitation and research. He has evidently been heavily involved in project management, colouring his view of what system requirements engineering might be. The emphasis is on a functional view of systems, with dataflow diagrams, entity-relationship models, and then a welcome treatment of events. All this is related closely and practically to the issues faced daily by lead engineers and project managers. There is a surprisingly detailed account - more than 50 pages - of function point estimation, and a strong emphasis on real project work and contracts:
The combination of an event-driven system requirements definition methodology and function point analysis for project estimating can reduce the chances of contract litigation.
This sounds like the voice of experience, even if there is an unmistakable American echo in the threat of hordes of contract lawyers ever-present in the mind of the project manager.
A second statement in the introduction that is perhaps even closer to Wiley's credo is:
I believe that an event-driven strategy for software (sic) development provides a more intuitive, effective partitioning ... than ... object-oriented approaches.
This seems to be both a recognition that object-orientation is the obvious and fashionable way of specifying systems that must handle real-world events, and a Canute-like attempt to hold back the flooding tide. We can imagine a spectrum of approaches in system development ranging from pure structured analysis and waterfall lifecycles at the functional end, to pure use case analysis, reusable components and iterative development at the object-oriented end. Wiley seems to be quite a long way towards iterative life-cycles, is strongly in favour of events (and hence scenarios or use cases), but equally strongly attached to functional decomposition.
When the reader sees a table that relates business events, their sources and triggers to (system) event responses and system releases (e.g. Version 1), there is a clear impression of something modern, practical, and focused on the user. For instance, the customer places an order, which event triggers the filling of that order. This is an essential part of the system so must be delivered in release 1. What is not stated is which system object receives the message and fills the order. This halfway house may seem intuitive to Wiley but it does seem a curious compromise.
Part I of the book looks at Business Events and System Development, with a clear justification for spending time on requirements (from the Standish Report) and a sensible account of why events are important in system specification.
Part II discusses Event-Partitioned System Requirements, doing everything except conceding that events might be handled by objects.
Part III concentrates on Estimating Software (sic) Projects, mainly with function points though with a quick tour of other options.
Part IV finally admits that objects might exist, and deals with Object-Partitioned Response to Events in 20 pages of reflective if slightly sceptical discussion.
It is something of a miracle that in 250 pages Wiley does not mention either systems engineering or requirements engineering. Instead, he talks about methods, which he calls methodologies, and methodologies, which he calls perspectives. He is unclear whether the study of purpose, objectives, and scope is part of the analysis phase or precedes it. He treats requirements as part of the development effort, in effect forming a nonphysical, conceptual or logical model of the system. This may be thought to blur Jackson's World/Machine distinction somewhat, if not to presume that user requirements already exist in some form. This intuition is reinforced by a look in the index: the terms user requirement and stakeholder are nowhere to be found.
Many topics are handled very plainly from a practical perspective. The reader will find a sensible discussion of rapid iterative techniques such as Joint Application Workshops. Function point cost estimation is clearly explained, in enough detail (with tables for each factor) to enable readers to apply the technique in practice. Readers wanting to try their hand at Dataflow Diagrams, Entity-Relationship Models, and Pseudocode to specify system behaviour will find a short crisp account here, with plenty of practical tips. Leffingwell and Widrig would undoubtedly cringe.
The bibliography is like the book industrial not academic. There is an efficient index and a serviceable if textbook-stiff glossary.
This book is aimed at requirements engineers working on system projects. Those who want a simple introduction to event-driven methods without going all the way to object-orientation, and who may be interested in estimating cost at the requirements stage may find it a useful and practical guide.
© Ian Alexander 2000
You may also like:
