Benjamin L. Kovitz
Manning 1999
Benjamin L. Kovitz
Manning 1999
ISBN 1884777597
Buy it from Amazon.com
Buy it from Amazon.co.uk
In this strongly individualistic book on engineering requirements, Kovitz limits himself to software (as opposed to systems), and stresses style (as opposed, perhaps, to structure). He does a good job of keeping to, and meeting, his goals, but omitting a clear account of process is an obvious weak point in any book about a process such as RE. Kovitz has implicitly to answer the challenge: what is your process? A book such as the Robertsons' Mastering the Requirements Process might provide an answer.
He does, in fact, devote a chapter in the middle of the book (chapter 7) to the software development process (though he avoids the p-word in favour of talking about a 'division of cognitive labor'). He carefully maps tasks such as analysis and user-interface design to documents such as requirements and interfaces, and then in turn maps these to principal audiences. To some extent this focus on products sidesteps the question of process: Kovitz effectively challenges the reader to select any development approach that includes the tasks he mentions, and which communicates their results adequately.
Even this brief glimpse of Kovitz' approach may be enough to hint at where he is coming from, and the suspicion is confirmed by the cover blurb: "he has worked as programmer, tester, system analyst, user-interface designer, and technical writer". This bespeaks an impressive personal knowledge, but perhaps specifically not a process view, and maybe especially not a systems view. Kovitz aims at and achieves great clarity of human communication with other engineers, just as in his user-interface work -- and there are excellent UI examples in the book, including a fully-worked Bug Log which, as he says, 'interfaces only to people' -- he certainly helped systems to communicate with their users.
Kovitz is extremely readable: in fact, you can even relax with his book and laugh with him at pieces of Jargon (section 12.5) and Small Details (chapter 15, as entertaining as all those books on Plain Words, and more relevant). Among the jargon-words that he picks on, what are Non-functional Requirements -- perhaps requirements that don't work? As for Requirements Specification, it's at best a tautology, at worst a contradiction in terms.
He is also the most quotable writer on systems engineering so far published. It is with a mixture of pain and the pleasure of recognition that we read that
'a sprawl of Use Cases is a terrible problem frame'
-- perhaps a neatly-organised set of levelled Use Case Diagrams would be better -- or that
'many requirements documents .. double their size by including software requirements that are identical to the user requirements, with just the wording changed'.
Readers may not agree with his prescriptions -- Jackson's Problem Frames, for instance, which he believes can sufficiently constrain problems, if carefully chosen. He is in fact an excellent source for people who want to get to know about techniques including both Jackson (tree) diagrams and Problem Frames -- in fact, Kovitz is referenced in Jackson's own book on the latter subject.
But he is both convincing and a pleasure to read when he argues against those standards writers who unrealistically demand that all paragraphs shall consist of exactly three sentences, or that sentences that end with prepositions are something we must not put up with. Standards, like all rules, are made to be broken:
'Many software companies routinely cut the corners described below, yet they are still in business and have satisfied customers'
In short, Kovitz has written a fresh, lively, honest, funny, and provocative book on a serious engineering topic -- not an easy thing to do.
Kovitz views requirements as communications between humans, and rightly stresses the value of clear, readable documents. This is not the whole story, though: requirements evolve and status changes throughout a project. Requirements therefore need to be instrumented with attributes to record their current status, whether or not the project chooses to use a requirements tool. Kovitz is curiously silent on this point, though he carefully and expertly explains how to define attributes of the system to be built. The book is to be praised for including fully-worked examples. These sensibly define not just the requirements but the users, events and terms used. They go so far as to indicate likely changes, but fall short of showing how change would be handled during the project.
Despite the excellent advice and examples, the beginning requirements engineer may not be entirely clear what to do at each stage, as the book does not emphasize process particularly strongly. However, the Small Details chapter includes perfectly serviceable templates, to the extent of recommending page layouts.
Kovitz' book will quickly become essential background (and possibly foreground) reading for would-be and practising systems engineers.
© Ian Alexander 1999 - 2001
You may also like:
