STC（美国技术通信学会）卓越奖获得者，国际业务分析师协会CBA兼执行VP推*。
敏捷开发和大数据时代的软件需求百科*书！
一流业务分析师，项目经理，产品经理/产品负责人，创业CEO，商业顾问/咨询的工具和参考书。
特色：
这本经典名著经过需求领域两大领军人物的联袂打造，得以*面升级和扩展，包含更多、更新的主题、实例和洞见。通过本书介绍的需求工程实践、工具和技术，读者可以提升需求引导、捕获、开发、管理和分析能力，并把这些行之有效的技术与技巧运用到工作当中，在尽可能减少成本、增强维护性和避免返工的同时，交付定位更准确、质量更优良的软件产品/服务。
特色主题：
准确锁定关键的利益干系人并与他们展开合作
聚焦于业务目标，对需求进行引导和分析
需求的文档、优先级排定、验证和重用
原型和创建需求的可视化模型
管理变更申请、范围蔓延和需求风险
理解和明确指定客户质量需求
针对数据需求和报表类需求提供指导
第3版特色：
包含*新的实例、实践与技术，体现需求领域的新进展
凝聚需求领域两大领军人物多年的心血，素材来自培训课程、演讲和工作坊，有实操性
循序渐进，阐述如何将有效需求实践应用于敏捷项目和其他各种特殊项目，比如业务流程自动化、软件包方案、外包、增强型、替换型和嵌入式系统等项目
重点聚焦于业务分析师的角色和成功业务分析师应该具备的核心竞争力
尤其适合业务分析师、开发人员、项目经理和其他软件项目干系人阅读和参考
作为经典的软件需求工程畅销书，经由需求社区两大知名领袖结对*面修订和更新，覆盖新的主题、实例和指南，*方位讨论软件项目所涉及的所有需求开发和管理活动，介绍当下的所有实践。书中描述实用性强的、高效的、经过实际检验的端到端需求工程管理技术，通过丰富的实例来演示如何利用实践来减少订单变更，提高客户满意度，减少开发成本。书中的用例、业务规则和商业工具*面修订以体现现状和未来的趋势。
本书尤其适合具备一定软件开发过程经验的业务分析师、需求分析师、项目经理和其他软件项目涉众。
第1章
软件需求的本质
“喂，Phil吗？我是人事部的Maria。我们在使用你开发的人事系统时遇到一个问题。有位职员刚刚把她的名字改成Sparkle Starlight，但我们无法在系统中改。你能帮个忙吗？”
“那么她是结婚了，随老公姓Starlight？”
“没有，她没结婚，只是改名字了，”Maria回答道，“问题就出在这里。好像我们只能在某人婚姻状况发生变化时才能在系统中改名。”
“好吧，是，我从来没想过有人可能会改自己的名字。当初我们在讨论系统的时候，你可没告诉过我有这种可能性。” Phil答道。
“我以为你知道任何人随时都可以合法更改名字呢，”Maria回应道，“我们得在星期五之前解决这个问题，否则Sparkle就领不到工资了。你可以在此之前修复这个bug吗？”
“这不是什么bug，好吗？！” Phil反驳道，“我从没想过你们需要这项功能。我现在正忙着做一个新的绩效评估系统。你所说的问题我只能在月底修复，但周五之前肯定不行，抱歉。下次如果再有类似情况，请早点告诉我，并请提供书面材料。”
“那我怎么和Sparkle说呢？”Maria追问道，“如果她领不到工资，会很难过的。”
“嗨，Maria，这不是我的错，”Phil抗议道，“如果当初你早提醒我你需要能够随时更改某人的姓名，这种事情就不会发生。你不能因为我没猜透你的想法就怪我。”
Maria怒了，但又无可奈何，只好厉声说：“是，你说的都对！好吧，这种破事儿让我对电脑简直是恨之入骨。问题解决好了，就马上打电话告诉我，可以吗？”
如果你是以上对话中的客户一方，就会明白无法使用软件系统来完成一项基本任务多么令人沮丧。你会痛恨自己得求着开发人员，因为关键变更请求最终掌握在他们手中。另一方面，开发人员也很沮丧，因为他们只有在系统开发完成之后才会明白用户期待有哪些基本功能。对于开发人员来说，更恼火的是，得中断手头的项目去修正以前已经完成的系统（因事先未被明确告知而疏忽的需求）。
软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当。就Phil和Maria这个例子而言，问题就包括：信息收集不正规；功能隐晦；对假设功能有理解上的分歧；需求指定不明确以及变更过程不正规。很多研究表明，软件产品中发现的缺陷有40%～50%是在需求阶段埋下的“祸根”（Davis 2005）。在具体说明客户需求和管理客户需求过程中用户输入不足和有误，是造成项目失败的罪魁祸首。尽管证据确凿，但很多组织仍然在实行这些没有什么成效的需求方法。
在软件项目中，所有干系人的利益交接点主要集中在需求方面。（更多干系人方面的内容，参见第2章）这些干系人包括客户、用户、业务分析人员和开发人员等。如果处理得当，这种交接既可以让客户满意，又能鼓舞开发人员。若处理不当，则会引发误解和摩擦，最终降低产品质量和业务价值。正是由于需求是软件开发和项目管理活动的基础，因此所有干系人都应该致力于需求实践活动，这是打造一流产品的前提。
但开发和管理需求确实很难！既没什么捷径，也没有任何灵丹妙药。另外，很多组织都在朝着一个目标努力，要找到一种能适应不同情景但又有共性的技术。本书后面将讲到很多这样的实践。这些实践假定你正在开发一种全新的系统。但是，它们中的多数也可用于改进、替换以及重构项目（详见第21章），还可以用于融合商业现成品的（COTS）打包解决方案项目（详见第22章）。即使项目团队遵循敏捷开发过程渐进式构建产品增量，团队也要理解每一个增量所涉及的需求（详见第20章）。
本章将帮助你：
* 理解软件需求领域所用的一些关键术语；
* 区分产品需求和项目需求；
* 区分需求开发和需求管理；
* 警惕可能出现的与需求相关的一些问题。
给自己的需求把把脉
要想对组织中现有的需求实践做一次快速体检，就对比下列问题，看看有多少条出现于你最近的项目中。如果其中有三四条以上与你的经历相符，那么本书就是为你量身定做的。
* 从来没有清晰制定过项目的业务目标、愿景和范围。
* 客户太忙，没有时间与分析师或开发人员共同处理需求。
* 团队无法与用户代表直接互动，不理解他们的具体需要。
* 客户认为所有的需求都很关键，因此没有对需求排定优先级。
* 开发人员在写代码时遇到了模棱两可或者遗漏的信息，所以只能靠猜。
* 开发人员与干系人沟通的重点集中于用户界面展示或者特性，并没有关注用户要使用软件完成的具体任务。
* 需求从来没得到过客户的认可。
* 客户认可了某个发布或者迭代的需求，但事后又不断更改。
* 不断接受客户的需求变更请求，项目范围随之扩大，由于没有增加资源或者删减功能，进度最后完全被打乱。
* 有人提出了变更请求，但被忽略，没人知道特定变更请求的具体状态。
* 客户提出特定的功能要求，而且开发人员也建好了，但就是没有人用过。
* 在项目接近尾声时，虽然满足规范说明，却不满足客户或业务的目标。
软件需求的定义
人们在讨论需求时，开始经常会遇到专业术语问题。人们从不同的角度阐述同一样东西，例如：用户需求、软件需求、业务需求、功能需求、系统需求、产品需求、项目需求、用户故事、特性或者约束条件。人们又赋予了不同的需求交付物多种称谓。对于开发人员来说，客户所定义的需求听起来更像是一种高级产品概念。对于用户来说，开发人员所说的需求理念可能听起来更像一种具体的用户界面设计。这种理解上的偏差让人困惑，令人沮丧。
关于“需求”的一些解释
即使计算机编程技术已经有很多年头，软件从业者仍然在激辩“需求”的准确定义。我们不想在本书中继续这种争论，只想从实用定义的角度简单表述一下。
顾问布莱恩·劳伦斯（Brian Lawrence）认为，需求是“任何能够驱动设计做出选择的东西。”这种口语化定义不错，因为很多信息都印证了他的说法。毕竟，开发需求的目的就是要做出合适的设计选项，最终满足客户需要。另外一种定义认为需求是产品所必备之属性，目的是向干系人提供价值。这也没错，但不太准确。我们比较倾向于Ian Sommerville and Pete Sawyer （1997）所提出的观点：
需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。
这个定义认为“需求”是多种不同类型的信息的统称。需求涵盖来自客户视角的外部系统行为以及来自开发人员视角的一些内部特征。它们包含系统在特定条件下的行为和属性，使目标用户觉得系统易于甚至乐于上手。
字典中的“需求”
字典对“需求”的解释为：“被命令或者强制性的东西；需要或者必要。”这与软件界所使用的“需求”不是一个含义。人们有时会怀疑是否有必要对需求进行优先级排序，因为有的低优先级需求可能永远不会被实现。人们认为如果对某些东西的需求不是太强烈，就说明它们不是需求。可能是这样，但我们管这类信息叫什么？如果将当前项目中的需求推迟到未来某个不确定的发布之中，它还是需求吗？当然是。
软件需求包含一个时间维度。它们可能是描述目前系统性能的现在时。或者它们可能是近期（高优先级）、中期（中等优先级）或者想象中（低优先级）的未来。甚至可能是过去时，也就是那些曾经被人指定但后来又被舍弃的需要。我们没必要浪费时间争论某个东西是否是需求，即使知道自己会为了某个合理的业务原因而永远不执行它。需求就是需求。
需求的层次和种类
由于有很多不同类型的需求信息，所以我们现在需要用一组形容词来修饰一下被人们赋予太多意义的“需求”。表1-1列出了需求领域的一些常用术语。
表1-1 一些类型的需求信息
术语
定义
业务需求
开发产品的组织或者获取产品的客户所需的高层次业务目标
业务规则
策略、纲领、标准或者制度，能够定义或者约束某些方面的业务。虽然本身并不是软件需求，但它却是一些类型的软件需求的鼻祖
约束
对开发人员在产品设计和构建上的限制条件
外部界面需求
对软件系统和用户、其他软件系统或硬件设备间的关联进行说明
特性
单个或者多个为用户提供价值的、有逻辑关系的系统性能，可以通过一个功能需求集合进行描述
功能需求
描述系统在特定条件下展现的行为? 续表
术语
定义
非功能需求
描述系统必须展现的属性或者特性，或者必须遵守的约束
质量属性
一种非功能需求，描述的是服务或者一个产品的性能特征
系统需求
包含多个子系统的产品的顶层需求，子系统可以是软件，也可以是软硬件
用户需求
特定用户群必须能够用系统所完成的目标或任务，或者是用户期望有的产品属性
软件需求有三种不同的层次：业务需求、用户需求和功能需求。此外，每个系统都包含某种类别的非功能需求。不同种类的需求如图1-1中的模型所示。正如统计学家乔治E.?P.?巴克斯（George E. P. Box）的一句名言所述：“从本质上讲，虽然一切模型都是错误的，但有些还是有作用的。”（Box and Draper 1987）。这句话用来形容图1-1真是恰如其分。这个模型也许并不全面，但提供的方案非常实用，可以帮助组织需求方面的知识。
图1-1所示椭圆中的内容代表需求信息的种类，长方形表示储存信息的文件。实线箭头表示具体类型的信息通常储存于所示文件之中。（业务规则、系统需求应与软件需求独立存储，例如存储在业务规则目录或者系统需求规范说明之中。）虚线箭头代表一种信息起源于或者受另外一种信息的影响。此图没有具体展示数据需求。数据受控于功能，因此数据需求贯穿于这三个层次的需求之中。第7章有很多这些不同种类的需求信息的示例。
图1-1 各类需求之间的关系。实线代表“被存储于”；虚线代表“起源”?或“影响”
业务需求描述组织为什么要执行系统（组织希望获得的业务收益）。其关注点在于组织或者提出系统要求的客户有哪些业务目标。我们假设有家航空公司打算把机场的柜台工作人员成本降低25%。为此，人们通常想到的是建一个自助服务终端，供乘客在机场自行检票。项目的出资方、目标客户、实际用户的管理层、市场部门或者产品规划部门一般都会有业务需求。我们喜欢将业务需求记录在愿景或者范围文件之中。还有一些战略性指导文件有时也会用于此目标，包括项目图表、业务实例以及市场（或者营销）需求文件。第5章的主要内容是对业务需求进行详细说明。考虑到本书的主旨，我们假定已经确定了业务需求或市场机遇。
用户需求描述了用户使用产品必须完成的目标或者任务，并且这个产品要能够为人提供价值。用户需求主要还包括对用户满意度最为关键的产品特性或特征的描述。用例（Kulak and Guiney 2004）、用户故事（Cohn 2004）以及事件响应表都是用户需求的表示方式。理想状态下，这种信息由实际用户代表提供。用户需求表达的是用户通过系统来完成哪些具体工作。通过航空公司网站或者机场自助检票机“办理登机手续”是“用例”的典型例子。如果将其写为“用户故事”，同样的用户需求可能是这样的：“作为一名乘客，我想办理登机手续，以便能够登机。”还有一点我们不能忘记，即大多数项目都有若干个用户类别和其他干系人，我们还必须获取它们的需求。第8章将对这种层次的模型进行解释。有些人喜欢用“干系人的需求”这个更广义的术语来说明各类干系人比直接客户更能提供需求。这当然没有问题，但是我们要在这个层级集中注意力，理解实际用户要用这个产品完成哪些具体目标。
功能需求说的是产品在特定条件下所展示出来的行为，主要描述开发人员需要实现的功能以便用户能够完成自己的任务（用户需求），进而满足业务需求。这三种需求环环相扣，对项目的成功至关重要。人们经常将功能需求记录为传统意义上的“应当”句式：“乘客应当能够随时打印自己已经办好登机手续的所有航段的登机牌”或者“如果乘客信息没有指定座位偏好，航班预订系统就应当为它分配。”
业务分析师（BA）①将功能需求记录在软件需求规范说明（software requirements specification，SRS）之中，尽可能详尽地描述人们对软件系统的预期行为。SRS用于开发、测试、质量保障、项目管理和相关项目功能。它的称谓很多，包括业务需求文件、功能规范说明、需求文件等。SRS可以是一个报告，由存储在需求管理工具中的信息所生成。由于它已成为一种行业标准术语，所以我们在本书中将其统称为“SRS”（ISO/IEC/IEEE 2011）。要想进一步了解SRS，请参见第10章。
系统需求描述了人们对某个产品的需求，而这个产品由多个组件或者系统子集组成（ISO/IEC/IEEE 2011）。“系统”在此不单单是信息名义上的系统。所有软件或软件、硬件系统子集都可以算是系统。甚至人和过程也是系统的一部分，因此某些特定的系统功能可以分配给人。有些人使用“系统需求”这个词来表达对软件系统的具体需求，但我们在本书中并不这样使用该术语。
超市收银员的工作台算是“系统”的一个典型例子。超市里有与称重设施相连的条形码扫描仪和手持式条形码扫描仪。收银员有键盘、显示器和现金抽屉。我们在超市里面还可以发现用于刷积分卡、信用卡或者借记卡的读卡器和PIN盒，甚至还有自动找零机。甚至还可以看到三台打印机分别打印购物小票、信用卡签单和优惠券，只不过这些对你来说无关紧要。这些硬件设备都在软件控制下互相关联。随后，业务分析师根据系统或者产品的整体需求提取具体功能，将其分配给这些组件系统子集中的某一个，同时了解它们之间的接口。
业务规则包括公司政策、政府法规、工业标准以及计算算法。在第9章中，将说明业务规则本身并不是软件需求，因为它的存在已经超出了任何特定软件应用的范围。然而，它们又经常决定着系统为了切合相关规则而必须包含哪些功能。正如公司安全策略一样，业务规则有时又引申出具体的质量特性，这些特性又以功能的方式由开发人员实现。因此，特定的功能需求可以追溯到具体的业务规则。
除了功能需求，SRS还包含某些类别的非功能需求。质量属性也被人们称为质量因子、服务需求质量、约束以及“***性”。它们从不同角度描述产品特征，例如性能、安全性、易用性和可移植性，这些对于用户、开发人员和维护人员来说都非常重要。还有一些非功能需求描述系统与外部世界的接口，包括与其他软件系统、硬件组件、用户以及沟通界面的关联。在创建产品的过程中，开发人员的选择受限于设计和实现约束。
非功能需求到底是什么？
要想对组织中的现有需求实践做一次快速体检，就需要对比下列问题，看看有多少条出现于你最近的项目。如果其中有三四条以上与你的经历相符，那么本书就是为你量身定做的。
在项目接近尾声时，虽然满足了规范说明，却不满足客户或业务的目标。
多年以来，人们从广义上将软件产品需求分为功能需求或者非功能需求。功能需求理解起来很容易，它们描述的是系统在不同条件下能够被用户观察到的行为。然而，大多数人都不喜欢“非功能”这个术语。因为这个形容词强调的是需求不是什么，并没有说明需求是什么。很遗憾，对于这个问题，至今没有一个令人满意的答案。
功能之外的需求强调的并不是系统要做什么，其重点在于系统做得有多棒。它们对系统最重要的特征或属性进行描述，包括系统的易用性、易用性、安全性和性能等很多特征，这些都在第14章中有所体现。有些人将非功能需求等同于质量属性，但这过于狭隘。例如，设计和实现约束也是非功能需求，外部接口需求也是。
还有其他一些非功能需求，它们描述的是系统运行环境，例如平台、可移植性、兼容性和约束。很多产品还受兼容性、监管和发行许可的影响。我们甚至还要考虑到产品的地域性需求，例如用户的文化、语言、法律、货币、专有名词、拼写和其他特征。虽然此类需求被归入功能需求，但业务分析师仍然可以从中获得大量的功能，确保系统的所有行为和属性符合用户的预期。
尽管有其局限性，但由于没有一种合适的替代选项，所以我们在本书中仍使用“非功能需求”这一术语。这类信息的名称是否准确并不重要，但要保证将它们纳入需求获取和分析活动。交付的产品虽然囊括所有预想的功能，但用户还是不喜欢，因为它不符合人们对其产品质量（通常未明确表达）的预期。
一个特性包含一个或者多个逻辑上有关联的系统功能，能够为用户提供价值，这些由一组功能性需求来共同描述。客户预想的产品特性清单与描述客户的任务相关的需求不能画等号。网页浏览器的书签、拼写检查、为运动器械设定定制锻炼程序、杀毒软件中病毒库的自动升级，这些都是典型的特性。特性包含多种用户需求，每种需求都表示特定的功能需求必须实现，以便用户能完成用户需求中所描述的任务。图1-2就是一个特性树，也可以说是一个分析模型，展示的是特性如何层层分解为更小的特性组，这些小特性与具体的用户需求关联，最终引出功能需求（Beatty and Chen 2012）。
图1-2 特性、用户需求和功能性需求之间的关系
为了解释这些不同类型的需求，我们假设在开发某个文本编辑程序的新版本。“在6个月内将非美国地区的销量增加25%”可以算是一种业务需求。市场部发现参与竞争的产品只有英语拼写检查器，因此他们决定新版本要包括一个多语种拼写检查器特性。对应的用户需求可能包含诸如“为拼写检查器选择语言”“发现拼写错误”和“将词添加到字典”这样的任务。拼写检查器有很多独立的功能需求，涉及的操作包括高亮拼写错误的单词、自动纠错、显示建议替代选项、用正确的单词整体替代拼写错误的单词。易用性需求明确指定如何使用特定语言和字符集来定位软件的使用区域。
……
简明目录
第Ⅰ部分软件需求的3W（什么、为什么和谁）
第1章软件需求的本质3
第2章从客户角度审视需求22
第3章需求工程优秀实践38
第4章业务分析师53
第Ⅱ部分需求开发
第5章建立业务需求67
第6章倾听用户的心声89
第7章需求获取105
第8章理解用户需求127
第9章照章办事147
第10章记录需求160
第11章写出优秀的需求178
第12章一图胜千言196
第13章具体指定数据需求218
第14章功能需求以外233
第15章通过原型来减少风险264
第16章要事优先：设定需求优先级279
第17章确认需求293
第18章需求的重用312
第19章需求开发之外325
第Ⅲ部分具体项目类别的需求
第20章敏捷项目341
第21章改进型和替换型项目349
第22章软件包方案项目359
第23章外包项目367
第24章业务过程自动化项目372
第25章业务分析项目378
第26章嵌入式和其他实时系统项目388
第Ⅳ部分需求管理
第27章需求管理实践403
第28章需求变更415
第29章需求链中的链接432
第30章需求工程工具442
第Ⅴ部分需求工程的实施
第31章改进需求过程455
第32章软件需求和风险管理472
尾声483
附录A当前需求实践自评485
附录B需求问题问诊指南491
附录C范例需求文档507
词汇表525
参考文献533
作者简介547
专家推*：
“业务分析领域的经典著作之一，第3版尤其体现了这一专业领域过去十年的进展和新趋势。”
——Kevin Brennan， IIBA（国际业务分析师协会）*席业务分析师兼执行副总裁
“软件需求的百科*书。”
——清华大学教授，中国软件行业协会过程改进分会名誉副会长
好书热评
《软件需求（第3版）》是目前非常有用的需求指南。两位作者Wiegers和Beatty覆盖了目前业务分析师应该知道的实践*景。无论是需求规范的老手，还是刚开始做项目的新手，都可以将本书作为桌边案头的必备参考书。
——Gary K. Evans，Evanetics公司敏捷教练和用例专家
.
这简直就是三连冠，Karl Wiegers和Joy Beatty携第3版再创佳绩。从1999年第1版起，《软件需求》提供的指南就已经成为我在需求咨询工作中的实践基础。我要向新手和有经验的从业人员鼎力推*此书。
——Roxanne Miller，Requirements Quest总裁
需求方面很好的书，又更上了一层楼！在第3版中，新主题的范围延展到覆盖整个项目场景。在敏捷环境中使用需求很有意义，因为所有相关人员都要了解新系统的基本功能和用途，并且敏捷开发人员现在也是受众，必须好好掌握书中的内容。
——Stephen Withall，《软件需求模式》作者
《软件需求（第3版）》终于问世，长久的等待是值得的。这是一本完整的实践指南，读者可以从中学到许多对工作有用的实践。我特别喜欢书中包含的例子和很多实操方案，可以方便地在真实生活场景中实践它们。
——Christof Ebert博士，Vector Consulting Services管理总监
Karl和Joy升级了软件需求领域的开创性著作，对上一版择其优并加以改进。这一版保留了此前版本中所有业内人员必备的参考，还扩展到足以应对当今复杂商业和技术环境所面临的挑战。不论什么技术、业务领域、方法论或项目类型，都可以借助本书向客户交付更好的成果。
——Shane Hastie，Software Education*席知识工程师
Karl Wiegers和Joy的这本有关需求的新书对前一版进行了精彩的补充。大型软件应用的需求是本世纪难以解读的业务话题之一。此书有助于解读这一粗略的主题。
——T. Capers Jones，Namcook Analytics公司副总裁兼CTO
简单地说，对于每个参与定义和管理软件开发项目的人（这本书既是必读之书，又是一本重要的参考。在今天的现代软件开发世界中，太多人认为需求实践是用于“无障碍”敏捷的。Karl和Joy对渐进管理需求的方法进行详细说明，并阐述了如何采用日新月异的方法实现软件交付。
——Mark Kulak，Borland公司软件开发总监
我看到Karl Wiegers和Joy Beatty*面更新了这本有关软件需求的书。我特别喜欢其中如何在敏捷项目中使用高效需求实践的新话题，因为近日来，我们这方面的咨询服务越来越多。这些在不同需求实践中的实践指南和真实案例是无价之宝。
——Doreen Evans，Robbins Gioia公司需求和业务分析实践管理总监
作为Karl经典好书《软件需求》的早期用户，我对新版早就迫不及待，望穿秋水了，而且它绝对没有让我失望。多年以来，从大型的、新型的零起点项目，到采用现成的商业现货方案和快速发布敏捷实践，IT开发的重点已经发生很大的变化。在第3版中，Karl和Joy探讨了这些新开发方法在需求过程中的内涵，还给出了宝贵的建议，这些建议不是基于教条的，而是从他们在需求领域广泛而深入的经历提炼出来的有效实践。
——Howard Podeswa，Noble公司CEO，《业务分析师手册》作者
如果要找一本实践指南来了解什么是软件需求、如何创建需求以及如何使用需求，《软件需求（第3版）》是不二之选。这本书的内容有用、易懂，可以带你完整了解如何应对需求相关的一般场景。结合许多故事、案例研究、趣闻轶事和实例，这本书读起来引人入胜。
——Laura Brandenburg，CBAP（认证业务分析师），Bridging the Gap站长
怎样才能使好需求容易理解？在添加内容时，可以像Karl和Joy所做的那样，确立*面的产品愿景，处理敏捷方面的问题，尽可能重用需求，处理软件包和外包项目，确定具体用户类别。可以由表及里查看需求，解决流程和风险的问题，而不只是确定功能。
——Donald J. Reifer，Reifer Consultants公司总裁
本书新版随业务的发展与时俱进，既在第2版的基础上进行了深化，又让分析师真切了解到如何应对敏捷开发的大潮，如何使用特性进行范围控制，如何提升需求收集技术，如何开展建模。Wiegers和Beatty联袂打造的这本书是专业人士的必读经典。
——Keith Ellis，Enfocus Solutions公司总裁兼CEO，《业务分析标杆》作者
《软件需求》读后感系列之一-无题乱弹作者：淡淡如菊
好几年前，当我转型成为一名业务分析师时，我苦恼于自己并不十分懂得这个职位究竟要做什么，要怎么做，要怎么做好。所以我在网络上搜寻所有可以买得到的相关书籍，以求获得一些指导，其中也包括《软件需求》（第2版）。在那个时候，这本著作系统的知识点给了我很多启发，我尽量从似懂非懂到有样学样，在实践中去思考如何改进，然后再次去实践。不仅仅是*初阅读的时光，后续这几年的工作过程中，当我遇到一些需求相关的问题的时候，我也会重新打开这本书，翻阅相关的章节，以求回到*初的状态，去理解本源，并再次出发去解决当下的问题。这次拿到新鲜出炉的第三版，我的感受是，第三版很好地保留了之前的精髓，并在其基础上补充了很多关于敏捷开发流程的观点。这次也有非常强大的翻译团队，阅读的感觉更流畅，这是一本非常适合软件开发领域的从业人员阅读的书籍，尤其是对需求分析感兴趣的朋友。我的个人观点是业务分析师都应该拥有一本以备随时参考。
这次十多位朋友一起读这本书，大家在微信上展开了很多讨论，也激发了我的灵感，所以想提笔写一写打动我的一些章节。我不知道自己能否写一个系列，但我今天打算从业务分析师的培养说起，呼应本书第四章的内容。
书中提到业务分析师的培养可以是前用户，前开发人员和测试人员，前（或兼职）项目经理，主题专家或者菜鸟（新人）。不管哪一种角色，转型成为业务分析师，都会有各自的优势或者劣质，如果能发挥优势，改进薄弱环节，那么在成为一名成功的业务分析师的道路上就有了好的开始。现在我也有带领一个业务分析师团队，我们的团队成员有前开发人员，前测试人员，也有新人。我本人也是半路出家，是一名软件开发程序员转型过来的。我的理解是，软件开发过程中的每个角色都要或多或少具备软件需求分析的功能，而其中的业务分析师当然是*应该具备这个技能的工作。那么除了文中提到的不同的人员转型到这个工作的优势劣势以外，我就随便谈几点的想法吧：
为用户画像的潜意识需求分析的工作离不开和用户沟通，我们常常会说需求获取，但和用户沟通并不是一个简单的单方向从用户获取需求的过程。不同的业务分析师去和同一个用户聊，也许会得到完*不一样的需求。我还在做程序员的时候，因为当时的团队没有BA这个角色，所以老板派我去用户现场了解他们的工作内容。那会完*是菜鸟出场，也没有需求获取的技巧和技术可言。当我去到现场，接待我的是一位热情的前辈，因为对方很配合，所以进展还不错，然后有一天我决定在工作之余约她出去一起吃饭。吃饭的时候，大家都很放松，她跟我聊了很多，她从哪里来，为何选择了我们公司，她对工作的看法和期许，她每天花很多时间在上班路上的困扰，甚至还有她的宠物。饭局后，我还在现场呆了一段时间，我明显感觉到我的工作进展的更加顺利了，说不出是什么原因，但很显然彼此的信任增加了。后来，当我们开始去设计这个系统的时候，我会常常想到她，想象如果是她在用这个系统，她的反应会是怎样，她会觉得好用吗，她会困扰吗？当年的我并不明白，这个和用户沟通的过程就是一个实实在在为用户画像的过程，除了明白她的工作，我们更应该去了解用户真实的面目，不是要刨根问底，但你要理解她自身的一些和系统有关的状况。比如她的教育背景，她对电脑的熟悉程度，她对工作的成就感在哪里，如果系统能帮到她，她的幸福感在哪里。如果你在和用户沟通的过程中， 会为了这样的发现而喜悦，那么我想你会适合往业务分析师这个方向发展的。
解决需求问题的成就感我的*一份工作是软件工程师，当年有幸进入了一家提供电信行业解决方案的知名公司。加入公司一个月后，因为前辈们纷纷被挖角，我们几个菜鸟被迫上了*一线。当时摆在我们眼前的项目，就是某通信公司引入了*新制式的交换机，话单的采集和分拣程序需求需要重新梳理并参与测试评比。当时的新交换机厂商是北电网络，他们在国内的工程师只负责设备调试，对于系统的软件问题只能帮忙联系加拿大的工程师进行中间协调。我们能拿到的所有的文档都是英文的，内部更是充斥着大量的通信术语，语言的障碍以及对这个领域的不熟悉，是否能如期完成需求梳理，当时的我们觉得任务艰巨。为了尽快搞定这个需求工作，我一页页翻看这份文档，不懂的字句求助Google，不能理解的设计用邮件求助外国工程师，*后总算理出了话单生成的机制，采集的要求，以及话单的构成，并整理出详细的数据字典。后续的故事就是，我们一帮菜鸟基于自己的需求理解，开发完成了话单采集及分拣程序，我们的程序在各大厂商对新交换机处理能力的测评中，获得了处理速度快、准确度高的评价，荣登三甲。所以说，需求分析的工作，程序员也可以做好的。如果你是一位对于需求分析工作特别有兴趣的程序员，如果你也确实觉得这样的工作能给你带来成就感，那么不如适当的往这个方向历练一下吧。你可以选择转型，也可以只是将其作为自己成为项目经理必备的技能。我的理解是，不会分析需求的程序员不是好的项目经理。
所谓菜鸟有谁不是从菜鸟开始的呢？对于刚刚走出校门的人来说，成为一名业务分析师是进入信息技术领域的一个很好的切入点，优点在于他或者她对需求流程的工作原理几乎没有什么先入为主的概念。毕业生要学习的东西很多，工作职责，开发流程，理解开发人员、测试人员，了解用户，掌握基本的业务知识，懂得如何有效的获取需求。我们无法奢求一个刚走出校门的孩子，既懂得需求分析的知识，又掌握了实际的技巧。菜鸟要做的是，保持对这份工作的热忱，快速学习，快速成长。成为一名业务分析师所基本的知识，本书能给你*好的解答。至于技能吗，要在实践中掌握，希望本学习小组的各位能多点分享这部分啦。但**重要的，是菜鸟的心，可以是决心，信心，恒心，世上无难事只怕有心人。
(原文链接：http://www.jianshu.com/p/86437a10783d?utm_campaign=hugo&utm_medium=reader_share&utm_content=note&utm_source=weixin-friends&from=singlemessage&isappinstalled=1)