Preface

The Purpose of This Book

There is nothing new under the sun. It has all been done before.
-Sherlock Holmes: A Study in Scarlet,
Arthur Conan Doyle

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.

What This Book is Not

This is not a book about the process of specifying requirements or about analysis techniques or requirements management. There are other good books that explain all those things, and this book can be used as a reference alongside them. This book can, however, be used perfectly well by itself; it includes a "crash course in specifying requirements" for readers with no previous experience.

This book doesn't advocate any particular methodology, approach, or specification software tool. It provides relevant advice no matter which way you choose to work. It isn't prescriptive: it doesn't say, "You must do it this way." It steers clear of jargon and avoids introducing its own terminology as far as possible.

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.