You may also like:
Ben Rinzler
Wiley, 2009
ISBN 0470437006 (paper, 160 pages)
Buy it from Amazon.com
Buy it from Amazon.co.uk
There is a book by a man from the software industry. He is earnest, educated. He wants to cut through the complexity that is much of the software engineering literature. He believes that requirements are fundamentally simple things:
Of the few references in the book, the first is Tom DeMarco's Structured Analysis and System Specification, on page 9. It's telling because of the age of that reference (which, oddly, is not given): 1975. Rinzler's prescription for writing requirements follows DeMarco's early approach: nearly all the diagrams in the book, barring one use case diagram, are dataflow diagrams (DFDs). It might have been just fine in '79; DeMarco himself wouldn't do it now.
Curiously for a book about stories, Rinzler does not emphasize story-telling as such, nor its engineering equivalents, scenarios and use cases. Instead, he relies on the narrative structure that is inherent in dataflows - or flowcharts: the sequence of activities that is diagrammed. Then:
My "story" approach takes simplified versions of the most basic Structured Analysis tools and puts them in a narrative structure that explains itself as it goes along. There's no need for a separate "How to read a story" section. (page 14)
Much is assumed here. Writing things simply and clearly is not easy. Arriving at "the basic purpose" of a piece of software - its mission, its top-level goal - isn't easy either. Clarity does not come purely from care with grammar and style ("Clear, precise words; Clear, short sentences; Clear, short paragraphs") but from a well thought out project dictionary, systematically documented assumptions, properly analysed goals, and so on. For those things, you need some insight into techniques for Discovering Requirements.
Clearly Rinzler is writing from his experience of working with business analysts on commercial or financial software. In that context, a mention of various styles of flowcharting (BPEL etc) would have been nice, along with a recognition that there are other kinds of software, where other approaches may be necessary. UML is largely dismissed as not suitable - with some justification, though perhaps somewhat too sweepingly: only activity diagrams get a grudging acceptance, which is odd, because flowcharts are close to the essence of process modelling.
The template, offered at several levels of elaboration (from very short and simple upwards) rings the changes on Summary, Future State, Gap Analysis, and the Requirements themselves. This too bespeaks Business Analysis, where almost all the problem is to identify the functions and business rules that apply.
If you are looking for a short and simple book on requirements, you have several to choose from:
| Title | Intended Audience | Approach | Type of Project |
|---|---|---|---|
| Telling Stories | Business analysts | uses dataflow diagrams to organise traditional requirements as easily-understood stories; simple document template | (In-house) Business Software |
| Writing Better Requirements | Anyone defining requirements, e.g. the client of a software house | uses scenarios to organise traditional requirements as easily-understood stories; simple document template | System and Software Products |
| Just Enough Requirements Management | Software developers, whether in-house, for a client or for the mass market (these different scenarios are carefully compared) | the minimum of prototyping, prioritisation (triage), risk analysis, requirements writing | Software, both In-house and Products |
| Customer-Centered Products | Managers, in any business that needs to define requirements | lively, often funny, business-like; argues for defining scope, interfaces, requirements, rationale, traces, verification criteria | System and Software Products |
In short, if you are a beginning business analyst and want a minimalist book on requirements, Rinzler may be for you.
© Ian Alexander 2009 You may also like: