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
3
If you’re clear and precise, you’ll probably get what you want. If there is any
problem when the thing is done, you have a record of what you asked for and
a credible basis for requesting corrections or improvements.
problem when the thing is done, you have a record of what you asked for and
a credible basis for requesting corrections or improvements.
When you want something complicated, you must write a more detailed
requirements document. And when you’re explaining not only your own needs,
but also the needs of a group, you must find a way to include the group of
needers in your process and systematically find out what they want. (God
didn’t have this issue. He knew what he wanted in an ark and didn’t have to
reach consensus.) Once you’ve written something, you have to check back
with the needers to make sure you are correctly expressing their needs. If
the needers can’t make sense of what you’ve written, they can’t tell you if you
got it right.
but also the needs of a group, you must find a way to include the group of
needers in your process and systematically find out what they want. (God
didn’t have this issue. He knew what he wanted in an ark and didn’t have to
reach consensus.) Once you’ve written something, you have to check back
with the needers to make sure you are correctly expressing their needs. If
the needers can’t make sense of what you’ve written, they can’t tell you if you
got it right.
Just as God does with Noah, we do better if we explain what we want in
plain language and a clear and logical sequence. We do better when we tell
a story.
a story.
This book explains how to write a software requirements document using
storytelling, the most ancient and human means for sharing information. I
know you can’t make a software requirements document into a story as excit‑
ing as Noah’s Ark or Huckleberry Finn. But you can make a narrative that is
engaging and easy to follow for the people who have an interest in solving
the problem at hand. In the narrative, the problem should be clearly stated
at the beginning, and all points should lead to the solution, with each point
following from one to the next in a logical sequence of dependent outcomes.
It also helps if you use a lot of pictures.
know you can’t make a software requirements document into a story as excit‑
ing as Noah’s Ark or Huckleberry Finn. But you can make a narrative that is
engaging and easy to follow for the people who have an interest in solving
the problem at hand. In the narrative, the problem should be clearly stated
at the beginning, and all points should lead to the solution, with each point
following from one to the next in a logical sequence of dependent outcomes.
It also helps if you use a lot of pictures.
When you need something pretty ordinary that people have been making
for a long time, like a chair or a hamburger, you don’t usually have to explain
what you want in much detail. There are perhaps a few variables you need to
specify (with cheese, no fries, medium rare). It’s more challenging when you
need something complicated and specialized such as a new software system.
what you want in much detail. There are perhaps a few variables you need to
specify (with cheese, no fries, medium rare). It’s more challenging when you
need something complicated and specialized such as a new software system.
Only very skilled and specialized engineers make software, and they have
gone to special schools to learn new languages and tools (Java, C#, and so
on). These engineers mostly communicate with each other about what they
make, using all the special words from these new languages, and pretty soon
ordinary people can’t understand them very well.
on). These engineers mostly communicate with each other about what they
make, using all the special words from these new languages, and pretty soon
ordinary people can’t understand them very well.
The challenge when trying to write a story about what you want software
to do is to make it understandable to two groups that communicate in very
different ways: the needers of the software and engineers who make it. If both
groups do not understand and approve of your story, it will fail.
different ways: the needers of the software and engineers who make it. If both
groups do not understand and approve of your story, it will fail.
37001c01.indd 3
1/29/09 10:50:40 PM