Product Description

Well-written requirements are crucial to systems of all kinds: you are unlikely to get what you want unless you ask for it. This book explains and demonstrates exactly what requirements are for, and how to write them

---

Product Details

• Amazon Sales Rank: #233077 in Books
• Published on: 2002-08-31
• Original language: English
• Number of items: 1
• Binding: Paperback
• 176 pages

From the Back Cover

Experience has shown us that investment in the requirements process saves time, money, and effort. Yet, development efforts consistently charge ahead without investing sufficiently in the requirements process. We are so intent to develop the technical solutions that we are unwilling to take the time and effort to understand and meet the real customer needs.
--From the Foreword by Ralph R. Young, author of Effective Requirements Practices

Who is it for?

If you are involved in the systems engineering process, in any company -- from transport and telecommunications, to aerospace and software -- you will learn how to write down requirements to guarantee you get the systems YOU need.

What skills will I learn?

• How to write simple, clear requirements -- so you get what you want
• How to organize requirements as scenarios -- so everyone understands what you want
• How to review requirements -- so you ask for the right things

0321131630B05282002

About the Author

Ian F. Alexander is an independent consultant specializing in requirements engineering. He has written several training courses on systems and requirements engineering. He has led many training courses on systems engineering, requirements, DOORS, and DXL, and has run numerous practical workshops on scenarios, trade-offs and requirements. He is co-author of an Addison-Wesley book on HTML 3 and its 2nd Edition on HTML 4. He is the author of the Scenario Plus for Use Cases toolkit, and is a well-known speaker and writer on scenario usage.

Richard Stevens is the founder of QSS, the firm that launched the pioneering requirements management tool DOORS - the worldms most popular requirements tool. He is the co-author of the books Systems Engineering, Software Engineering Standards, Software Engineering Guidelines, and Understanding Computers. In 1998, Richard was appointed as the first European Fellow of INCOSE, the International Council on Systems Engineering.

0321131630AB05282002

Excerpt. © Reprinted by permission. All rights reserved.

It isn't that they can't see the solution. It is that they can't see the problem.
G. K. ChestertonRequirements 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 grateful to Richard Marshall for reading an early draft, and to Professor Ken Jackson for his perceptive and precise comments.

0321131630P05292002

---

Customer Reviews

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.

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 Practical Advice

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

Good, but short
There were some good thoughts about writing better requirements, but, for the price that you pay for the book, I expected more substance. Most of the suggestions are just good common sense.