Also by Ian Alexander:
   Scenarios, Stories, Use Cases
   Discovering Requirements

Requirements are essential

Requirements are the key to project success. We all know this, but we often forget – 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 – 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.

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.

© Ian Alexander 2002

© Suzanne Robertson 2002

Back to Top

© Jeremy Dick 2002

Back to Top

Sticky Minds Review by Roland PJ Aucoin

The objective of this book is to provide a guide for new writers for improving written requirements. It introduces the importance of requirements, the audience of these requirements, the users of these requirements, the different names for and types of requirements, and the challenge of the actual requirement writing process.

This book delivers practical experiences and prudent, conservative guidelines for improved, documented requirements. The terms used are sufficiently generic to accommodate a wide range of reader application background. The book is also sufficiently focused and technical to provide the depth and foothold that new and inexperienced requirement documenters need.

Every project and product starts its life with the gathering and recording of requirements. The better the collection and clarity of the documented requirements, the better the product.

This is an easy book to read, well directed to the intended audience: new requirements writers. It gives several practical guidelines, and includes many real-life experiences as examples. The authors show requirements gathering happens in iterations, not all at once. They present many ways to approach and resolve issues. They use generic definitions and steps, but focus on achieving correct results. Overall the flow is very logical and has a good pace. The book is organized to reinforce the points in the exercises. It also contains many “best practices.”

The authors focus on "checklists, traceable requirements, quality (not perfection)," and checks and reviews—often missed or assumed in generating requirements but critical to project success. Section 5.5, "Exceptions," is an excellent topic to address, as it is often overlooked in requirements. I do caution on section 6.3, negotiating scope—one needs a lot of experience in metrics to resource and scope without design. In my work, I first get complete requirements, then do some design, then resource and negotiate scope to get construction approval. It is too difficult to do it in any other order.

The best description of the book is in the Foreword by Dr. Ralph Young: "Ian Alexander and Richard Stevens are interested in helping you to evolve requirements that meet the customer's needs. They have provided an approach that is based on experience and lessons learned from decades in 'the school of practical experience.'"

© Roland PJ Aucoin 2003

Back to Top

ACCU Review by Roger N Lever in C Vu

Requirements are a fundamental part of any project, however, that does not mean that this is a subject that has been so well documented that there is nothing left to learn. In fact many might suggest that writing requirements is not understood at all based on some so-called requirements documentation. That is where this book aims to help - writing better requirements.

Although it is not a large book (~150 pages) it does cover the subject in sufficient detail that you will undoubtedly learn something even if you think you know a bit about it to start with. The book itself is structured around capturing, organising, writing and reviewing requirements. Each topic is addressed in an engaging, clear and concise style and each chapter includes exercises to help reinforce the material. These questions have some suggested answers at the back of the book and this is a useful way of realising how little critical thinking is applied to even some apparently simple statements.

There is a lot of good commentary in this book and unless you have spent a great deal of time learning the ropes and improving continuously you will learn something new. This learning will be reinforced by the many examples of both the right way and the wrong way to produce requirements. For those people who are interested in this area it is a very useful book to have to hand. Before I started reading this book I thought I knew something about writing requirements - I definitely know more now.

© Roger N Lever 2003

Back to Top

The Rational Edge Review by Peter Hanschke

Whether you are new to writing requirements or an old pro, this book is a must read. For novices, the authors provide a step-by-step methodology for writing requirements. For the pro, the layout of the requirements gathering and writing process is an excellent refresher. Do you want to achieve greater clarity when using common terms or improve the structure of your requirements document? This book has the required level of detail to help.

The first chapter covers the preliminaries and defines common terms such as user, customer, and different names used for requirements. It finishes with a description of requirements writing within the larger context of system development that is, unfortunately, buried in the text and treated too lightly. All too often, project teams do not really understand the discipline of requirements gathering and writing. This sometimes results in animosity from team members who mistakenly think their agendas conflict with that of the analysts and resent the amount of time these activities require. A separate chapter expanding upon the relationship between requirements and the rest of the development process would have helped readers understand that writing requirements is a crucial activity; it affects the entire project team as well as the quality of the product.

In subsequent chapters, the authors do a good job of describing a process for writing better requirements, providing useful techniques for each process step. The most difficult step in the requirements process is gathering proper, well-articulated requirements from stakeholders, and the techniques presented in the chapter on requirements gathering are particularly useful. Conducting interviews, holding workshops, and observing users at work are some of the techniques the authors identify and describe. In many cases users do not really know what their requirements are, so augmenting the interview or workshop with a prototype usually spurs their imagination. Regardless of the format interviewers chose for gathering requirements, the authors encourage them to keep asking the "Why?" question until the real requirement is revealed. Other useful questions are "So what?" and "Who cares?"

The exercises in these chapters are also well presented and well thought out -- every chapter has at least one exercise that assigns the reader tasks based on ideas and techniques covered in the text. For example, the exercises in Chapter 4 -- "Other Sources of Requirements" -- provide the reader with sample specifications. The task is to read the specification, extract statements from the text, and categorize these statements according to their type (User Requirements, System Specification, Design Elements, etc.). The first exercise identifies statements that need categorizing, and the second exercise is "free-form" -- the reader must pick out the statements for categorizing. Completing all of the exercises gives the user a practical way to learn and experience the process of gathering and writing requirements.

A chapter on how not to write requirements adds some humor to the book. For example, "The battery low warning lamp shall light up when the voltage drops below 3.6 volts, and the current workspace or input data shall be saved," is an example of including multiple requirements in one statement. (I don't think the two requirements are related, but you never know -- they just might be!) The example, "The fire alarm shall always be sounded when smoke is detected, unless the alarm is being tested or the engineer has suppressed the alarm," points out that "let-out" clauses, such as those that begin with "unless," can be dangerous. Actually, a fire alarm built to this requirement would be a real danger! (I am sure I have written a few laughable requirements in my lifetime, too.)

In addition to the few minor weaknesses I've cited, the authors include a single snippet of the European Space Agency's Software Development Standards but then do not reference it again. This left me frustrated. I felt they should either have provided more information and excerpts as an Appendix or simply not mentioned the standards at all.

Overall, however, I am confident that this book will help all who read it not only to improve their ability to write requirements but also to convey the importance of good requirements writing to other team members. I have found it particularly useful to give people examples of bad requirements. In our daily speech we use all sorts of constructs -- let-out clauses, wishful thinking, rambling, and so forth -- that we must avoid when writing requirements, and the examples this book provides are a great way to demonstrate the confusion they can cause.

As a product manager, I constantly write requirements documents; I know that I will use this book as a reference to gather and categorize them, and to lay them out clearly.

© Peter Hanschke 2003

Back to Top

Experience has shown that investment in the requirements process saves time, money, and effort. Yet, development efforts consistently charge ahead without making a sufficient investment in the requirements process. Project teams are so intent on developing the technical solutions that they are unwilling to take the time and effort to understand and meet real customer needs.

Those involved in the systems engineering process at any company may find this book useful for learning how to draft requirements that will help guarantee that users get the systems they need. The authors provide specific guidelines for writing simple and clear requirements, organizing those requirements into scenarios that help everyone get the features they want, and reviewing the requirements to ensure that they ask for the right features at the project’s outset.

© Michael J. Lutz 2003

Back to Top

“Too many projects have poor requirements, and never recover.”

Requirements as the Foundation for Success.  Good systems begin with good requirements.  Requirements elicitation and writing and prioritization and evolution and validation are key fundamental skills for all systems engineers.  Learning these skills – and maintaining them – takes practice. 

I routinely encourage SE practitioners at all levels to periodically read a “requirements process book.”  This is a good, concise, and practical book on the activities and challenges of the requirements process.  “The challenge in writing requirements is mainly to communicate reliably between groups of people who may never meet, and who have quite different viewpoints.”

Target Audience.  “Writing Better Requirements is designed as a short, convenient overview for practicing systems engineers and others who find they need to write requirements. . . . This book should also form a useful introduction for students who want to learn how to get started with requirements.”

The Write Requirements Process.  The authors build the book around a simple, five step view of the write requirements process – a process that must be structured, disciplined, and iterative for projects to succeed:

·   Identify stakeholders

·   Gather requirements

·   Organize requirements

·   Check requirements

·   Review and baseline requirements

Structure.  “This book specifically focuses on how to discover and express requirements.”  The eight chapters of the book talk in detail to each of the five steps above.  Chapters include:

1. Introduction

2. Identifying stakeholders

3. Gathering requirements from stakeholders

4. Other sources of requirements

5. Structuring the requirements

6. Requirements in context

7. Requirements writing

8. Checking and reviewing

Style and Features Worth Mentioning.  The writing style is simple and focused, pithy and practical:  “once you have established a basic structure, take it back to the users and check it out.”  Guidance is sufficiently detailed and prescriptive to be useful in a wide range of project contexts.  Examples and checklists are frequent.

Four particular features of the book that facilitate its usefulness include:

·   Identification of a set of 38 key requirements-related terms that are highlighted and defined in the text – and collected together into a glossary

·   A set of 18 exercises that encourage readers to practice the guidance provided – along with a set of answers in an appendix  (Don’t cheat!)

·   An appendix which provides an example of a set of system requirements

·   An annotated list of 23 references for further reading organized into five categories – a right-sized list.

Should You Buy It?  First and foremost, I find this to be an excellent first book on requirements – a good primer.  The book’s simplicity, conciseness, readability, and practicality make it well suited for being a good introduction to requirements processes.  It could fit well into “introduction to SE” classes and courses.

Second, it could serve well as a “refresher” book to be passed around the SE team on any project.  Third, the book could be used by SE practitioners to help educate and indoctrinate customers and clients who will be participating extensively in requirements processes.  The book would be informative, facilitative, and safe in this role.

Availability.  This 6”x9” 176-page paperback book lists for $36.99.  Amazon has it for $33.20 (or £14.69 or EUR 34,56 from European Amazon locations).  The publisher also has discounts.

Additional Information. The entire preface of the book is on the publisher’s site.

Alexander’s Web Site.  This is a classy and informative site!  It is very extensive; very well organized, and very easy to use.  Alexander provides a wide range of resources for the requirements engineer.  He includes numerous book reviews on a wide range of topics that are of interest to a broader range of SE practitioners.  I strongly encourage readers to visit the site and become at least aware of the range of information that is available there.

In Closing.  As I said above, I view this as a very good first book on requirements.  It is concise, informative, and prescriptive.  It is elegant in its conciseness and simplicity.  I found the book grow on me the more I read it.  This book can help you write good requirements.  And good requirements are the foundation for building good systems. 

“Requirements are the key to project success.  We all know this, but we often forget – 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.”

“Perhaps the key to the whole process is an effective way of organizing the requirements. . . . the way the users see their own problem.”

Back to Top

Amazon Customer Review by J. Brown

The Book Provides Practical Advice

It is rare when you come across a project management book that is easy to read, short and full of valuable information but Writing Better Requirements meets this criteria. I like simple and to the point!

The book provides good practical advice on writing requirements. Alexander and Stevens follow their own advice for writing requirements in the book by using simple words that contribute to the books readability. The book is written in a manner that will not intimidate non-technical personnel so it may given to the entire project team, including customers and users. (Wait... I just had a novel idea...we should teach our customers and users how to write requirements.)

Here are five of many valuable tips from Writing Better Requirements

1. Perspective on the requirements effort. The authors state approximately 5% of the project effort and up to 25% of the schedule duration should be put on project requirements.

2. Guidance on structuring requirements. Improper structuring is identified as a primary cause of poor requirements. The structuring discussion includes a useful table that documents problems and solutions for structuring requirements. For, example, the authors characterize one problem as Some requirements can be applied simultaneously or in any order and provide the common sense solution of Mark whether sections in the structure are sequences, parallels or alternatives. Overall the authors provide some good alternatives to challenges on how to effectively structure requirements.

3. Plenty of exercises. Another valuable aspect of this book are the exercises provided after a lot of the sections in the book. The exercises provided are well thought out and solutions are included at the end of the book. In addition to the exercises examples are provided to clarify and reinforce key points.

4. Guidelines on conducting a requirements workshop. Important guidelines on how to conduct a requirements workshop are discussed including room lay out and facilitation tips. The book has a good glossary of terms.

5. Lists of other sources of requirements. The book includes a nice list of other sources of requirements. One of these sources that is often overlooked is problem reports from the previous system. The authors state these problem reports can often be turned around into requirements. This is a powerful method to ensure improvement of the future system.

Writing Better Requirements should be a part of every project managers library. I give it 5 of 5 stars! Make your life easier and give it as a holiday gift for your users and customers.


Dr. James T. Brown PMP PE CSP
Author - The Handbook of Program Management

Amazon Customer Review by Vance Hilderman

I found this book to be very helpful in developing an overall process sense of requirements development. This book provided an excellent synopsis of "why" good requirements are important and what the pitfalls are when such is lacking. The examples were both relevant and descriptive. As an overall initial treatise on requirements, this book was terrific. As such, the focus is perhaps more upon managers and leaders of teams, rather than the actual developer of detailed requirements. Ideally there would be a follow-on companion volume with greater detail to better aid the actual developer of requirements including checklists and several case studies, as well as more detailed examples. But I completely recommend this book.

Amazon Customer Review by Michelle A. Maese

I love this book!

It's a short and to the point book on what requirements should contain; it's like a cliff-notes version of other requirements gathering books. We ordered one for our whole team and made it required reading! For anyone who doesn't have the time nor the patience to weed through 300 pages to get to the point, this is the book for you.

Amazon Customer Review by J.A.D. Swan

DIY Requirements Analysis: a great primer

Back to Top

Amazon Customer List by Jonas_S

From an Amazon list by jonas_s called 'Companions for your business success': "Reducing time-to-market parameters, through extracting clear goals and req. incorporated with your customer."

Back to Top

Adopted by Clinical Research Working Party

Writing Better Requirements has been adopted as the approved requirements reference by the Computer Systems Validation in Clinical Research (CR-CSV) Working Party in their Joint ACDM/PSI Guideline on Computer Systems Validation Clinical Research, 2^nd Edition, 2004. This is an industry-specific set of advisory standards for computer systems used to support the research and development of pharmaceuticals. Since there is a safety and hence regulatory aspect to such work, it is essential that all aspects of the development environment be fit for purpose. The guideline covers Risk Management, User Requirements, and User Acceptance Testing (among other topics) for systems that collect, process and store critical evidence of drug effectiveness.

Back to Top

An RQNG List by mnotaro

Writing Better Requirements by Ian Alexander
(a little old-school, but some things - like writing good requirements - never go out of style)

Back to Top

Agilier

There are plenty of books around covering techniques for gathering requirements; however, these tend to be focussed on a particular development method, such as RUP or plan-driven, or focussed on a particular engineering discipline, such as software or systems engineering. Alexander and Stevens' excellent book focuses simply on how to write better requirements - irrespective on what development method used or what product is under development.

After some solid definitions of commonly-used (and misused) terms within requirements engineering, the authors proceed to describe techniques for identifying the appropriate stakeholders and then how to elicit the requirements from them - elaborating interview, workshop and prototyping techniques.

The authors also describe other sources of requirements, for example:

• old documentation;
• existing and potential customers;
• helpdesk staff;
• competitors' products;
• contracts.

It is this section of the book is one that demonstrates the authors' real-world experience - this reviewer has found many additional requirements and constraints while studying contractual documentation, for example.

The most interesting part of the book from a practitioner's viewpoint is the book's approach to structuring requirements. Traditionally, most systems engineering projects have a structure that lists the requirements as a series of "shall statements" enshrined in the IEE-830 standard. This is in contrast to most software engineering projects that commonly use a scenario-based structure. Scenarios, are, in the words of the authors, a "time-sequenced series of activities to structure a set of requirements" - the most popular scenario format being the Use Case format.

The authors prefer to use a combined approach by firstly defining the goals that the system will meet and then creating scenarios that met that goal as a series of individual steps. These steps form the basis for the requirement set and can either be written in the "shall" format described above or in a more compact way that the authors prefer. The authors propose an alternative that allows easier reading:

• User type - the type of user that benefits from the requirement
• End state - where the user wants to reach when the requirement successfully executes;
• Testability - the requirement must be testable

The authors emphasise that the text is only part of the requirement set; there are other attributes used as appropriate - such as the source of the requirement and its priority.

Interestingly, this compare structures closely with "user stories" - a very lightweight requirement format used by agile methods such as XP and Scrum

As a [type of user]
I want to [perform some task]
so that I can [achieve some goal]
tested by [specified a test scenario]

As a [harried shopper]
I want to [locate a CD in the store]
so that I can [purchase it quickly, leave, and continue with my day].

<requirements in context - constraints, scope, additional information - toolset>
The authors define constraints as those types of requirement that limit the number of design solutions. These include those are usually called "non-functional" requirements, such as reliability, supportability and maintainability. The importance of this type of requirement is well-known in systems engineering projects; however, this requirement type is often overlooked in "traditional" software projects.

Finally, the authors recognise that the nothing is perfectly correct first time and emphasise the fact the requirements gathering is iterative. Successful projects rely on frequent user feedback - this applies in aspects of requirements elicitation, too.

This excellent book covers the sweet spot between agile and plan-driven projects and would be equally suitable for systems and software engineering projects. It would be equally suitable for those practitioners experienced in agile projects who are looking for more rigour and formality and also for those that are experienced in plan-driven projects who may be looking for a requirements structure that is more easily read by their stakeholders.

The authors’ systems engineering background is a valuable counterpoint to many requirements books that are focussed exclusively on software engineering. Many practitioners with experience in the latter will find their awareness sharpened by the precise definitions of such terms as “affordance”, “constraint” and the distinction between a user requirement and a system requirement.

There is a useful glossary and exercises throughout. Answers are provided, although some have no definitively-correct solutions – rather like the real world.

Modest in size but massively useful.

Back to Top

You may also like: