Wiley Telling Stories: A Short Path to Writing Better Software Requirements 978-0-470-43700-1 Manuale Utente
Codici prodotto
978-0-470-43700-1
Telling Stories
5
about your technology environment, business, industry, economic con‑
ditions, or any other general background information that might be
useful. You probably don’t need a lot about the setting in a requirements
document, but a paragraph or two in the executive summary can be
very helpful.
Plot:
ditions, or any other general background information that might be
useful. You probably don’t need a lot about the setting in a requirements
document, but a paragraph or two in the executive summary can be
very helpful.
Plot:
•
The series of processes that occur in the current and future system
are the plot of your requirements document. Like the plot in a story,
the events happen in a certain order and the outcome of each affects the
later ones. They are what make you eagerly turn pages.
Characters:
the events happen in a certain order and the outcome of each affects the
later ones. They are what make you eagerly turn pages.
Characters:
•
There are many types of characters in a requirements docu‑
ment: some are people, some are machines or programs. Any entity
capable of action can be a character in a requirements document.
Point of view:
capable of action can be a character in a requirements document.
Point of view:
•
It can be very useful to take different points of view as you
describe different processes, or the same process. Your ultimate goal is
to provide an omniscient view that faithfully describes everything that
happens and what everyone needs. But along the way, it could make
sense to explain an order process from both the customer and the order‑
taker point of view, for example.
to provide an omniscient view that faithfully describes everything that
happens and what everyone needs. But along the way, it could make
sense to explain an order process from both the customer and the order‑
taker point of view, for example.
If we learn best from stories, and if story elements are analogous to elements
of a software requirements document, how do we put this idea into practice
and make a better requirements document? First, I have to clarify what I mean
by software requirements document.
and make a better requirements document? First, I have to clarify what I mean
by software requirements document.
What Are Software Requirements, and
Who Are They For?
Who Are They For?
A software requirements document explains a business problem and the
requirements of a software solution from a user and a business perspective. It
is precise and detailed so that engineers can figure out what to build and how
to evaluate what they produce. It uses common language that the business
users and managers on the project can understand. You won’t know if the
requirements are right unless the needers tell you so, and they can’t tell you
if they can’t understand the document.
requirements of a software solution from a user and a business perspective. It
is precise and detailed so that engineers can figure out what to build and how
to evaluate what they produce. It uses common language that the business
users and managers on the project can understand. You won’t know if the
requirements are right unless the needers tell you so, and they can’t tell you
if they can’t understand the document.
Here are some qualities of effective requirements:
A requirements document states
•
what is needed from a system in precise,
measurable, and testable terms.
37001c01.indd 5
1/29/09 10:50:40 PM