Ian Graham
Wiley, 2008
Ian Graham
Wiley, 2008
ISBN 9780470775639
Buy it from Amazon.com
Buy it from Amazon.co.uk
It is 10 years since Ian Graham's last book, Requirements Engineering and Rapid Development. His new book builds on his expertise in specifying financial software with a wealth of new ideas and an unrivalled command of practical techniques for business.
Graham remains no less critical of the UML - its vagueness, its dodgy notations, use cases - but he has pragmatically adopted its better bits such as statecharts and class diagrams, which are after all not unique to UML anyway. For example, he suggests combining
"the use case notation along with UML stereotypes to create rich pictures à la Soft Systems Method. ... In this way, use cases can be used to represent much more of the requirements space." (page 107)
In other words, you extend the UML however you need to, to make it expressive enough for requirements work. You talk the enemy's language, but you express your own meanings. Graham is an exceptionally eclectic writer and practitioner. Apart from Checkland's SSM, he makes active use of Business Process Management (BPM) techniques and notations, both formal and informal. He was closely associated with the Catalysis method, so it is no surprise to find an informative chapter on "Catalysis Conversation Analysis".
"A conversation involves exactly two agents. A collaboration arises from multiple conversations and therefore may involve two or more agents. Like a conversation a collaboration has a stereotypical script and a goal." (page 155)
You can see that Graham is sharp, quick, and somewhat schoolmasterly: you are expected to be paying attention. Everything is explained very clearly, but it is said just once, and in terms of a whole set of concepts which are certainly not universal in the software world. In the sample just quoted, Graham is introducing some key Catalysis concepts. His point is that just capturing a script (or scenario, a sequence of actions) is not enough to define interactions between two or more conversations. He goes on to give the example of order processing, where there are two conversations: PlaceOrder and Enter&ValidateOrder. In themselves, these "fail dismally", but a diagram of the collaboration, where validation follows the placing of an order, with a loop back to try again if validation fails, "does so nicely".
Graham uses smiley face icons to denote "human agent", and a computer screen icon to denote "system" - he reserves his most withering scorn for the UML use case diagram notation which uses a confusingly ambiguous stickman icon to mean "agent, human or machine" when it is precisely the human involvement in conversations that is important.
Graham's examples are often to do with trading. This experience lends the book strength, as in the chapter on modelling large enterprises. Ordinary BPM (and indeed UML-style analysis) gets hopelessly bogged down in details,
"caught between the monster of procrastination and the whirlpool of slow progress".
He does not name the monsters as Scylla and Charybdis, but the classical reference to bold Odysseus is plain enough. The dangers in modelling large enterprises can be overcome by establishing a "mission grid" of top-level goals. From there, you can analyse each goal in detail, and attach business rules (constraints) in a proper context. Anyone familiar with military planning will be struck by the parallels: in both cases the activities of large numbers of people and machines are co-ordinated using a matrix which indexes a hierarchy of detailed lower-level descriptions of required activities by role, though the military matrix has time along one axis, so the 'synchronisation matrix' is a scenario rather than a goal representation like the mission grid.
All in all this is a fascinating book. There are not many software authors who could write a sentence like:
"All phenomenologists and dialecticians, whether idealist or materialist, acknowledge that the perception or apprehension of objects is an active process." (page 104)
There are not many, either, who can casually drop references to Kant, Hegel and even (Karl) Marx into their text without appearing pretentious or irrelevant. Graham's writing is direct and based on personal experience, however. The abbreviation for "Just Do It" is given as "(JFDI)" (page 73) - you will have to work out the acronym for yourself, but it isn't something that suggests a lofty philosophical attitude. Similarly, while the essential nature of the (class of) objects called Chair is discussed in abstract philosophical terms, one of the purposes given for the class is "(or perhaps for bar-room brawling)". Fairly practical philosophy, then.
Graham assumes a lot of his audience: not least, the intellectual ability to switch quickly from technical details to logical, mathematical and philosophical underpinnings. Beginners would find much of the discussion hard to follow (why does it matter that use cases and scenarios are both instances? Why is a scenario sometimes claimed to be a use case instance?).
There is invariably sound sense underneath the logic-chopping. It really is no good creating an extra use case for every real-world exception: the approved UML approach of creating a specialized use case to "extend" just one use case to provide an exception path is clearly madness, for in the real world the same exception - Graham humorously uses the example of slipping on a banana skin - can and does occur in many different concepts. Graham's suggestion is in fact highly pragmatic: only create one exception use case for "slipping", and - here is the clever technical suggestion - make it semantically coherent by saying you are "passing a message" to the exception use case. That way, argues Graham, you avoid the ridiculous multiplication of use cases, or as he might have said
entia non sunt multiplicanda praeter necessitatem,
"entities must not be multiplied beyond necessity" (Occam's Razor).
But all that the requirements analyst needs to know here is the rule (which the book does not state as such):
"create just one use case for each business-critical exception, and call it from each use case where that exception occurs";
the intellectual discussion throws more heat than light on the problem.
For data-handling activities, Graham suggests creating a single CRUD (Create, Read, Update, Delete) use case instead of four separate cases. This issue has in fact been hotly debated. While Graham is of course correct that using one CRUD case reduces the number of use cases by a factor of four, it also bunches together actions that have little to do with each other (violating the age-old principle of coherence: the stuff in a module should be on the same subject). On the other hand, the CRUD approach tells software designers what to do, with as little repetition as possible.
The book ranges over all three of the topics mentioned in its title: requirements, specification/modelling, and SOA, so you may find some parts of the book less familiar than others. Further, many techniques are just briefly named and recommended, rather than being explained and illustrated. This also applies to modelling notations: for instance, there is a UML Activity Diagram and a BPMN process diagram, but WS-BPEL / BPEL / Beeple is only discussed in abstract terms, including mentions of BPML and pi-calculus - in too little detail for the reader to be able to evaluate their worth, let alone apply them.
Requirements analysts - whether in the financial sector or not, business analysts, and software engineers alike will find much good advice and plenty to reflect on in this distinctive and informative book. Financial sector business analysts involved with SOA may find it a very useful guide. Beginners should not use this book as their first requirements text.
© Ian Alexander 2009
You may also like:
