Wiley Telling Stories: A Short Path to Writing Better Software Requirements 978-0-470-43700-1 Manual De Usuario
Los códigos de productos
978-0-470-43700-1
Telling Stories
4
Why Do We Learn Better From Stories?
I wouldn’t need to explain this to Aesop, the mythical author of Aesop’s Fables.
When he wanted to encourage savings, he didn’t lecture on the dangers of
poverty, he made up the story of the ant and the grasshopper. There are stories
to everything, and our brains are built to listen to them.
When he wanted to encourage savings, he didn’t lecture on the dangers of
poverty, he made up the story of the ant and the grasshopper. There are stories
to everything, and our brains are built to listen to them.
Listening to a story makes us experience everything we hear as if we were
part of the action. We relate to each event and fill in any details that might
be left out. We are able to evaluate and remember each piece of information
because it is part of a logical and realistic whole that we validate against our
own experience. We compare the story to what we know and if it is believable
and the information is important to us, we find it compelling in a way that a
simple recitation of the same information could never be.
be left out. We are able to evaluate and remember each piece of information
because it is part of a logical and realistic whole that we validate against our
own experience. We compare the story to what we know and if it is believable
and the information is important to us, we find it compelling in a way that a
simple recitation of the same information could never be.
Admittedly, the story of making or changing most software systems is not
that interesting, but if you do your best to relate what the system does to an
understandable narrative, it will be much more compelling. In particular, if
you emphasize the main problem the project aims to solve and carry it through
every stage of your work, it can bring life to detailed requirements and make
readers pay attention to information that might otherwise be tedious.
understandable narrative, it will be much more compelling. In particular, if
you emphasize the main problem the project aims to solve and carry it through
every stage of your work, it can bring life to detailed requirements and make
readers pay attention to information that might otherwise be tedious.
How Do Story Elements Relate to Requirements?
You may remember from your English classes (if you took any) that a story
has setting, conflict, characters, plot, point of view, and theme. Let’s go
through these and explore how each is analogous to a part of the require‑
ments process:
has setting, conflict, characters, plot, point of view, and theme. Let’s go
through these and explore how each is analogous to a part of the require‑
ments process:
Conflict:
•
The basic problem that you are hoping to solve is the central
conflict to resolve in the requirements process. We don’t often think of
a lack of technology as a conflict, but it is a conflict between an old way
of working and a new and better way in the future (we hope).
Theme:
a lack of technology as a conflict, but it is a conflict between an old way
of working and a new and better way in the future (we hope).
Theme:
•
The theme is the central concept underlying the solution in
your document. Viewed another way, a theme can be a very big require‑
ment, such as the general need for an automated way of validating data
in your system.
Setting:
ment, such as the general need for an automated way of validating data
in your system.
Setting:
•
A setting is the place and time of the story. In a requirements
document, it is important to explain the broader context of the problem
you are trying to solve. This could include some general information
you are trying to solve. This could include some general information
37001c01.indd 4
1/29/09 10:50:40 PM