Chapter 1: Synopsis of

"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.
"I don't much care where-" said Alice.
"Then it doesn't matter which way you go," said the Cat.
"-so long as I get somewhere," Alice added as an explanation.
"Oh, you're sure to do that," said the Cat, "if you only walk long enough."
-Alice in Wonderland,
Lewis Carroll

Overview

This chapter tells you the bare minimum that you need to know about requirements to understand the rest of the book. It is a synopsis of a much larger version of the chapter that is available for download from the book's associated Web page at http://www.microsoft.com/mspress/companion/9780735623989. (See the Preface for more information.) For convenience, the two are referred to as the synopsis and the full versions. The synopsis concentrates on defining concepts and terminology that are used throughout the book; it sets the scene. The full version goes into a lot more detail (on every topic) and provides justifications and advice-but it is still merely a whirlwind introduction to the subject. Both versions are organized in the same way: opening with some basic definitions and justifications, then describing where requirements fit in the overall process of building a system, and putting forward some principles worth following. Both versions end by describing three overall approaches to requirements, which are: a traditional approach, in which requirements are specified in detail before moving on to the development phases; an extreme approach, which strives to produce software as rapidly as possible at the expense of formality and documentation, and in which requirements are much less prominent; and a compromise incremental approach that specifies some of the requirements up front and some later on. Requirement patterns are equally applicable and equally valuable no matter which approach you take.

A number of good books explain software requirements in general and traditional requirements processes in a lot more detail, present a lot of extra analysis techniques, and cover other requirement-related activities ignored here. Of these, Software Requirements by Karl Wiegers (Microsoft Press, 2003), is my favorite. (Others include Robertson & Robertson, 2006; Davis, 1993; and Leffingwell & Widrig, 2000. See "References" at the back of this book for details.) This chapter (even the full version) is no substitute for such a book, and the reader is urged to invest in one (or more) of them.

This chapter assumes that you want to define what a new software system is for and what it must do-though it insists neither that you write a requirements specification nor that you include in your project a dedicated "requirements phase" following which the system will be designed and built. A system, as far as this book is concerned, comprises a collection of software components and (optionally) the hardware on which it runs; this book does not regard any of the people who use the system as part of the system itself.

This book makes no assumptions about the manner in which you record requirements. The most straightforward way is to use a word processor. Alternatively, you can use a requirements management tool built especially for the purpose.