Datasheet

Telling Stories
14
the strongest proponents of Structured Analysis (including Tom DeMarco him‑
self, writing in Structured Analysis and System Specification) touted its advan‑
tages over what they called “narrative prose” analysis documents. I don’t know
exactly what they meant by that, but I can guess that they were criticizing the
long, rambling documents I’ve seen that have a lot of text and no meaning‑
ful structure or systematic methodology. Brain dump is a more common and
perhaps better term for documents like this.
Interestingly, near the end of Structured Analysis, DeMarco includes instruc‑
tions for what he calls “packaging” the results of structured analysis. He
doesn’t call for any summary or narrative content to tie it all together. He does
recommend including a guide to Structured Analysis that explains how all the
tools work. He acknowledges that the methods of Structured Analysis will be
new to many people. Instead of narrative about the content of the work itself,
we get narrative about the tools. I don’t think users reviewing requirements
really want to know anything about Structured Analysis. This reminds me
of those “How to use this book” sections I always find amusing. “Begin with
Chapter 1 and turn each page to the left to proceed. Bold type means the
content is important!” If a book needs a “How to use this book” section to be
understood, it has already failed.
There is a middle ground, however, between rambling, unstructured “nar‑
rative” and nonnarrative collections of diagrams, specifications, and data
dictionaries that only those who know Structured Analysis can understand.
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.
One key advantage of Structured Analysis, according to its authors, was
that parts could stand on their own, be distributed for review independently,
created out of order, and didn’t have to be read as a monolithic phone book.
The parts of a good narrative document can also be created out of order and
read on their own. In fact, I recommend starting with data flow diagrams. A
bit of narrative content that explains how a diagram fits into the overall system
makes it more capable of being understood on its own, not less. It’s very easy
for readers to skim or skip around in a well‑structured document in which
every section explains how it fits into the whole. One of the biggest problems
I’ve observed when analysts distribute parts of their “nonnarrative” work is
they leave off meaningful titles and there is not a brief summary that explains
the basic purpose of the current part.
37001c01.indd 14 1/29/09 10:50:41 PM