Haim Kilov
Prentice Hall, 1998
ISBN: 0130798444 (boards)
Haim Kilov
Prentice Hall, 1998
ISBN: 0130798444 (boards)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Einkaufen von Amazon.de
Disponible chez Amazon.fr
Kilov has managed what one might have thought was by now impossible: to offer a completely fresh take on Requirements Engineering. He has in the process penned a likeable, charming and in places even funny book, full of rather good quotes from literature and computer science.
The grand old men of computing are here: von Neumann, Turing, Wirth, Dijkstra, Hoare, Parnas, Goguen; perhaps Jackson's absence is surprising. More unlikely heroes include Adam Smith the capitalist, Wittgenstein ("Only in the context of a proposition has a name meaning"), and Lewis Carroll -- but then Carroll was a playful mathematician and logician, and so in a way is Kilov.
If there is another Requirements Engineering book at all like this one, it is Graham's determined assault on the bastions of UML. It is not that Kilov exactly attacks any particular camp; rather that he plainly belongs neither to the functional analysis/dataflow modelling/structured requirements sect ("data doesn't flow") nor to the object-oriented creed ("too early for components").
The reader gets the feeling that there is much good work here -- and Kilov's own practice in the financial world is evidently successful; yet there is sparse contact with the outside world's dominant paradigms -- lots of shalls, or lots of UML. Of all the existing approaches with which readers may be familiar, only formal specification in the shape of Z, and strict rules in the shape of RM-ODP (a crisp standard for specifying open distributed processing, but perhaps far more widely applicable) are applauded.
The book seems to set out to persuade: "The teaching of business specifications -- in the same way as the teaching of programming -- is the teaching of thinking." Is this Dijkstra or Kilov speaking? Perhaps both. The reader is shown a paradigm with a respectable intellectual pedigree yet far from most current practice. Is Kilov trying to convert us to using precise specifications and to a new notation? Disclaimers about the unimportance of symbols notwithstanding, people react at once to pages of diagrams drawn in unfamiliar notations.
The modelling approach that most resembles Kilov's is entity-relationship modelling, as used especially in the database world. This is largely static: it describes structure but not explicit behaviour. Kilov goes further, by describing the components of decisions, rules, and business operations in structural terms. For example, the total amount of money in two accounts is the same (is invariant, another key word) before and after a transfer between them. So the operation must -- but Kilov shies away from specifying requirements in terms of operations, at least at first. This is in marked contrast to the rising popularity of scenarios and use cases, which are fundamentally operational.
Some aspects of the Kilov notation are easy and comfortable: a customer is exclusively subtyped into either a payee or a payer; a contract is composed of an environment and some preconditions. For compactness, the relationships are shown as little triangles on the lines between the 'things': for instance CA means Composition Assembly, D means Dependency, Ref means Reference. The direction is indicated rather neatly by routing the line from the source thing to the point of the triangle; one or several lines can come out of the base of the triangle. Less comfortably, perhaps, there is no implicit direction in the diagrams, so the triangles can be on their sides or even upside down -- and the visual flow can be from right to left, bottom to top, or in several directions at once. This is perfectly logical, but if it is true that out there in industry people read all diagrams as old-fashioned control flows starting at top left, then it may be a while before everyone is using Kilov diagrams for their precise specifications. What is more, if people read the triangle as an arrowhead, it goes the wrong way.
There are in reality two quite separate issues here: notation, and precision. In practice, the two are harder to separate. Even confining the problem to precision, we can observe that very few practitioners today attempt to make their requirements formally precise, and as few stakeholders ask them to. As Kilov rightly observes on page 2,
"Most -- if not all -- observations made by Dijkstra, Hoare, and others then for programming, with a special emphasis on simplicity and elegance, are valid (and often reinvented) now for analysis."
Words like elegance form something of a private language of approval; on the other side of the coin, pet hates include using the code as its own specification: "it does what it does" may be the ultimate business specification put-down. The arguments for precision are quite powerful, just as they are in programming; yet code is still often cut from natural-language specifications.
The book is a pleasant surprise in many ways. For instance, one might expect a book on business specifications to cover only domain modelling or user requirements. But Kilov pays careful attention to traceability and the handover to system specification. Similarly, Kilov says that the book will not cover people techniques such as interviewing and workshops, but there is plenty of advice on people-related issues such as managing different viewpoints:
"names should be identical to the ones used by customers -- and synonyms and homonyms should be permitted since they are used in the business. Never try to determine the only correct name: there is none since viewpoints and contexts will continue to exist."
Advice like this is wonderfully liberating, and applies in all Requirements Engineering contexts. There is plenty more of it in the book, all worth absorbing slowly and reflectively.
This book "is part of a continuing effort by the author to contribute to the improvement of systems development processes" says George Lieberman in the Foreword. As such it is presumably aimed primarily at thinkers -- researchers and gurus -- who shape system life-cycle models, and secondarily at practitioners, who after all generally have to do what they are told. It is not a book for beginners, though advanced students familiar with more conventional approaches may find it stimulating. Practitioners in the financial world who may have heard of Kilov could also find the book rewarding. Ultimately, the book will prove a success if it influences thinking in our field in the direction of greater precision. Perhaps that shift is long overdue.
A footnote in 2002: Kilov has now apparently abandoned the attempt at propagating his notation, and seems to be reframing his approach within the ever-spreading branches of the UML, if his article in a Cutter report 'Anticipating the Market: The Value of Business Models' is anything to go by.
© Ian Alexander 2000, 2002