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 grateful to Richard Marshall for reading an early draft, and to Professor Ken Jackson for his perceptive and precise comments. 0321131630P05292002
评分
评分
评分
评分
这本书的深度不仅仅停留在“如何写”的层面,更深入探讨了“谁来写”以及“如何达成共识”的软技能部分。我个人认为,这部分内容是许多同类书籍所缺失的。作者用了相当大的篇幅来讨论需求沟通中的权力动态和认知差异。书中分析了分析师、产品经理、开发人员以及最终用户之间的信息壁垒,并提出了打破这些壁垒的具体策略,比如采用“三方会谈”模式来共同定义验收标准,而不是让分析师单方面记录。最让我印象深刻的是对“隐含假设”的剖析。作者指出,很多项目失败的根源并非是需求写错了,而是因为双方对于某些基础性的行业规则或技术环境存在未被言明的共同假设,一旦这个假设被推翻,整个需求链就会断裂。为了对抗这种风险,书中提供了一套“假设清单驱动的提问法”,它强迫读者主动去挑战那些被视为理所当然的前提条件。这种将心理学和沟通技巧融入技术写作的跨界处理,极大地提升了这本书的独特性和实用价值,让我意识到,写好需求,首先是一种高阶的人际沟通能力。
评分这本书的叙事节奏把握得相当老练,完全不像某些技术书籍那种平铺直叙、干巴巴的风格。作者似乎非常懂得如何将枯燥的理论融入到引人入胜的案例流中。我读到关于“非功能性需求”的那一章时,深有体会。以往我对性能、安全这些概念总是感到模糊,觉得它们更像是项目末期测试时才需要操心的事情。然而,这本书通过一个虚构的电商平台升级案例,清晰地展示了如果不将响应时间、并发处理能力等写进早期文档,后续团队在架构选型上会走多大的弯路,以及由此带来的成本激增。作者没有直接批判瀑布模型或敏捷模型的优劣,而是巧妙地利用这个案例,展示了在不同开发范式下,需求文档的形态和侧重点应该如何灵活调整。最让我拍案叫绝的是,书中穿插了几组“需求审查清单”,这些清单并非是官方标准,而是作者根据多年经验提炼出来的“防坑指南”。例如,其中一项提醒我注意识别那些带有“通常”、“大概”、“尽快”这类模糊词汇的表述,并提供了一套替换方案,要求用可量化的指标来替代。这种实操性极强的工具输出,使得这本书的价值远远超出了理论探讨的范畴,更像是一份可以随时拿出来对标的实战工具箱。
评分读完这本厚厚的书,我最大的感受是它的“系统性”和“可移植性”。它没有局限于任何特定的行业或技术栈,无论是金融系统的核心模块开发,还是一个面向消费者的移动应用迭代,书中的原则和方法论都适用。作者构建的这套知识体系是高度自洽的,从业务目标定义到具体的技术规格描述,各个层级之间的逻辑衔接如同精密机械般紧密。让我特别受益的是对“度量”的强调。书中反复指出,一个好的需求必须是可测试的,而可测试的前提是其结果是可度量的。它提供了一套从宏观业务指标(如转化率提升百分比)到微观系统指标(如错误率低于千分之一)的层级化指标设定框架。这套框架的价值在于,它真正将“需求”这个文档和最终的“商业成功”紧密地绑定在了一起。当我合上这本书时,我明白这并不是一本读完就可以束之高阁的工具书,而更像是一本可以伴随我职业生涯不断回顾和实践的“方法论圣经”。它教会我的不是固定的招式,而是培养一套持续质疑、精确表达和有效协作的思维模式。
评分从排版和细节来看,编辑团队显然也下了不少功夫,这使得阅读体验本身就成了一种享受。书籍采用了大量的图表和流程图来辅助解释复杂的概念,这些图表的设计非常简洁,去除了所有不必要的装饰元素,直奔主题。例如,书中用一个“需求演化路径图”清晰地展示了从模糊的业务目标到具体的验收标准,中间经历了哪些信息的损耗和提炼过程。这种视觉化的呈现方式,对于我们这种需要经常向非技术背景的管理者汇报进度的专业人士来说,简直是救星。我发现自己可以轻易地截取其中的某个图表,直接放入演示文稿中,并能快速地向听众解释清楚我们当前的需求成熟度。而且,书中在讨论需求文档的版本控制和变更管理时,所采用的语言非常具有前瞻性。它没有固守传统的“冻结需求”观念,而是接受了需求是必然会变化的现实,转而重点教授如何建立一个健壮的“变更控制流程”,确保每一次修改都有据可查、影响可控。这体现了作者对现代软件开发环境的深刻理解,即灵活性与可控性之间微妙的平衡艺术。
评分这本书的封面设计,那种沉稳的深蓝色调,配上烫金的字体,初看之下就给人一种专业、可靠的感觉。我拿起它的时候,期待着能从中找到一些能立刻提升我日常工作效率的“速效药”。翻开目录,里面的章节划分得异常清晰,从基础的概念界定,到深入的场景应用,逻辑链条非常完整。我尤其欣赏作者在引言部分对“为何要写好需求”的阐述,那段话不仅仅是陈词滥调地强调其重要性,而是从项目失败的案例出发,层层递进,构建了一种不写好需求就无法达成商业目标的紧迫感。它没有急于抛出复杂的模型,而是先用一系列生动的比喻,将抽象的需求文档具象化,比如把优秀的需求比作建筑的蓝图,而糟糕的需求就像是手绘的草图,看似有形状,但结构随时可能崩塌。这种由浅入深的讲解方式,极大地降低了初学者的阅读门槛,让我感觉自己并不是在啃一本晦涩的技术手册,而是在听一位资深的项目经理分享他的实战经验。书中对“用户故事”的探讨也十分到位,不仅仅是罗列“作为一个[角色],我想要[目标],以便于[价值]”的句式,而是深入解析了如何通过访谈技巧挖掘出用户真正潜在的需求,而不是他们口头上说的那些“想要”的东西。这部分内容,对我重塑与利益相关者沟通的方式起到了立竿见影的作用。
评分 评分 评分 评分 评分本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2026 book.quotespace.org All Rights Reserved. 小美书屋 版权所有