作者：[英]SuzanneRobertsonJamesRobertson著
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
掌握需求过程(第3版)试读：
版权声明
Authorized translation from the English language edition,entitled: Mastering the Requirements Process: Getting Requirements Right,Third Edition,9780321815743 by Suzanne Robertson and James Robertson,published by Pearson Education,Inc.,publishing as Addison-Wesley Professional,Copyright©2013 Pearson Education,Inc.
All rights reserved.No part of this book may be reproduced or transmitted in any form or by any means,electronic or mechanical,including photocopying,recording or by any information storage retrieval system,without permission from Pearson Education,Inc.
CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD.and POSTS&TELECOM PRESS Copyright © 2013.
本书中文简体字版由Pearso.Educatio.Asi.Ltd.授权人民邮电出版社独家出版。未经出版者书面许可，不得以任何方式复制本书内容。
本书封面贴有Pearson Education（培生教育出版集团）激光防伪标签，无标签者不得销售。
版权所有，侵权必究。
第3版译者序
《掌握需求过程》已出版到了第3版，其间的时间跨度达到了十多年。当年的第1版让我惊艳，现在的第3版让我看到经过岁月和历练，她散发着成熟的魅力。Elon Musk在一次TED访谈中提到，有两件事情很重要：一是好的理论框架，二是注重实践反馈。《掌握需求过程》的第3版正好体现了这两点。
在理论框架方面，作者完善了以前版本中需求过程和需求规格说明书模板的内容。另外，第3版增加了Brown Cow模型，将以前版本中隐含的发现需求本质的思想阐述得更清晰。所谓需求，绝不是解决方案。所谓解决方案，决不是需求。只有弄清楚真正的需求，才能得到创新的解决方案。我以为，自动化的信息系统和业务领域的完美结合，是这个时代的最大创新；而创新是 IT从业人员最应该关注的事情。
在实践反馈方面，作者继续强调了需求验收标准的重要性，这是利益相关者早期的重要反馈。第3版重点讨论了迭代式开发中需求工作的方式，体现了需求理论框架与项目实践反馈的完美结合。作者完全拥抱了敏捷开发的价值观：成功的项目不是按时间、按预算交付产品，而是给产品拥有者带来巨大的价值。
没有什么比好的理论更可实践的了。在这本书的翻译过程中，我学到很多，在此郑重将本书推荐给大家。王海鹏2013年夏于上海
第3版前言
为什么需要第3版的《掌握需求过程》？因为我们需要它。自本书的上一版本出版以来，已过了不少时间，在需求和开发的世界里发生了不少事情。我们已将本书中介绍的Volere需求技术应用到许多项目中。我们从项目、客户和其他Volere技术的实践者那里得到了反馈。有了这些知识，我们觉得是时候更新本书，反映需求实践的当前状况了。今天的系统、软件、产品和服务必须更吸引人、更适用，才能让人们注意、购买、使用和珍爱。我们比以前更需要确保我们在解决真正的问题，我们比以前更需要更好地完成需求发现的工作。
软件开发的新技术（最值得注意的是敏捷技术的兴起）已经改变了需求发现者的角色：不是指需求活动背后的真相，而是指需求发现的方式。与敏捷团队合作的业务分析师完成任务的方式是不一样的。结合迭代、增量和螺旋式开发技术，这要求业务分析师用不同的方式来完成需求任务。
外包的增长巨大，这没有减少需求的工作负担，而是更需要得到准确、无二义性的需求。如果你计划将规格说明书发到地球的另一端，就需要考虑外包方是否能理解它，准确地知道要构建什么。
尽管这些变化改变了我们开发和交付产品和服务的方式，但底层的事实仍然没变，即：如果我们要构建某种软件、产品或服务，那么它必须为其拥有者提供最佳价值。
你会在这个版本中看到最佳价值的主题，它得出的结论是：怎样开发软件并不重要，重要的是软件为其拥有者做些什么。你可以按时、按预算完成一个项目，但如果交付的软件没有给拥有它的组织机构带来什么好处，那就是浪费钱。换言之，你可以超预算或超工期，但如果交付的产品带来了几百万美元的价值，那它就比便宜的竞争产品更有益。
业务分析师的任务是发现软件要改进的真正的业务。这不能简单地在键盘上完成，因为软件是一种解决方案，要提供有价值的解决方案首先要理解要解决的问题（真正的问题）。在这个版本中，我们增加了在横线上思考的内容。这里的横线来自于Brown Cow模型（你需要阅读本书来了解它是什么），代表技术实现和抽象本质世界之间的分界，在抽象本质世界中才能发现真正的需求。我们增加了创新的内容，这是发现更好的、更适用的需求和解决方案的方法。
这就是需求发现者的任务，也是这一版的任务：更深入地探讨如何理解客户的组织机构，如何通过发现和沟通对问题的更好的理解，来找到更好的解决方案。2012年6月于伦敦
致谢
写书很难。如果没有他人的帮助和鼓励，编写一本书几乎是不可能的，至少对于本书的作者是这样。所以我们很高兴能花一些篇幅来告诉你是谁给了我们帮助和鼓励，使本书得以出版。
Vaisala公司的And.McDonald慷慨地贡献出他的时间，并向我们提供了相当多的技术评论和观点。我们迫不及待地想要说明的是，本书中的IceBreaker产品只是Vaisala公司的IceCast系统的一个“远亲”。Vaisala用户组（Vaisal.Use.Group）也提供了很有价值的评论和观点，E.M.Kennedy是Vaisala用户组的主席。
感谢那些技术审阅者，他们在百忙之中抽出时间辛苦地读完了相当不完善的材料。Mike Russell、Susannah Finzi、Neil Maiden、Tim Lister和Bashar Nuseibeh都无愧于接受我们的敬意。
我们也要感谢在Atlantic Systems Guild公司的同事（Tom DeMarco、Peter Hruschka、Tim Lister、Steve McMenamin和John Palmer），感谢他们多年来给予的帮助、指导和不轻信的关注。
Pearson Education 公司的职员也做出了贡献。无论何时，当我们谈及延长最后期限时，Sally Mortimore、Alison Birtwell和Dylan Reisen berger总是非常慷慨和有技巧，使用了非常有说服力的语言。
对于第2版，Peter Gordon在恰当的时间提供了指导和建议。Kim Boedigheimer、John Fuller和Lara Wysong在本书的出版过程中发挥了巨大的作用。Jill Hobbs更正了我们的语法错误和断句错误，使这本书具有可读性。Ian Alexander、Earl Beede、Capers Jones和Tony Wasserman提供的技术信息是无价的。先生们，谢谢你们敏锐的洞察力。所有剩下的技术错误都要归因于我们自己。
你也许觉得，到了作者出第 3 版时，就不需要帮助了。事实并非如此。我们非常感谢负责文字的三人小组Gary Austin、Earl Beede和John Capron。我们的Volere同事Stephen Mellor解决了我们遇到的一些麻烦问题。我们的Volere同事James Archer和Andrew Kendall在这些年里提供了帮助，贡献了他们的想法和经验，拿着一杯红酒和我们进行了有意义的对话。
Pearson的员工Peter Gordon、Kim Boedigheimer和Julie Nahil提供了无价的帮助。我们特别要感谢Alan Clements设计了本书的封面。Jill Hobbs再次更正了我们的语法错误和语义错误。
最后要感谢我们研究班的学员和咨询的客户。他们的评论、他们坚持要求的清晰解释、他们的洞见以及他们的反馈意见，都对本书产生了影响，不管这种影响是否直接。
谢谢大家！Suzanne RobertsonJames Robertson2012年6月于伦敦
第1版序
从Don Gause和我出版了Exploring Requirements: Quality before Design一书到现在已经差不多10年了。我们的书实际上是一种探索，是关于人们的处理过程的调查，这些过程能够用于为软件系统或其他产品收集完整、正确和可沟通的需求。
参考阅读
Gause,Donald C.,and Gerald M.Weinberg.Exploring Requirements: Quality Before Design.orset House,1989.
这里使用了“能够”一词，但在这10年里，我们的客户最常问到的问题是：我如何能够将这些分离的过程组织起来，成为针对信息系统的完整全面的需求过程？
最终，James Robertson和Suzanne Robertson在本书中提供了一个答案，我可以负责任地将它提供给我的客户。《掌握需求过程》一书一步接一步、一个模板接一个模板、一个例子接一个例子，展示了一个经过良好测试的方法，该方法反映了一个完整的、全面的需求过程。
他们的过程暗含了“合理性”。换言之，过程的每一部分都是有意义的，即使是对那些在需求工作方面不太有经验的人来说也是如此。在组织机构中引入这类结构时，合理性就转化为易接受性，在如此多的复杂过程被尝试和拒绝之后，这一点显得非常重要。
他们描述的过程被称为Volere方法，这是他们在多年帮助客户改进需求的过程中积累而得的产物。撇开Volere方法本身不谈，对所有想开发需求并把这件事做好的人，James和Suzanne对这项艰难的任务贡献出了他们非凡的教学技巧。
对于 Robertson 夫妇的教学技巧，他们研究班上的学员和对他们的《Complete Systems Analysis》一书有很高热情的读者都很了解。《掌握需求过程》一书为分析方面的书提供了一个众人期盼的“前传”，也可以说是任何分析类书籍的“前传”。
参考阅读
Robertson,James,and Suzanne Robertson.Complete Systems Analysis: The Workbook,the Textbook,the Answers.Dorset House,1998.
我们可以使用所有我们能够获得的需求方面的好书，本书就是其中之一！Geral.M.Weinberghttp://www.geraldmweinberg.com1999年2月 第1章基本事实
本章讨论需求的基本构成。1.1 事实1
需求其实并非在谈需求。
对于软件产品、硬件产品、服务或任何你想构建的东西，需求就是它们要做的事或要成为的东西。不论你发现还是没发现，写下来或没写下来，需求都存在。显然，除非产品满足需求，否则就不对。所以从这个角度你可以认为，需求是某种自然法则，等着你来发现。
这就是说，需求活动主要不是编写需求文档。相反，它专注于理解业务问题，并为之提供解决方案。软件是要解决某种问题，硬件和服务也是。需求发现的真正艺术是发现真实的问题。只要你做到了这一点，就为识别和选择不同的解决方案奠定了基础。所以，从本质上说，需求与编写需求无关，而是发现要解决的问题。
另外，当我们说“业务”、“业务问题”或“工作”时，我们的意思就是你所关心的各种活动，它们可以是商业上的、科学上的、嵌入式的、政府的、军方的，实际上也可以是所有其他类型的活动、服务或消费品。
此外，在本书中，当我们说“他”（常指业务分析师）时，我们的意思是“他或她”。我们发现说“他或她”或“他/她”很不方便。请相信，需求工作不分性别。
在本书中我们用“他”来指所有性别。两位作者（一名男性和一名女性）觉得用“他或她”容易导致阅读不流畅，不方便。1.2 事实2
如果我们必须构建软件，那么它必须为拥有它的人提供最理想的价值。
请注意，我们关注最终结果的拥有者，只是间接地关注用户。这种关注似乎与通常的优先级相反，所以我们最好解释一下。
拥有者是为软件（也可以是硬件或其他要构建的产品）付费的人或组织，不论拥有者为该软件的开发付了钱，还是从别处购买了该软件。软件部署时造成的业务影响，也是拥有者付出的成本。另一方面，拥有者从软件中得到好处。描述这种关系非常简单，拥有者花钱买好处。
我们可以用另一种方式来表述：除非产品提供了利益，否则拥有者不会付钱。这种利益通常表现为提供某种以前没有的能力，或改变某种业务过程，使之更快、更便宜、更方便。自然，这种利益为拥有者提供的价值，必须超过开发该产品的成本（参见图1-1）。图1-1 随着软件变得越来越强大、成本越来越高，软件带来的利益也越来越大。但在某一点，构建的成本开始超过利益，项目就不再盈利了
要最好地体现价值，产品提供的利益必须与产品的成本相称。在某些情况下，如果带给拥有者的价值足够大，产品可以成本很高。例如，航空公司愿意付大量的钱来开发模拟器，确保飞行员获得合适的资质和技能。如果他们没有合适的资质和技能，就会造成生命财产损失。航空公司可能也会花大量的钱来开发自动化的值机系统，因为这将大幅减少乘客登机的成本。同一家航空公司只愿花很少的钱来开发食堂员工花名册系统，因为事实是：这类任务可以手工完成，食堂里的人不对可能带来烦恼，但几乎不会对生命构成威胁。
需求发现者（称为“业务分析师”、“需求工程师”、“产品拥有者”、“系统分析师”或其他头衔）的职责，就是确定拥用者看重的价值是什么。在某些情况下，提供一个小系统，解决一些小问题就能够为拥有者提供足够的利益，让他们觉得值。在另一些情况下（可能这种情况很多），扩展系统的功能将提供很大的价值，并且可能只要增加少量成本就可以实现。这都取决于拥有者认为什么有价值。
然后就是最佳价值：充分理解拥有者的问题，以便交付一个解决方案，以最好的价格提供最好的回报。1.3 事实3
如果软件不必满足要求，那你怎么干都行。但是，如果它打算满足要求，你就必须知道要求是什么，才能构建正确的软件。
这样思考很有价值：如果开发者正确地理解了产品打算为用户完成什么，以怎样的方式完成，这些产品就是最有用的。要理解这些事情，你必须理解拥有者的业务工作，并决定将来工作如何进行。
如果这些事情得到理解并达成了一致意见，业务分析师就与拥有者沟通，探讨怎样的产品能为工作带来最大的改进。业务分析师得到需求，描述产品的功能（它要做什么）以及产品的属性（它做到什么程度）。
不知道这些需求，开发项目得到的产品就不太可能有太大价值。除了少数撞大运的意外，没有产品能在事先不理解需求的情况下成功。
不论拥有者希望做哪种工作，科学的、商务的、电子商务的或社交网络的，也不论使用什么开发语言或开发工具来构建产品，开发生命周期（敏捷、原型、螺旋、Rational统一过程或其他方法）也与理解需求的要求无关。
这一事实总是会出现：你必须得到需求的正确理解，并与客户达成一致意见，否则你的产品或项目就会有严重的缺陷。
不幸的是，需求并非总是得到正确的理解。作者Steve McConnell 和Jerry Weinberg提供的统计数据表明，多达60%的错误源自于需求活动。软件开发者（几乎）有机会消除这些错误，但许多人选择（或他们的经理选择）几乎跳过需求发现，直接轻率地开始构建错误的产品（这是不可避免的）。结果，他们在产品上花了许多倍的金钱。如果开始就发现了正确的需求，成本会低得多。糟糕的质量在开发生命周期中传递，事情就这么简单。
有两次我被问到：“请告诉我，Babbage先生，如果向机器输入错误的数字，会得到正确的答案吗？”我无法理解问出这种问题的混乱思维。——Charles Babbage1.4 事实4
构建一个软件和解决一个业务问题之间，存在巨大的差别。前者不一定实现后者。
许多软件开发项目只关注软件。这也许看起来很合理，毕竟，大多数软件项目设法开发出某种软件。然而，只关注软件有点像在建帕台农神庙时只关注石头。软件要对拥有者有价值，就必须解决拥有者的业务问题。
我们开发了相当多的软件。每年产生数千万行代码（也可能是数亿行）。这些代码中包含许多错误，最多的错误是需求错误。因此，世界上相当多的软件不能解决正确的问题。
某些开发过程基于一种理念，即向目标用户交付某种功能，然后请他们来说是否能解决他们的问题。如果不能解决，软件就返工一下，然后再次展示并请求批准。这样做有一个问题：我们永远不知道用户批准前一次交付是因为对它满意，还是因为被过程搞得筋疲力尽。
最重要的是，很难让单个用户理解部署一个软件在更大范围内造成的影响。通常软件用户不知道更大业务的足够信息，不能确定具体应用这种软件是否会对业务的其他部分带来问题。
就算是啰嗦，我们也要再次强调，软件就是要解决一个业务问题。于是很清楚，所有开发工作都必须从问题开始，而不是从看到的解决方案开始。1.5 事实5
需求不一定要写下来，但构建者必须知道它们。
通常，需求项目的目标看起来就是尽可能得到一份厚厚的需求规格说明书。很少有人能理解它的大部分内容，甚至更少的人有耐心去读它，但这似乎都不重要。需求编写者相信，需求规格说明书越厚，他们的工作就越会受到欣赏。
在写好之后，这份可观的文档就被抛过墙头（或者应该说用铲车抛过墙头），交给开发者，盼望这些人对厚厚一叠规格说明书感到高兴。毕竟，它的页数越多，内容遗漏的可能性就越少。也许理论上是这样。自然，开发者几乎总是对这种文档毫无兴趣，要么忽略它，要么固执地坚持它。这两种方式的最终结果，通常都不能令人满意。
虽然有这种奇怪的行为，我们仍然需要分析需求，并将这些需求告诉给开发团队（参见图1-2）。图1-2 自然，需要和产品构建者沟通需求
需求是否写下来，这不是问题的要点。在某些情况下，口头沟通需求更有效，在另一些情况下，必须永久地记录下需求。
虽然口头沟通需求效率高，但我们觉得，所有需求都用这种方式来沟通是不可行的。在很多时候，编写需求的活动有助于业务分析师和利益相关者彻底理解需求。除了改进理解之外，正确编写需求也提供了追踪文档。需求的理由，或故事卡上的缘故，记录了团队的决定。它也为测试者和开发者提供了清晰的指示，说明了需求的重要性，从而建议需要花多少工作量。此外，如果维护者知道为什么有这项需求，也会降低将来维护的成本。
需求并不是要为项目增加额外的负担，所以除非很有必要，否则就不应该写任何东西。但是，如果有需要，那么编写需求的工作将带来数倍的回报，因为需求的准确性和对将来维护工作的减少。1.6 事实6
客户不一定总能给你正确答案。有时候客户也不可能知道什么是对的，有时候他就是不知道需要什么。
传统来讲，需求活动被看成是某种类似速记员的任务。也就是说，业务分析师仔细聆听利益相关者，准确记录他们说的所有东西，并将他们的要求翻译成产品的需求。
这种方式的缺点是，它没有考虑到利益相关者在试图描述需求时的困难。展望一个产品来解决一个问题，这不是一项简单的任务，尤其是问题并非总是理解得很彻底。考虑到今天业务的复杂性和规模，个人确实很难理解业务所有适当的部分。
我们也有“增量改进”的问题。在询问有关新系统时，利益相关者常常会描述原有的系统，并加上一些改进。这种增量的方式通常排除了所有重大的创新，常常会导致平庸的产品，不能满足期望。
业务分析师必须表演戏法。有时候他必须记录下客户的要求，有时候他必须说服客户，他们要求的并不是他们需要的，有时候他必须从客户的解决方案中导出需求，有时候他必须提出没有人提到的创新，得到更好的解决方案。在所有情况下他都应该想到，每个利益相关者都可能是匹诺曹（见图1-3），不要什么都相信。图1-3 有时候，你的客户就像匹诺曹，不会告诉你全部事实1.7 事实7
需求不是偶然得到的，要通过某种有序的过程得到。
所有重要的努力都需要有序的过程。随机使用钢筋和水泥不会建成大楼，需要一个定义的过程来设计和建造这样的结构。类似地，有一个定义的、系统的过程来拍电影。摩托车也是通过有序的过程来设计和建造的，你的最近一次飞行也是一组有序的过程，几乎是逐字执行的。甚至艺术工作，如写小说和画画，艺术家都会遵循一个有序的过程。
这些过程不是因循守旧的过程，不是无头脑地执行所有指令，不问任何问题，按预先描述的顺序，没有任何变通。相反，有序的过程由一组任务构成，实现预期的结果，但这些任务的次序、重点和应用程度需要采用该过程的人或团队来决定。
最重要的是，参与这个过程的人必须能看到，为什么过程中不同的任务是重要的，哪些任务对项目最重要。1.8 事实8
你怎么迭代都可以，但仍需要理解业务的需求。
自本书的上一版出版以来，迭代式开发方法变得越来越流行。这肯定是有意义的进步，但像很多进步一样，这些技术有时候炒作过度了。例如，我们曾听到有人说（也有人印刷出版），迭代式交付让需求变得多余。
冷静的头脑会意识到，任何开发技术都需要发现需求，这是认真开发的先决条件。因此，冷静的头脑已经将需求过程吸收到他们的开发生命周期中。聪明的方法不是废除需求，而是从一个不同的方向接近需求。
真正值得关注的是既要发现需求，又不必编写无用的、不成熟的、浪费的成堆文档（这适用于所有类型的开发技术）。
不论你怎样开发软件，总是要理解客户的业务问题，以及产品必须做些什么来解决这个问题（即它的需求）。1.9 事实9
没有银弹。所有方法和工具都无法弥补糟糕的想法和糟糕的手艺。
虽然我们需要一个有序的过程，但不应该认为它能够代替思考。过程有帮助，但它们对聪明人帮助较大，对不准备思考的人帮助较小。对于需求过程来说，这一点尤其正确。在需求过程中，业务分析师需要面对几个版本的需求，同时还要想象未来最好的软件产品是怎样的。
需求活动一点儿也不简单，要想成功，就需要业务分析师的思考和理解。一些自动化工具可以有所帮助，但它们只能作为辅助手段，而不能替代好的需求实践。盲目遵循事先制定的实践，根本不能取得有经验的业务分析师能取得的结果。分析师使用最重要的工具：头脑、眼睛和耳朵。1.10 事实10
要想成功地实现需求，需求就必须可度量、可测试。
从本质上说，功能需求是产品支持其拥有者的业务时必须做的事。非功能需求是产品要在拥有者的环境中取得成功，必须将功能完成得多好的量化描述。
要让构建的产品完全满足这些标准，在编写需求时就必须准确。同时，必须考虑到需求来自于人，而人并非总是准确，可能总是不准确。要达到必要的准确程度，必须对需求进行某种测量。如果可以用数字代替文字来测量需求，就能让需求可测试。“即使完美的程序检验工作，也只能建立满足规格说明的程序。软件任务最难的部分在于，得到完整而一致的规格说明书。构建一个程序的许多本质工作，实际上就是消除规格说明书中的缺陷。”——Fred Brooks，No Silver Bullet: Essence and Accidents of Software Engineering
例如，如果你的产品有一个需求是“应该对新用户有吸引力”，那么就可以建立一个测量指标，即初次使用的用户能够在2分钟内成功建立一个账户，对于用户应该知道的所有数据项，都不会有超过5秒钟的犹豫，如他的姓名、邮件地址和类似的数据项。（犹豫时间是测量产品直观程度的指标，是对用户的吸引力的一部分。）自然，如果你用这种方式来测量需求，测试人员就可以确定产品（有时候是产品原型）是否满足需求。
可以很放心地说，如果你不能为需求找到测量指标，那它就不是需求，只是一种无根据的想法。1.11 事实11
作为业务分析师，你将改变用户思考这个问题的方式，不是现在就是将来。
在你开始理解需求时，尤其在需求来自于不同的利益相关者时，你就开始建立一些抽象概念，并建立一个词汇表。你展示业务过程的模型，与利益相关者一起发现工作的本质，得到清晰和可测量的需求，并将所有这些事实反馈给利益相关者。在做这些事情时，你就会改变（改进）他们对业务问题的看法。
如果人们对需求的含义有了更好的理解，他们就可能看到改进的办法。你的一部分工作就是帮助人们尽早理解和质疑他们的需求，这样他们就可以帮助你发现他们真正的需求。1.12 需求究竟是什么
在了解这些事实之后，我们一直在讨论的需求到底是什么呢？简而言之，需求就是产品支持其拥有者的业务所必须完成的事，或让拥有者接受并感兴趣所必须具备的品质。需求之所以存在，要么因为该类型的产品要求某些功能和品质，要么因为客户希望该需求成为交付的产品的一部分。1.12.1 功能需求
功能需求描述了一个动作，产品要对操作者有用，就必须执行该动作。功能需求源于利益相关者需要完成的工作。几乎所有的动作（计算、检查、发布或其他动作）都可以是一项功能需求。
功能需求是产品必须完成的那些事。
产品应该生成一份所有道路的除冰调度表，这些道路在给定的时间参数内预计会结冰。
这类需求是产品要做的一件事。产品要在拥有者的业务背景下有用，就必须做这件事。你可以推断，上例中的拥有者是一个组织机构，负责保持道路的安全，实现方式是分派卡车，在快要结冰的道路上播撒除冰物质。1.12.2 非功能需求
非功能需求是产品的属性或品质。产品要让拥有者和操作者接受，就必须具备这些属性或品质。非功能需求描述了诸如观感、可用性、安全性和法律限制等需求，在某些情况下，这对于产品的成功是至关重要的。例如下面这个例子：
产品必须在0.25秒以内确定对方是“朋友”还是“敌人”。
非功能需求是产品必须具备的属性或品质。
有时它们作为需求的原因是为了改进产品，或让人们想买它。例如：
产品应该提供愉快的用户体验。
有时它们让产品可用：
产品应该能被到达大厅的旅行者使用，这些旅行者可能不使用当地的语言。
非功能需求可能开始看起来很模糊，或不完整。在本书后面的内容中，我们会看到如何为它们制定验收标准，让它们可度量、可测试。1.12.3 限制条件
限制条件是全局性的需求。它们可以是对项目本身的限制，或是对产品最终设计的限制。例
如，这是一个项目限制条件：
产品必须在新的税务年度开始前准备好。
限制条件是一个全局问题，约束着所有的需求。
产品的客户是在说，如果顾客不能在新的税务年度中使用该产品，那么它就没有什么用了。其效果是，需求分析师必须对需求进行限制，只包括那些在最后期限内能够提供最大价值的需求。
还有一些限制条件是针对产品的最终设计和构造的。例如，下面的例子：
产品应该作为iPad、iPhone、Android和Blackberry应用来运行。
如果这是一个真正的业务限制条件，而不只是某种看法或观点，那么不满足这个限制条件的所有解决方案显然是不能接受的。
不论限制了什么，限制条件都可以看成是另一种类型的需求，参见图1-4。
限制条件只是另一种类型的需求。图1-4 最终产品的功能受到限制条件的约束。功能性是用户能得到的好处，但“交付”功能性的非功能需求让产品可用，被用户接受1.13 Volere需求过程
本书描述了一个过程，目的是成功地收集、验证需求，并编写需求文档。每一章都将介绍该过程的一项活动，或者完成活动所需的需求收集的一个方面的问题。
Volere是意大利语，意思是“希望”或“想要”。
在学习该过程时，要记住它是针对得到提交产物的一个指南。通过该过程所做的工作是由相关的提交产物驱动的，而不是一种流程。我们希望你把这个过程看做一组任务，成功的需求工作必须完成它们（细节程度不同）。这个过程不是不惜一切代价必须遵守的固定流程。阅读每一部分时，要考虑在自己的组织结构中如何执行这部分过程。
你通过该过程所做的工作是由相关的提交产物驱动的，而非流程。
要理解这个过程，不一定要按本书的顺序来阅读，尽管可能有一些术语是前面章节中出现的。你的需求自然与其他读者的需求不同，因此你可能想先探索该过程的某些方面，然后再是其他方面。当你熟悉了该过程的基本框架后（第2章中提供），就可以随意阅读对你最有价值的章节。 第2章需求过程
本章探讨需求收集过程，并讨论如何来应用它。
本书是我们经验的提炼。在书中，我们描述了一个需求过程，它源自我们在需求领域多年的工作。在这些年里，我们与做聪明事的聪明人合作，参与不同领域的项目。世界各地有许多人使用了我们的技术的不同部分，我们从他们的经验中也学到很多。
不论是要构建用户定制的系统，还是构建组件集成的系统，或者使用商业上架销售的软件包，或者采用开源软件，或者将开发外包，或者对已有的软件进行改动，都需要发现、捕获和交流需求。
在多年的项目和客户咨询工作中，从最有效的活动和提交产物中，我们形成了Volere需求过程和与之相关的规格说明书模板。这些经验的结果就是一个需求收集和规格说明过程，其中的原则几乎可以应用于所有开发环境中所有类型的应用开发中，实际也确实是这样。
我们想从一开始就强调，当我们提供一个过程时，是将它作为一个发现需求的工具。我们不希望你挥舞着这个“过程”对同事说，这就是“做事情的唯一方式”。我们非常希望你从这个过程中发现许多有用的事情去做，从而更有效、更准确地收集需求。我们对这一点很有信心，因为我们亲眼看到数百个公司，他们根据自己的文化和组织机构来调整这个过程，我们也听说数千个公司已经这样做过。
采用Volere需求过程的客户，开发产品时采用了RUP、增量、迭代、螺旋、Scrum，或其他类型的迭代式开发过程，也有的客户采用了更正式的瀑布式过程，或自己定制的开发过程。这些年来他们与我们达成了一致意见：要构建正确的产品，就必须发现正确的需求。但需求不会来自于幸运的意外。为了发现正确、完整的需求，需要某种有序的过程。
要构建正确的产品，就要发现正确的需求。
图2-1展示了Volere需求过程。图中包含的每项活动，以及它们之间的联系，都在本书的后续章节中进行了详细讨论。图2-1 这张Volere需求过程图展示了活动及其提交产物。我们使用了特定风格的数据流图表示法。每个活动（圆圈表示）及其提交产物（带标签的箭头或
文档）将在正文中解释。虚线代表这个过程如何在迭代项目中使用2.1 需求过程的上下文
我们需要指出（实际上需要强调），这个过程没有设计成一个瀑布式的过程。在本书的不同部分，我们都会指出在采用某种迭代开发时，如何修改这个过程。
需求发现应该被看成是所有构建活动的先驱，但它也应该被看成是某种可以很快执行的活动，有时候相当不正式，有时候与后续的设计和构建活动重叠，但永远也不应忽略。
让我们先简单看一下图2-1中的所有活动，后续章节中会更详细地介绍。本章的目的是向你简要介绍这个过程，它的组件、它的交付物，以及它们结合在一起的方式。如果你想了解某项活动的更多细节，也可以在读完这部分简介之前，直接跳到相关章节。
在介绍这个过程时，我们假定你在开发一个新产品，也就是说，从头开发一个产品。我们采用这种方式，是为了暂时避免纠缠于所有维护项目都有的约束条件。稍后，我们将讨论这些情况下的需求，即产品已经存在，需要进行改动。2.2 案例分析
我们将通过一个项目来解释Volere需求过程，该项目采用了这个过程。
IceBreaker项目的目标是开发一个产品，能预测何时何地道路会结冰，并调度卡车用除冰物质处理道路。这个新产品使得道路管理部门能够更准确地预测冰情，更精确地安排道路处理，从而使道路更为安全。该产品也会减少除冰物质的需求，对道路管理部门的预算和环境都有帮助。
形成雾或冰的可能性取决于道路表面能量的接收或丧失。这种能量流由一些环境的因素和气象的因素（诸如暴露程度、海拔高度、交通状况、云的多少和风速等）控制。这些因素造成了道路表面温度随时间和位置的变化而变化。冬季夜间一个郡的道路网中路面温度差可达10℃。”——Vaisala News2.3 项目启动
想象一下火箭发射。10—9—8—7—6—5—4—3—2—1—发射！如果只需要从10开始倒计数就能发射火箭，那么就算是安道尔[1]也会有自己的太空计划。实际情况是，在我们进行火箭发射最后10秒倒计数之前，要进行大量的准备工作，火箭加满了燃料、计算了飞行轨道，实际上进行了一切火箭离开地面之前需要进行的工作。
启动（blastoff）也被称为“项目发起”、“发动”、“制定项目章程”以及许多其他的名称。我们使用启动这个术语来描述我们想表述的意思——发动项目并让它起飞。
启动会议的主要目的是为接下来的需求发现工作奠定基础，并确保项目成功需要的所有东西都已到位。主要的利益相关者（客户、关键用户、首席需求分析师、技术和业务专家，以及其他对项目的成功具有关键作用的人物）聚在一起，对关键的项目问题达成一致意见。
启动会议确定了业务问题的范围，争取让利益相关者达成一致意见，认为拥有者的组织机构的这个部分需要改进。启动会议确认了需求发现工作中要包含的功能，以及明确排除在外的功能。
确定业务问题的范围通常是最方便的启动方式。在IceBreaker项目中，首席需求分析师协调整个小组的讨论，直到他们对工作的范围（也就是要研究的业务领域）以及工作与周围的世界有怎样的联系达成一致意见。会议参与者们在白板上画出上下文范围模型，展示工作所包含的功能，并引申开来，展示他们认为在冰情预报业务范围之外的东西。这个图展示了工作与外部世界的关系，从而准确定义了包含的功能。（下一章会对此有更多介绍。）图2-2展示了上下文范围图在这里的用法。以后，随着需求活动的推进，上下文范围图将用于揭示辅助这项工作的最优产品。【关于项目启动的详细讨论，请参考第3章。】图2-2 上下文范围模型针对要研究的工作范围，在风险承担者之间达成一致意见。最终的产品将作为工作的一部分
当他们对要研究的业务范围差不多达成一致时，小组开始确定利益相关者。利益相关者是在项目中有利益关系的人，或者具有与该项目相关的知识，实际上，是所有对它有要求的人。对于IceBreaker项目来说，有利益关系的人是道路工程师、卡车车库负责人、气象预报人员、道路安全专家、除冰处理顾问等。必须确定这些人，这样需求分析师就能与他们一起工作，找出所有的需求。上下文范围图建立了工作的范围，对确定许多风险承担者是有帮助的。
项目启动也确认了项目的目标。启动小组对进行项目的业务理由达成了一致意见，并同意做这个项目可以得到清晰的、可测量的好处。小组也同意，业务投资于这个产品是值得的，而且组织机构有能力构建和运营该产品。
在这个阶段对项目的需求部分所涉及的成本进行初步预估，是不错的项目管理实践。这可以通过工作范围模型中包含的信息来完成。对项目可能面临的风险进行早期评估，也是不错的项目管理实践。尽管这些风险看起来像是负面新闻，但在为新项目将带来的好处而欢欣鼓舞之前，早一些了解项目的不利一面（它的风险和成本）总是好的。
最后，小组成员对项目是否值得进行和是否可行达成一致意见。这是“进行或终止”的决定。在早期取消一个项目似乎很残忍，但我们从痛苦的经验中得知，与其经过数月或数年的搏斗，消耗掉有价值的资源而又没有成功的机会，不如在项目早期就取消它。
或者，如果此时还有许多未知的东西，启动小组可以决定开始需求调研，不久后再来复查需求，重新评估项目的价值。
在为新项目将带来的好处而欢欣鼓舞之前，早一些了解项目的不利一面（它的风险和成本）总是好的。
参考阅读
DeMarco,Tom,Tim Lister.Waltzing with Bears: Managing Risk on Software Projects.Dorset House,2003.
McConnell,Steve.Software tstimation: Demystifying the Black Art.Microsoft Press,2006.2.4 网罗需求
启动会议结束后，需求分析师们开始在工作中网罗，学习和理解它的功能性，即“这部分业务是做什么的”。为了获得方便性和一致性，他们将工作上下文图划分为一些业务用例。
每个业务用例都是一部分功能，这是工作正确响应一个业务事件所必需的。（这些术语很快就会全面解释。）每个业务事件都指派一名需求分析师（分析师几乎可以相互独立地工作），以便进行进一步更详细的研究。分析师采用一些技巧，如做学徒、场景分析和用例研讨会等，来发现工作的真正本质。第5章对这些技巧进行了详细描述。【关于业务事件、业务用例以及如何发现和使用它们的讨论，可参考第4章。】
网罗意味着发现需求。业务分析师与IceBreaker的技术人员坐在一起，听他们描述当前的工作，以及对希望的工作方式的想法。业务分析师也咨询其他感兴趣的利益相关者和主题事务专家（易用性、安全、运营、管理等方面的专家），以发现最终产品的其他需求。IceBreaker的业务分析师花了许多时间与气象学家和高速公路工程师在一起。【关于网罗活动的详细内容，可参考第5章。】
也许需求调研中最难的工作就是发现系统的实质。许多利益相关者不可避免地会谈到他们眼中的问题的解决方案，或表达他们在当前工作中的需要。而问题的实质是，拥有这个产品的底层业务的理由。或者，可以将它看做是工作的策略，或者想象在没有技术的情况下工作会是什么样子（也包括人）。关于系统实质的问题，第7章中会有更多讨论。【关于开发创新性产品，可参考第8章。】
在理解了工作的实质之后，分析师们与关键利益相关者一起工作，决定改进工作的最佳产品。也就是说，他们确定多少工作需要自动化或改变，以及这些决定会对工作产生什么影响。当需求分析师知道了产品的范围，就为它编写需求。我们在图2-3中展示这个过程。图2-3 启动会议确定了待改进工作的范围。业务用例可以通过这个范围图导出。每个业务用例都由需求分析师和相关的利益相关者进行研究，以发现期望的工作方式。在理解了这些之后，就可以确定适合的产品（PUC场景），并写下需求或用户故事
IceBreaker产品不能简单地将现在完成的工作自动化，最好的自动化产品不只是对原有情况的模仿。为了交付真正有用的产品，分析团队必须与利益相关者一起创新，也就是说，找到更好的完成工作的方式，并开发一个产品来支持这种更好的工作方式。他们举行创新研讨会，团队成员在会上使用创造性思维技巧和创造性触发物，产生关于最终产品的更新、更好的想法。
参考阅读
Maiden,Neil,Suzanne Robertson,Sharon Manning,and John Greenwood.Integrating Creativity Workshops into Structured Requirements Processes.Proceedings of DIS 2004,Cambridge,Mass.ACM Press.
Michalko,Michael.Thinkertoys：A Handbook of Creative-Thinking Techniques,second edition.Ten Speed Press,2006.
Robertson,Suzanne,and James Robertson.Requirements-Led Project Management.AddisonWesley,2005.2.5 快而不完美的建模
模型可以用于Volere生命周期的任何时候。在图2-1中，我们将这种活动表示为“为工作做原型”。当然，你可以看到一些正式的模型，用UML或BPMN制作的，但许多时候业务分析师可以有效地利用快速的草图，对调研的工作进行建模。这里我们要提到一种快而不完美的建模技术，就是使用即时贴来对功能建模，每张贴纸可以用于表示一个活动，贴纸可以快速地重新安排，展示工作目前完成的方式和可能完成的方式。我们发现，利益相关者将这种建模方式与他们的业务过程联系起来，总是愿意参与，亲手安排贴纸，说明他们认为工作应该是怎样的。我们将在第5章“工作调研”中详细讨论这种建模方法。
在第8章中，我们探讨如何转入实现已经发现的需求。此时，你的模型就从解释当前的工作，变成解释将来的产品将如何帮助工作。
我们现在可以称这类模型为原型，是潜在产品的快而脏的展现形式，使用的工具是笔和纸、白板或其他熟悉的方式，如图2-4所示。这个阶段使用的原型，目的是向用户展示可能实现的需求的模拟。IceBreaker的业务分析师勾画出一些建议的界面，以及需要的功能的可能实现方式。这种可视的工作方式，让工程师和其他利益相关者的想法融合在未来的产品中。图2-4 白板上随手画出的原型，对可能实现的需求提供了快速的视觉解释，并澄清一些误解或遗漏的需求2.6 场景
场景非常有用，所以我们用第6章整章来讨论。场景展示了业务过程的功能性，将业务过程分解为一系列容易识别的步骤，用英语写成（或任何你在工作中使用的语言），所有的利益相关者都可以参与讨论。IceBreaker的分析师用场景来描述业务过程，并展示他们对所需功能的理解。然后这些场景会根据需要修改，不同的利益相关者对场景的不同部分感兴趣。在较短的时间后，业务分析师就能让每个人理解工作要做什么，并达成一致意见。
在他们达成一致之后，场景就成为需求的基础。【关于使用场景的详细讨论，参考第6章。】2.7 编写需求
系统开发的一个主要问题就是需求被误解。为了避免误解，分析师必须以一种无二义的、可测试的方式写下需求，同时确保提出需求的利益相关者理解并同意写下的需求，然后再传递给开发者。换言之，分析师编写需求是为了确保参与开发的各方对需要做的事达成一致的理解。
虽然写下需求可能看起来是繁重的负担，但是我们发现这是确保记录和沟通需求实质的最有效方式，也确保交付的产品可测试（参见图2-5）。图2-5 需求以书面的形式记录下来，以使利益相关者、分析师和开发者（以及其他有兴趣的人）之间能够有效地沟通。通过仔细写下这些需求，团队确保构建正确的产品
IceBreaker的分析师从用业务的语言编写需求开始，这样不懂技术的利益相关者才能理解这些需求并检验这些需求的正确性。他们为需求添加了“理由”，这说明了需求的背景理由，这消除了许多二义性。而且，为了确保彻底的准确性，也为了确保产品设计者和开发者能够准确地实现利益相关者的需求，他们为每项需求添加一个“验收标准”。验收标准是对需求的一种量化或测量指标，让需求可测试，这样测试人员就可以确定实现的产品是否满足了需求。
理由和验收标准让业务的利益相关者更容易理解需求，他们有时候会说：“我不想要任何我不懂的需求，我也不想要没用的、对工作没贡献的需求。我想理解它们的贡献。这就是我希望每项需求都有理由，并且可测量的原因。”
对于测量需求，业务分析师有一不同的、互补的理由：“我需要确保每项需求都没有二义性，对于提出它的利益相关者和实现它的开发者都是一样的意思。我也需要确保按照利益相关者的预期来测量需求。如果我不能对它进行测量，那就永远无法判断构建的产品是不是利益相关者真正需要的。”【第12章详细描述了验收标准。】
分析师使用了两种机制，使编写需求规格说明的工作更容易。第一种机制是需求规格说明模板，它是需求规格说明的一个提纲。业务分析师用它作为一个检查清单，检查哪些需求应该询问，同时也作为组织需求文档的一致的方式。第二种机制是需求项框架，也称为“白雪卡”。每项原子需求（最低层的需求）都由一些属性组成，白雪卡是一种方便的方式，确保每项需求都有正确的组成要素。【编写需求的详细讨论，参见第10章、第11章、第12章和第16章。】
当然，编写过程并非真的是一项独立的活动。实际上，它与围绕它的一些活动（网罗需求、制作原型和质量关）是集成在一起的。但是，为了理解如何将正确的需求变成可沟通的形式，我们将单独来看它。
迭代式开发方法采用“用户故事”作为传递需求的方法。这些故事实际上是低层需求的占位符。它们在开发者和利益相关者的对话中得到扩充，从而发现详细的需求。在第14章“需求与迭代开发”中，我们将详细讨论业务分析师如何能得到更好的用户故事。迭代式工作并不排斥需求，而是寻求另一种方式来发现和沟通需求。
想编写需求，主要不是为了得到书面的需求（虽然这常常是需要的），而是去“写”需求。写需求这个活动，以及与之相关的理由和验收标准，澄清了编写者对需求的看法，用无二义的、可验证的方式确定下来。换句话说，如果业务分析师不能正确地编写需求，他就没有理解需求。2.8 质量关
在产品开发周期中，需求是后面所有工作的基础。因此有理由断定，要想构建正确的产品，需求在交给设计者/开发者之前必须保证正确。为了确保正确性，质量关对需求进行检查（参见图2-6）。质量关是一个单点，每项需求都必须通过它，才能成为需求规格说明的一部分。质量关通常由一到两个人组成，可能是首席需求分析师和一个测试人员，只有他们有权允许需求通过质量关。在允许需求加入需求规格说明之前，他们一起检查每项需求的完整性、相关性、可测试性、一致性、可追踪性和其他一些质量属性。【第13章描述了质量关怎样检查需求。】
确保质量关是需求传递给开发者的唯一通道，这样项目团队就能控制需求，没有绕过去的通道。图2-6 在每项需求传递给开发者之前，质量关测试每项需求的完整性、正确性、可度量性、无二义性和其他一些属性，确保它是严格的2.9 复用需求
构建的任何产品的需求都不会是完全独一无二的。我们建议在开始任何新需求项目之前，浏览一下以前项目的规格说明书，寻找潜在可复用的东西。有时会发现许多需求是可以复用的，不用进行修改。更常见的情况是，会发现一些需求尽管不完全是所想要的东西，但它们可以作为写入新项目的需求的基础。
例如，在IceBreaker项目中，道路工程的规则在不同的产品中是一样的，因此需求分析师不必再重新发现这些需求。他们也知道卡车调度的业务在每一年里变化不会很大，所以他们的需求网罗过程可以利用以前项目的一些需求。
类似地，在一个组织机构的不同项目中，非功能需求是相当标准的，因此分析师可以从以前项目的规格说明书开始，把它作为一个检查清单。【第15章讨论了复用需求。】
复用需求的要点是，一旦成功地确定了产品需求，并且产品本身也是成功的，那么需求就不需要重新开发。在第15章中，我们讨论了如何利用组织机构中已有的知识，还讨论了如何通过复用以前项目的需求来节省时间。2.10 复查需求
质量关存在的目的是将不好的需求拒之门外，但是它一次只处理一项需求。当考虑需求规格说明是否完整时，应该对它进行复查。最终的复查会检查是否存在遗漏的需求，保证所有的需求相互一致，需求与需求之间没有悬而未决的冲突。简而言之，复查工作确保规格说明书是完整的、恰当的，这样可以转向下一个开发阶段。【关于复查规格说明书的更多内容参看第17章。】
复查也为重新评估产品的费用和风险提供了一个机会。既然拥有一份完整的需求集，对产品的了解就比启动会议要更多。特别是，对产品的范围和功能有了一个更准确的认识，所以这就是重新估计产品规模的时候。根据产品的规模，以及你所知道的项目的限制条件和解决方案架构，可以预估构建该产品的费用。
在这个阶段你也会知道，哪些类型的需求会导致巨大的风险。例如，用户可能要求一种你的组织机构从来没有构建过的界面。或者他们不得不使用从未试验过的技术来构建产品。开发方是否有人力能够构建指定的产品？通过此时重新评估风险，就更有机会成功地构建期望的产品。2.11 迭代和增量过程
在需求业界有一项常见误解，认为必须先收集所有的需求，才能够进入到下一步的设计和构建工作。换言之，做需求就意味着采用传统的瀑布式过程。在某些环境下这样做是必须的，但并非总是这样。一方面，如果打算外包，并且需求文档构成了合同的基础，那么很显然需要完整的需求规格说明。另一方面，如果总体架构已知，构建工作就可以在全部需求收集完成之前开始。图2-7中展示了这两种方式，建议你在做自己的需求项目时，考虑哪一种方式最合适。在第9章“今日业务分析策略”中，我们对不同方法进行了更多的讨论。图2-7 许多不同开发生命周期中的两种。图的上部是传统瀑布模型，得到完整的需求文档后再开始产品开发；图的下部是迭代过程，在初步分析之后，产品以小的增量进行开发。两种方式实现同样的目标
在IceBreaker项目中，开发者已经准备好开始构建产品了，所以
试读结束[说明：试读内容隐藏了图片]