Who Will Benefit from Using This Book

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:

1. Business analysts, or anyone fulfilling that role. This book makes no assumptions about how much the reader knows: it's suitable for both junior and experienced business analysts as well as for business executives and software engineers who have never specified requirements before. Requirement patterns can be put into practice quickly.

2. Software architects and engineers on any system for which requirements have not been written-because the gap must be filled, and it will be one way or another. This book's advice is equally relevant no matter who decides what a system needs to do. Its advice is of just as much value to any organization that does not have dedicated analysts, and particularly those that take an agile approach to development. Agile methods place little (if any) emphasis on writing requirements specifications, but still the functionality of the system must be identified-and the requirement patterns in the book can help just as well here as when using a traditional approach. In extreme programming, in particular, requirement patterns can help you write user stories, interpret user stories, and formulate "rules" for good practices for developers to follow. Software architects and engineers who are familiar with design patterns should be particularly comfortable using requirement patterns.

Secondary audiences are:

3. Anyone asked to review a requirements specification, which covers a wide range of technical, managerial, and sales people as well as a new system's user community. This book can help reviewers judge a specification's quality and completeness, and discover omissions.

4. Software developers who must implement requirements. Each requirement pattern contains a "Considerations for Development" section to assist developers.

5. Software testers who must test how well the delivered system satisfies its requirements. Each requirement pattern contains a "Considerations for Testing" section for testers with suggestions on how to test requirements of that type.

6. Project managers who manage a system's requirements, changes to them, and a project to implement them.

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.