The purpose of this book is to help you decide and define what a new software system needs to do and to suggest what extra features to add to make it a good system—or even an excellent one. It saves you effort and enables you to be more precise, by providing detailed guidance on how to specify individual requirements. Requirement patterns are encapsulated expertise, conveniently prepackaged for reuse. The book contains 37 requirement patterns, each of which describes an approach to tackling a particular type of situation that crops up repeatedly in all kinds of systems, but focusing on commercial business software. Only a fraction of any system is specific to its business area; the bulk occurs over and over again no matter what your system is for. These patterns cover more than half of all requirements in some systems—a lot more if we add the extra requirements the patterns suggest.

If you're wary of the word "requirement" here, don't be; it doesn't mean you have to be embroiled in paperwork. This book is suitable for use by business analysts using a traditional analysis approach and by software architects and engineers who use agile methods. You can use requirement patterns to help you identify and define what a system needs to do even if you don't write formal requirements as a result.

The requirements for a software system specify the problem it needs to solve—its purpose and goals. If they're omitted or done badly—which is, unfortunately, all too frequently the case—a system is unlikely to be a perfect fit, no matter how well it's implemented. A disturbing proportion of computer systems are judged to be inadequate; many are not even delivered; more are late or over budget. Studies consistently show that the single biggest cause is poorly defined requirements: not properly nailing down a system's purpose and what it must do. Even a modest contribution to improving requirements offers the prospect of saving businesses part of a huge sum of wasted investment.

To build good systems more often, improvements are needed all along the chain. Serious efforts have been (and continue to be) made in nearly all of them. But most fundamental of all is what the requirements themselves actually say (and, just as importantly, fail to say). That's been neglected, but it's what this book concentrates on. If I want to define a requirement of a specific type, what do I need to write? How do I go about it? What extra requirements should I consider writing? What else should I worry about? This book identifies many areas (big and small) for which requirements are frequently inadequate, imprecise, or missed altogether—and suggests what you can do about it. The patterns themselves aim to be down-to-earth and practical—primarily distilled from personal experience—things I wish I'd known all along.

This is primarily a reference work, to be pulled out whenever you want help in a particular situation—to explain what a requirement needs to convey, raise questions to ask, point out potential pitfalls, suggest extra requirements, provide example requirements, and generally provide practical advice. You can start using the requirement patterns without having read the book through.

This book contains lots of example requirements—over 400—many of which are suitable for applying unchanged to any system and others that are a useful starting point for a requirement to suit the reader's needs. These examples are the heart of the book. It was from the study of real-life requirements that the requirement patterns in this book were identified. Omissions, ambiguities, and other weaknesses in these real requirements fed much of what the requirement patterns have to say.

This book also provides guidance on how to write other kinds of information that belong in a requirements specification—such as system scope, assumptions, a glossary, document history, and references—and how to structure a requirements specification.

You won't agree with everything in this book, and you won't need to act on all the suggestions made by any requirement pattern. But if the time it saves you, when writing requirements or later, is worth more than the purchase price, it has earned its keep. I hope that these patterns prove useful one way or another, by containing enough useful and thought-provoking material to lead you to produce better systems.

The primary audience of this book is anyone involved in deciding what a new software system needs to do. This is the business of specifying the requirements for a software system, even if you don't like the word "requirement" or you don't end up writing a full requirements specification. For convenience, we refer to any person who specifies requirements as an analyst; they could be a business analyst, a systems analyst, a systems architect, or a software engineer; they could be a business-oriented or technical person. They might have previous experience with specifying requirements, or they might not. They can be divided into those who use traditional analysis processes and those who use more agile methods:

Secondary audiences are:

Job titles of people who will find this book valuable include business analyst, systems analyst, business systems analyst, software architect, systems architect, software engineer, testing engineer, product manager, project manager, project office manager, and chief technical officer.

You, dear reader, will be able to improve your skills and productivity in the following ways from reading this book (and from using it as a reference):

As a result you, your colleagues, and the organization you work for will see further benefits:

This book can be used with no previous experience of specifying requirements. Chapter 1 is a "crash course" containing the bare minimum that a novice reader needs to get started. A good general book on requirements engineering (such as those cited at the beginning of Chapter 1) is a better introduction, and readers who have read them or who are already experienced business analysts are likely to get more from this book. Software engineers using agile methods can use the book in isolation. Anyone responsible for reviewing a requirements specification needs no previous knowledge or skills in order to use this book to help them.

This book is accessible to a nontechnical reader. It focuses on writing textual requirements in natural language that can be read by anyone. It is free of arcane diagram formats, deep theory, and jargon. You can read it without knowing UML (Unified Modeling Language) or any other formal technique.

This book is divided into two parts:

Bringing up the rear are a glossary of terms and acronyms used and encountered in the book, plus a list of references.

I advise that you read through Part I to understand what's going on. If Chapters Chapter 1 and Chapter 2 in the book don't tell you enough, refer to the Web page for the full versions. You don't need to devour Part II systematically: familiarize yourself with the patterns that it contains (unless you're an analyst keen for advancement!), and refer to it whenever you encounter a situation in which one of the patterns will help.

You can download the following documents from the book's companion Web page at http://www.microsoft.com/mspress/companion/9780735623989:

The first two are available both as Adobe PDF (Portable Document Format) documents and Microsoft XML Paper Specification (XPS) documents. The last two are available as Microsoft Word documents. To download these documents, you will need about 6 MB of disk space. For system requirements for viewing these files, see the companion Web page.

I greatly appreciate the diligent and generous contributions of a number of people, without whose assistance this book would have been much the poorer—or wouldn't even have been completed at all. First, special thanks to Trish Reader for encouragement all the way through, sound business analysis advice, and feedback on various drafts.

I am deeply indebted to all my reviewers, especially those who heroically read and commented cover to cover: to Roxanne Miller, for her deep understanding of what all business analysts will look for in this book, and for keeping me (relatively) honest on analysis techniques; and to Lydia Ash, for her expertise on testing but also countless invaluable suggestions on almost everything. I appreciate the feedback and suggestions of Robert Posener for scrutinizing the text with the all-seeing eye of the consummate project manager; Craig Malone on development methodologies (especially agile matters); Marc Munro for his database expertise on the information and data entity patterns; security guru Eric Fitzgerald on access control; and accessibility experts Annuska Perkins, Norm Hodne, Ramkumar Subramanian, and Laura Ruby. Finally, thanks to Shanno Sanders for perceptive insights on the overall direction of the book. Sometimes I have rashly persisted in disregarding their advice, for which I assume full responsibility—as I do for all errors that remain.

I am grateful to Karl Wiegers for contributing such a generous Foreword, and for the early encouragement that was the nudge I needed to write this book.

I'd like to thank everyone at Microsoft Press, especially acquisitions editor Ben Ryan for his faith in the concept, and editors Devon Musgrave and Maria Gargiulo for their never-failing patience, their good-natured reactions to even the quirkiest of my ideas, and their painstaking copy editing. Finally, this book could never have been written at all if not for the innumerable people who have contributed to my professional experience over the years. The most valuable have been those at the two extremes of the spectrum: the excellent, from whom I've learned so much about how to specify and develop good systems; and the inept, whose creativity in finding ways to do things wrong is an education in itself. Thanks to you all.