Begin at the Beginning

The first step in any project is to find out what users require. It’s almost that simple.

• By Mike Gunderloy
• 07/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 Microsoft Press.

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 requirements:

• 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 analyst.

‘Tis the Voice of the Customer, I Heard Him Declare…
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 can succeed.

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 whole process.

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.

Your Homework
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.