Begin at the Beginning
The first step in any project is to find out what users require. It’s almost that simple.
The beginning is the chiefest part of any work.
- By Mike Gunderloy
- July 01, 2003
How do you begin a new software project? Do you open up your favorite
IDE and start slamming in code? Perhaps you think a bit first and noodle
a few diagrams down on a cocktail napkin. Or perhaps you sketch the user
interface on your whiteboard, right next to the football pool statistics
and the phone number for that good Chinese place around the corner.
If you’re taking any of these approaches, you’re not really
beginning at the beginning. Before you can build any piece of software,
you need to know what the software will accomplish: What are its requirements?
If you lack a structured process for answering that question, it might
be time to pick up a copy of Karl E. Wiegers’ Software
Requirements, just out in a vastly expanded second edition from
It’s Not As Easy As It Looks
Even defining the term “requirements” isn’t a
simple matter. Different stakeholders in the project may have different
ideas of its requirements, and you may focus on different kinds of requirements
depending on the project lifecycle. Wiegers distinguishes four types of
- Business Requirements—High-level objectives of the
organization or customer who requests the system.
- User Requirements—User goals or tasks that the users must
be able to perform with the product.
- Functional Requirements—Software functionality that the
developers must build into the product to enable users to accomplish
their tasks, thereby satisfying the business requirements.
- System Requirements—Top-level requirements for a product
containing multiple subsystems. Note that not all of the subsystems
will be software!
Wiegers goes on to divide the process of working with these requirements
into requirements development and requirements management. Requirements
development further divides into a complex set of elicitation, analysis,
specification, and validation activities, with feedback loops between
them. After requirements development has teased out the requirements for
a product, requirements management entails the process of coming to agreement
with the customer as to what the requirements are. Of course, it’s
all dynamic; you ignore the requirements change process at your peril.
Much of the book is devoted to digging into these various activities in
depth and providing concrete advice for the budding (or experienced) requirements
‘Tis the Voice of the Customer, I Heard Him
One of the best parts of this book is chapter 7, which is devoted
to requirements elicitation. Wiegers identifies this (correctly, in my
experience) as “perhaps the most difficult, most critical, most
error-prone, and most communication-intensive aspect of software development.”
Requirements the most critical part of a software project? Sure! When
I think back on my own experience of failed projects, most of them revolve
around disagreements between customer and developer as to just what was
supposed to be done. Lacking that agreement, there’s no way you
Wiegers provides lots of ideas on eliciting requirements, including the
use of a formal requirements workshop to enable a group of users to work
together with the developer. He covers the role of the analyst in helping
guide the discussion and offers lots of tips on digging out and formalizing
the requirements that the users might not even know they had. Perhaps
most important, there are tips on telling when you’re finished eliciting
requirements. For instance, if the users can’t come up with any
more use cases, it probably means they’ve told you everything that
the software needs to do.
Use the Case, Luke
Use cases emerge as a central construct in this methodology. That
makes sense, because they’re a concept that makes sense both in
the software development domain and in the real world. Actual users can
understand the notion of writing little scenarios about who does what
with the software. Developers can turn these scenarios into pretty little
stick figure diagrams that make them feel happily structured about the
Wiegers offers advice on both gathering and documenting use cases. He
also relates use cases back to functional requirements, and warns (as
with so many other things) of the traps that you need to avoid. In particular,
he has one warning that can apply to almost any methodological construct:
Don’t try to force every requirement you encounter to fit
into a use case. Use cases can reveal most—but probably not all—of
the functional requirements.
Quantity and Quality
Even experiences requirements analysts may learn new tricks from
this book. Consider the notion of quality attributes. You may think you’ve
collected all the requirements for a new piece of software when you know
what it should do—but what about all the unspoken assumptions about how
well it should do those things? These quality attributes are also part
of the requirements, and often the hardest part to get out of the users.
Typically they’re represented by hard-to-quantify terms such as
availability, efficiency, flexibility, integrity, and usability. The book
offers a framework for thinking about these nebulous requirements, and
ways to talk with users about them.
The evidence is fairly strong that these quality attributes aren’t
always considered in the software world. Think about commercial products
you’ve used: Ever try to do something that seemed reasonable, only
to end up with a dialog box telling you that there were 1,432,574 minutes
remaining in the operation? That’s a sure sign that the software
is functionally there, but lacking in some important usability requirements.
Overall, as you might guess, I’m quite impressed with this
book (I don’t have time to review bad books in this column). In
addition to a comprehensive view of the field, Wiegers also writes well.
Each chapter starts with a narrative illustrating its main point from
an example of requirements gathering in the wild, and ends with things
for you to think about in your own work.
You’ll also find useful templates and formats for documents scattered
throughout the book. Better yet, you’ll find them online at http://www.processimpact.com/goodies.shtml.
In particular, if you’re on the fence, I suggest you take a look
at the Current Requirements Practice Self-Assessment on the Web site.
If you don’t score very high on this exam, then your requirements
process could stand some improvement. And given that errors are much less
costly to fix at the requirements stage than at any later time in the
development process, such improvement tends to have a very good return.
Got a requirements horror story? Or a great way to collect requirements
without doing hard work? Drop me a line and let me know about it! I’ll
use the most interesting comments in a future issue of Developer Central.