Datasheet

Telling Stories
12
often produce far more than is necessary, agonizing for months, producing
phone‑book‑length documents and wall‑sized diagrams, and then wondering
why their requirements aren’t met.
Not surprisingly, many become disillusioned with the requirements process.
I don’t believe this is because writing requirements is an inherently flawed
exercise. I think that the wrong people have been forced to do the work, they
haven’t been adequately trained or supported, and they usually waste a lot of
effort working on the wrong content. People hate writing requirements when
they do too much work and produce complex and confusing material.
A simple and flexible storytelling process can be satisfying and adaptable
to a wide range of small and large efforts. This approach is even compatible
with most of the latest methods of software development, including Agile,
Extreme, and others.
I’ll explain later who I think should be writing requirements. Now I’ll get
into how telling stories applies directly to the requirements process.
Can Stories Get Us Back on Track?
Perhaps while exploring many useful ways of representing software systems
for engineers, Structured Analysis and other modern methods have become
too abstract and moved away from how people ordinarily learn and commu‑
nicate—too far away from storytelling. Storytelling is something everyone
understands intuitively, immediately improving the process of gathering infor‑
mation and structuring the requirements document.
When you tell a story, you instinctively transform abstract knowledge into
a logical structure. Whether writing or reading a story, you quickly get bored
when you get into material that isn’t interesting. You also can tell immediately
when something sounds wrong, even if you haven’t heard the story before.
You get this very sophisticated validation process for free, without having
to teach anything to anybody. Your mind is so well suited to stories that it
almost automatically eliminates superfluous content and keeps you on the
right subject. This quality of stories is especially useful when explaining very
complex systems.
Let me tell another story to show how this works. When I switched from
writing about software that regular people use to do everyday tasks, to writ‑
ing about a credit risk system at an investment bank, I floundered for several
days. The hardest part was that I couldn’t see or use the system. All I could do
was look at reports it produced and talk to the development manager, and he
37001c01.indd 12 1/29/09 10:50:41 PM