Datasheet

Telling Stories
6
A requirements document details the way a system interacts with the
•
elements around it.
A requirements document uses plain language understandable to soft‑
•
ware users and engineers alike.
There are some very common wrong ideas and misconceptions about
requirements documents:
A requirements document does not explain
•
how a system is built.
A requirements document does not describe the technology used to
•
make a system.
A requirements document does not detail the schedule, plans, costs, or
•
resources required to make the system.
Beyond its immediate utility to the needers of the software and the engineers
making it, a requirements document has many secondary purposes:
It sells a project to senior management and other stakeholders.
•
It demonstrates that a thorough and well‑considered process has taken
•
place.
It preserves a team’s reasoning so that future team members can under‑
•
stand how choices were made.
It provides the basis for functional specifications and acceptance tests.
•
It can be a starting point for user documentation.
•
Are Software Requirements Different from
Business Requirements?
Not in this book. I use the term software requirements very broadly to mean any
requirements for making or changing software systems. Most of what I cover
applies to any type of requirements, but some analysts attach a great deal of
meaning to the term software in the phrase software requirements. Sometimes
you will hear a great effort made to distinguish software requirements from
business requirements, technical requirements, functional requirements, non‑
functional requirements, minimum daily requirements, and so on.
Having tangled with several of these terms in various environments and
projects, I can confidently tell you there is no clear consensus about what
they mean and how they should be used. When engaged to work on any type
of requirements, you should not assume you know what to do just because
37001c01.indd 6 1/29/09 10:50:41 PM