Writing Better Requirements
Writing Better Requirements
复制标题
DOI：
--
复制
发表时间：
2002-08
期刊：
影响因子：
--
通讯作者：
I. Alexander;R. Stevens
中科院分区：
文献类型：
--
作者：
I. Alexander;R. Stevens
摘自书中：并不是他们看不到解决方案。是他们看不到问题所在。 G. K. Chesterton 需求是必不可少的 需求是项目成功的关键。我们都知道这一点，但我们常常忘记n并付出代价。许多项目，无论是工业界还是公共部门，都未能达到所需的效果。他们交付延迟，超出预算，而且质量很差。错过需求是灾难性的。本书的目标读者是《编写更好的需求》，旨在为正在实践的系统工程师和其他需要编写需求的人提供简短、方便的概述。因为它是关于实用技术的，所以它应该在许多不同类型的系统和软件项目中有用。我们的目标是让读者能够编写足够好的需求，以便针对它们指定、设计和测试成功的系统。对于想要学习如何开始处理需求的学生来说，本书也应该是一个有用的介绍。本书涵盖和不涵盖的内容 本书特别关注如何发现和表达需求。它不是关于系统规范，也不是如何做出满足用户需求的设计，甚至不是用户应该如何确保满足他们的需求。既然用户拥有需求，那么这些需求就必须以用户可以理解的方式表达。本书将需求视为简单的文本，并由操作场景和非正式图表支持。人们已经进行了许多尝试来改进这些简单的方法，使用更正式的结构和符号，并取得了不同程度的成功。我们并没有试图涵盖所有这些方法。为了将需求置于上下文中，本书当然必须涵盖开发过程的某些方面。项目管理、验证、质量保证和开发生命周期都与需求密切相关，事实上，这些领域中的每一个领域孤立起来都是毫无意义的。但在本书中，我们专注于捕获和编写需求的任务。每章都包含练习，帮助读者练习技能。我们为那些想要超越编写良好需求而扩展到系统和需求工程其他方面的读者推荐一些好书。充分利用本书内容 本书应按照其编写顺序进行阅读，引导读者完成识别、收集、组织和审阅的严格过程。这对于成功至关重要。每一章都介绍了需求过程中的一个阶段。关键术语通过示例和练习进行非正式定义、解释和说明，以培养良好需求编写的实践技能。这些技能包括观察问题、与人打交道、批判性地审视正在编写的内容以及有效地审查需求。在某种程度上，审阅是一项单独的技能，可以单独看待；其他的按或多或少严格的顺序排列在一起。本书的结构 我们首先说明需求的重要性。您可能需要本章来说服其他人他们有问题。太多的项目要求很差，并且永远无法恢复。如果您已经确信，可以跳过这一介绍性章节。然后，我们以非技术的方式展示如何定义问题，并与唯一知道问题所在的人（用户）密切合作。本书的正文逐步介绍了整个过程，着眼于：如何捕获用户的需求；如何将这些组织成从用户到开发人员的清晰信息；要求所需的特殊写作技巧；如何在每个阶段非正式地审查需求，然后正式审查。实践练习 本书正文中的所有章节都包含供读者使用的实践练习。这些被设计为每次大约需要半小时。有些是足够开放的，可以进行更广泛的自学或学生项目。我们建议读者尝试每个练习，至少简单地尝试一下，以实际感受所涉及的困难。书的后面是所有问题的简短答案，并为读者提供了更完整项目的提示。先解决问题再解决问题 如果这本书的信息可以用一句话来表达的话，那就是：在尝试创建解决方案之前，先就人们的需求达成一致。找出需要什么，而不是急于提出假定的解决方案，是系统开发各个方面的关键。只要有决心、耐心、熟练的团队以及对要解决的问题的良好定义，大多数技术问题都可以得到解决。致谢 我们要感谢那些如此仔细地审阅本书的匿名审稿人；我们的妻子和家人在我们写作时对我们的宽容；以及我们所有的咨询、培训和研讨会客户，他们亲身体验了这些材料并向我们展示了解释它的方式。我们特别感谢理查德·马歇尔阅读了早期草稿，并感谢肯·杰克逊教授的洞察力和精确的评论。
From the Book: 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.