Ian Graham
Addison-Wesley, 1998.
Ian Graham
Addison-Wesley, 1998.
ISBN 0201360470 (boards)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Ian Graham, a well-known requirements engineer and speaker, has written a powerful and provocative book, obviously based on practical experience. For instance, he feels that the very worst object-oriented analysis comes from people who are thinking in terms of dataflows -- he believes that analysis has to be object-oriented to make much sense. He specially dislikes methods such as UML that purport to be object-oriented but don't do it well, no matter how attractively they are marketed.
For newcomers, the book offers the advantages of clarity, brevity, wit, and a logically-consistent notation and terminology. Its disadvantages are that many newcomers in industry will certainly see things done differently -- but as Graham would most probably argue, done worse. The book introduces the principles of encapsulation, enabling different parts of a system to be modified safely and independently, and inheritance, enabling behaviour to be defined just once, and used wherever needed.
Another strong strand is a practical preference for involving users in "rapid" or "joint" development. This is no mere prejudice in favour of quick-and-dirty coding: Graham argues convincingly for humane and fair user-centred projects, as well as for more formal semantics in object models. The key reasons for getting users inside projects are simple: to abolish the us-and-them barrier; and to ensure that systems are built to meet real user needs. Rapidity of feedback is also crucial. Workshops attended by users provide proof that a development is on track, and enable mistakes to be corrected before they become stuck in systems when time and money run out. Graham has no patience with the kind of project manager who actually aims to hoodwink users.
In workshops, users do need simple diagrams, and Graham concedes that they understand process flow better than static objects. This is not a reason for giving in to dataflow and inviting bad programmers to write 'flat C++': instead, it means that workshops should focus on goals and tasks performed by different classes of actor. All of these can become objects. Graham insists that diagrams should be created by the system, not hand-drawn, so his are always simple and show just one kind of relationship (such as state transition or task sequence). The reduced amount of meaning in any one diagram is compensated -- for tool owners -- by the ability to switch instantly between different diagram types, effectively allowing tool users to explore different 'dimensions' of a model.
Graham is equally at home with metrics, automatic generation of diagrams, rulesets, business process modelling, code generation, simulation, user workshops, design patterns, and reuse. There are many original proposals on all fronts.
The book is probably most suitable for practising requirements engineers. Beginners may find the use of examples a little sketchy, while a certain familiarity with industrial (or financial) practice and with object-oriented concepts is assumed. That said, requirements engineers will want to have their own copy of this vigorous book from a leading practitioner and theorist.
See also Ian Graham's Requirements Modelling and Specification for Service Oriented Architecture (2008).
© Ian Alexander 1998