Datasheet

Telling Stories
7
someone told you to go write “business” requirements, “software” require‑
ments, or any other type.
I have often heard “business” requirements defined as requirements written
by a nontechnical “business‑side” group and then delivered to a “technical”
group that analyzes them and then devises “software” requirements that are
more technical and detailed. But I have also heard “business” requirements
used to describe all types of nontechnical requirements.
I don’t think dividing requirements into many categories is a very useful
exercise. Using the approach I recommend, distinctions aren’t really important.
When gathering requirements, it can help to think of meaningful categories
that remind people of what they might have overlooked. These categories are
usually more specific than abstract terms such as “software” and “business.”
Think about performance requirements, data requirements, usability require‑
ments, availability requirements, or any other category that is meaningful to
your project. I’ll make more specific suggestions when I discuss gathering
content. I think it’s best to focus on telling the main story of the system; every
type of requirement will come up along the way.
Why Projects Collapse
(Without Detailed Requirements)
To understand how a project can break down without effective written require‑
ments, let’s take a look at a fictional, but very typical story.
When starting a project to make a new order processing system, the mak‑
ers and needers of the software have a few meetings. The makers listen to the
basic ideas of what the needers want and very quickly get into talking among
themselves about how they are going to build something to satisfy the need‑
ers. The needers can’t follow the discussion, but try to participate by smiling
and nodding.
After retreating to their offices, the makers present the needers with some‑
thing in writing about what they are going to do and ask the needers to approve
it. They call it a requirements document, but it says more about how the mak‑
ers are going to do their work than the details of what they are making. There
are considerable details about costs and resources and schedules, but nothing
clear about things such as how to apply the discount rate for preferred custom‑
ers and whether a customer profile can be altered from the transaction entry
screen by users without customer service entitlements.
37001c01.indd 7 1/29/09 10:50:41 PM