Table of Contents
| Foreword | viii |
| Preface | x |
| Acknowledgments | xiii |
| 1 | Introduction | 1 |
| 1.1 | Why do requirements matter? | 1 |
| 1.2 | Who are requirements for? | 6 |
| 1.3 | Different names for requirements | 8 |
| 1.4 | Different types of specification | 10 |
| 1.5 | The challenge of writing better requirements | 11 |
| 1.6 | The requirements writing process | 16 |
| 2 | Identifying the stakeholders | 19 |
| 2.1 | Different types of stakeholder | 19 |
| 2.2 | Your house extension: a simple case? | 21 |
| 2.3 | A practical approach to identifying stakeholders | 22 |
| Exercise 1 | Listing the stakeholders | 23 |
| 3 | Gathering requirements from stakeholders | 27 |
| 3.1 | Possible techniques | 27 |
| Exercise 2 | Asking "why?" | 31 |
| 3.2 | Interviews | 31 |
| 3.3 | Workshops | 39 |
| 3.4 | Experiencing life as a user | 44 |
| 3.5 | Observing users at work | 44 |
| 3.6 | Acting out what needs to happen | 45 |
| 3.7 | Prototypes | 48 |
| 4 | Other sources of requirements | 50 |
| 4.1 | Possible sources | 50 |
| Exercise 3 | Extracting requirements from source documents | 55 |
| Exercise 4 | Extracting requirements from a memo | 57 |
| 4.2 | Getting requirements for mass-market products | 58 |
| 4.3 | User requirements in subsystem projects | 58 |
| 5 | Structuring the requirements | 60 |
| 5.1 | You need structure as well as text | 61 |
| 5.2 | Breaking down the problem into steps | 62 |
| 5.3 | Organizing requirements into scenarios | 65 |
| 5.4 | Examples of goal decomposition | 68 |
| Exercise 5 | A structure for user requirements | 69 |
| 5.5 | Handling exceptions | 70 |
| Exercise 6 | Could anything go wrong here? | 72 |
| Exercise 7 | Exceptions | 74 |
| 5.6 | Examples and exercises in requirement structure | 75 |
| Exercise 8 | Creating a heading structure | 76 |
| Exercise 9 | The right document for each subject | 76 |
| Exercise 10 | Wrongly placed requirements | 78 |
| 6 | Requirements in context | 79 |
| 6.1 | The user requirements document | 79 |
| 6.2 | Organizing the constraints | 81 |
| Exercise 11 | Writing constraints | 87 |
| 6.3 | Defining the scope | 87 |
| Exercise 12 | Restricting the scope | 89 |
| 6.4 | Requirement attributes | 90 |
| 6.5 | Keeping track of the requirements | 92 |
| 7 | Requirements writing | 96 |
| 7.1 | Quality, not perfection | 96 |
| 7.2 | Sketch, then improve | 96 |
| 7.3 | Anatomy of a good requirement | 97 |
| 7.4 | Guidelines for good requirements | 98 |
| 7.5 | Don't write like this | 100 |
| Exercise 13 | Good requirements | 105 |
| Exercise 14 | Writing requirements for familiar domestic systems | 105 |
| Exercise 15 | Ambiguous requirements | 107 |
| 8 | Checking and reviewing | 108 |
| 8.1 | Checking the document structure with users | 108 |
| 8.2 | Checking the requirements | 111 |
| Exercise 16 | Checking individual requirements | 113 |
| Exercise 17 | Checking a set of requirements | 115 |
| 8.3 | Reviewing | 116 |
| 8.4 | Success-the reviewed document | 120 |
| Exercise 18 | Reviewing | 120 |
| Summary | 122 |
| Appendix | Example user requirements | 124 |
| Answers to exercises | 130 |
| Glossary | 146 |
| Further reading | 150 |
| Index | 155 |
Forewords & Introductions
It isn't that they can't see the solution. It is that they can't see the problem.
G. K. Chesterton
Requirements are essential
Requirements are the key to project success. We all know this, but we often forget n and pay the price. Many projects, both in industry and in the public sector, fail to do what is needed. They deliver late, over budget, and poor quality. Missing out on requirements is disastrous.
Who this book is for
Writing Better Requirements is designed as a short, convenient overview for practising systems engineers and others who find they need to write requirements. Because it is about practical techniques, it should be useful in many different kinds of system and software project. We aim to enable readers to write requirements good enough for successful systems to be specified, designed, and tested against them.
This book should also form a useful introduction for students who want to learn how to get started with requirements.
What this book does and does not cover
This book specifically focuses on how to discover and express requirements. It is not about system specification, nor how to make a design that meets user needs, nor even about how users should ensure their requirements are met.Since users own the requirements, these must be expressed in a way users can understand. This book treats requirements as simple pieces of text, supported by operational scenarios and informal diagrams. Many attempts have been made to improve on these simple means, using more formal structures and notations with varying success. We have not tried to cover all these approaches.
To place requirements in context,the book must of course cover some aspects of the development process. Project management, verification, quality assurance, and the development life cycle are all closely linked with requirements n indeed each of these areas is meaningless in isolation. But in this book, we concentrate on the tasks of capturing and writing requirements. Each chapter contains exercises to help readers to practice their skills.
We recommend some good books for readers who want to go beyond writing good requirements to other aspects of systems and requirements engineering.
Getting the best from this book
This book is meant to be read in the order in which it is written, taking the reader through a disciplined process of identifying, gathering, organizing, and reviewing. This is vital for success.
Each chapter introduces a stage in the requirements process. Key terms are defined informally, explained, and illustrated with examples and exercises to develop the practical skills of good requirements writing.
These skills involve looking at problems, dealing with people, looking critically at what is being written, and reviewing requirements effectively. Reviewing is to some extent a separate skill and can be looked at separately; the others belong together in a more or less strict sequence.
Structure of this book
We begin by illustrating the importance of requirements. You may need this chapter to convince other people that they have a problem. Too many projects have poor requirements, and never recover. If you are already convinced, you can skip this introductory chapter.
We then show in a non-technical way how to define a problem, in close co-operation with the only people who know what the problem is, the users. The body of the book steps through the process, looking at:
- how to capture requirements from users;
- how to organize these into a clear message from users to developers;
- techniques for the special kind of writing needed for requirements;
- how to review requirements informally at every stage, then formally.
Practical Exercises
All the chapters in the body of the book contain practical exercises for the reader. These are designed to take about half an hour each. Some are sufficiently open-ended for more extended self-instruction, or student projects. We recommend that readers attempt each exercise, at least briefly, to get an actual feeling for the difficulties involved. At the back of the book are short answers to all the questions, with hints to the reader for more complete projects.
Problems before Solutions
If the message of this book can be stated in a sentence, it is:
Get agreement on what people want, before attempting to create solutions.
Finding out what is needed, instead of rushing into presumed solutions, is the key to every aspect of system development. Most technical problems can be solved, given determination, patience, a skilled team n and a good definition of the problem to be solved.
Acknowledgements
We would like to thank the anonymous reviewers who checked the book so carefully; our wives and families for tolerating us while we wrote; and all our consultancy, training and workshop clients who experienced the material first-hand and showed us the way it needed to be explained. We are specially Richard Marshall for reading an early draft, and to Professor Ken Jackson for his perceptive and precise comments.
Read an Excerpt
Preface
It isn't that they can't see the solution. It is that they can't see the problem.
G. K. Chesterton
Requirements are essential
Requirements are the key to project success. We all know this, but we often forget n and pay the price. Many projects, both in industry and in the public sector, fail to do what is needed. They deliver late, over budget, and poor quality. Missing out on requirements is disastrous.
Who this book is for
Writing Better Requirements is designed as a short, convenient overview for practising systems engineers and others who find they need to write requirements. Because it is about practical techniques, it should be useful in many different kinds of system and software project. We aim to enable readers to write requirements good enough for successful systems to be specified, designed, and tested against them.
This book should also form a useful introduction for students who want to learn how to get started with requirements.
What this book does and does not cover
This book specifically focuses on how to discover and express requirements. It is not about system specification, nor how to make a design that meets user needs, nor even about how users should ensure their requirements are met.Since users own the requirements, these must be expressed in a way users can understand. This book treats requirements as simple pieces of text, supported by operational scenarios and informal diagrams. Many attempts have been made to improve on these simple means, using more formal structures and notations with varying success. We have not tried to cover all these approaches.
To place requirements incontext, the book must of course cover some aspects of the development process. Project management, verification, quality assurance, and the development life cycle are all closely linked with requirements n indeed each of these areas is meaningless in isolation. But in this book, we concentrate on the tasks of capturing and writing requirements. Each chapter contains exercises to help readers to practice their skills.
We recommend some good books for readers who want to go beyond writing good requirements to other aspects of systems and requirements engineering.
Getting the best from this book
This book is meant to be read in the order in which it is written, taking the reader through a disciplined process of identifying, gathering, organizing, and reviewing. This is vital for success.
Each chapter introduces a stage in the requirements process. Key terms are defined informally, explained, and illustrated with examples and exercises to develop the practical skills of good requirements writing.
These skills involve looking at problems, dealing with people, looking critically at what is being written, and reviewing requirements effectively. Reviewing is to some extent a separate skill and can be looked at separately; the others belong together in a more or less strict sequence.
Structure of this book
We begin by illustrating the importance of requirements. You may need this chapter to convince other people that they have a problem. Too many projects have poor requirements, and never recover. If you are already convinced, you can skip this introductory chapter.
We then show in a non-technical way how to define a problem, in close co-operation with the only people who know what the problem is, the users. The body of the book steps through the process, looking at:
- how to capture requirements from users;
- how to organize these into a clear message from users to developers;
- techniques for the special kind of writing needed for requirements;
- how to review requirements informally at every stage, then formally.
Practical Exercises
All the chapters in the body of the book contain practical exercises for the reader. These are designed to take about half an hour each. Some are sufficiently open-ended for more extended self-instruction, or student projects. We recommend that readers attempt each exercise, at least briefly, to get an actual feeling for the difficulties involved. At the back of the book are short answers to all the questions, with hints to the reader for more complete projects.
Problems before Solutions
If the message of this book can be stated in a sentence, it is:
Get agreement on what people want, before attempting to create solutions.
Finding out what is needed, instead of rushing into presumed solutions, is the key to every aspect of system development. Most technical problems can be solved, given determination, patience, a skilled team n and a good definition of the problem to be solved.
Acknowledgements
We would like to thank the anonymous reviewers who checked the book so carefully; our wives and families for tolerating us while we wrote; and all our consultancy, training and workshop clients who experienced the material first-hand and showed us the way it needed to be explained. We are specia to Richard Marshall for reading an early draft, and to Professor Ken Jackson for his perceptive and precise comments.
loading...