掌握需求过程

掌握需求过程1

（前篇）

本文论述了软件开发中的重要课题——如何得到正确的需求，向读者展示了需求收集和验证过程，为精确地发现客户所需所想提供了技巧。同时为传统、敏捷和外包开发提供了不同的策略指导。对客户价值、迭代式开发和故事卡片的讨论，利用验收标准让需求可测试，是在项目早期消除需求缺陷的好方法，通过各种检查清单，帮助识别利益相关者、用户、非功能需求，引入了Brown Cow模型，清晰地展现了“做什么”和“怎么做”的关注点分离。本文可作为软件开发人员在开发过程中随时参考的手册，对产品经理、系统分析师、软件开发者和测试者均有益。从以下几方面进行描述

基本事实

需求过程

确定业务范围

业务用例

工作调研

理解真正的问题

开始解决方案

业务分析测试

功能需求

非功能需求

验收标准和理由

质量关

需求与迭代开发

复用需求

沟通需求

需求完整性

第一章 基本事实

需求起始并非在谈需求 需求活动主要不是编写需求文档，相反，它专注于理解业务问题，并为之提供解决方案。

如果我们必须构建软件，那么它必须为拥有者提供最理想的价值。

如果软件不必满足要求，那怎么做都行，但是如果打算满足要求，就必须知道要求是什么，才能构建正确的软件。

构建一个软件和解决一个业务问题之间，存在巨大的差别，前者不一定实现或者。

需求不一定要写下来，但构建者必须知道它们。

客户不一定总能给你正确答案，有时候客户也不知道什么是对的，也不知道需要什么。

需求不是偶然得到的，要通过某种有序的过程得到。

你怎么迭代都可以，但仍需要理解业务的需求。

所有方法和工具都无法弥补糟糕的想法和糟糕的手艺。

要想成功地实现需求，需求就必须可度量、可测试。

作为业务分析师，你将改变用户思考问题的方式，不是现在就是将来。

功能需求是产品必须完成的那些事，非功能需求是产品必须具备的属性或品质，产品应该提供愉快的用户体验。限制条件是一个全局问题，约束着所有的需求，限制条件只是另一种类型的需求。

第二章 需求过程

不论是要构建用户定制的系统，还是构建组件集成的系统，或者使用商业上架销售的软件包，或者采用开源软件，或者将软件开发外包，或者对已有的软件进行升级改动，都需要发现、捕获和交流需求。要构建正确的产品，就要发现正确的需求。

项目启动——网罗知识——为工作做原型——编写需求——质量关——复用/复查需求——设计、构建——产品使用与演进

项目启动会议的主要目的是为接下来的需求发现工作奠定基础，并确保项目成功需要的所有东西都已到位，主要的利益相关者（客户、关键用户、首席需求分析师、技术和业务专家以及其他关键人物）聚在一起，对关键的项目问题达成一致意见。

启动会议结束后，需求分析师开始在工作中网罗，学习和理解它的功能性 。每个业务用例都是一部分功能，分析师通过场景分析和用例研讨会等来发现工作的真正本质。业务师用场景来描述业务过程，并展示他们对所需功能的理解，对调研的工作进行建模，可以有效地利用快速的草图，尽快和不同的利益相关者达成一致意见。接下来编写需求，者是确保记录和沟通需求实质的最有效方式，也确保交付的产品可测试，对每项需求添加验收标准，验收标准是对需求的一种量化或策略指标，让需求可测试。分析师使用两种机制，使编写需求规格说明的工作更容易。第一种机制是需求规格说明模板，第二种机制是需求项框架。为了确保正确性，质量关对需求进行检查，确保质量关是需求传递给开发者的唯一通道。复查工作确保规格说明书是完整的、恰当的，这样可以转向下一个开发阶段。当一部分需求成功通过质量关之后就可以启动开发工作了，同时需求分析师为下一优先级的用例搜集需求，进入迭代和增量开发过程。需求随着产品开发过程而演进，随着时间的推移，关于产品的需求变得精确、可测试。如果在编写需求时有一份指南，就会更容易、更方便。

项目驱动——描述项目的理由和动机
项目的目标——投资构建产品的理由以及希望取得的业务上的好处

客户、顾客和其他的利益相关者——产品涉及他们的利益或对他们产生影响

产品的用户——预期的最终用户以及他们对产品可用性的影响

项目限制条件——加在项目和产品上的约束条件

需求限制条件——项目的局限性和产品设计的约束条件

命名标准和定义——项目的词汇表

相关事实和假定——对产品产生一定影响的外部因素或开发者所作的假定

功能需求——产品的功能

工作的范围——针对的业务领域

产品的范围——定义预期产品的边界，以及它与相邻系统的连接情况

功能与数据需求——产品必须做的事情以及功能所操作的数据

非功能需求——产品的品质

观感需求——预期的外观

易用性和人性化需求——如果产品要让预期用户成功地使用，它必须是怎样的

执行需求——速度、大小、精度、人身安全性、可靠性、健壮性、可伸缩性、持久性和容量等需求

操作和环境需求——产品预期的操作环境

可维护性和支持需求——产品的可改动性必须达到什么水平以及需要怎样的支持

安全性需求——产品的信息安全性、保密性和完整性

文化和政策需求——人和社会因素

法律需求——满足适用的法律

项目问题——这些适用于构建产品的项目

开放式问题——那些尚未解决的问题，可能对项目的成功有影响

立即可用的解决方案——利用已有的组件而不是从头开发

新问题——引入新产品而带来的问题

任务——将产品投入使用必须要做的一些事情

迁移到新产品——从现存系统转换的任务

风险——项目最有可能面对的风险

费用——早期对构建产品的成本或工作量的估计

用户文档——创建用户指南和文档的计划

后续版本需求——可能在产品将来的发行版本中包括的需求

解决方案的想法——我们不想错失的设计想法

需求项框架，包括需求的各种属性，用于最初的需求收集工作：

需求编号:		需求类型:	模板类型	事件/BUC/PUC编号：	用例清单
描述：
理由：
来源：
验收标准：
客户满意度：		客户不满意度：
依赖关系：		冲突：
支持材料：	指出说明和解释这项需求的文档
历史：	创建、变更和删除等

我们从各种不同项目中提炼出我们的经验，提供一组适用于所有项目的基本活动和提交产物。

第三章 确定业务范围

如果要构建一个软件，它必须为拥有者提供最佳价值。产品开发生命周期的第一项任务就是定义工作的准确范围，工作的范围、外部世界中整个组织机构的范围以及项目要构建的产品的可能范围。

从环境中分离工作，分析工作上下文范围，工作上下文范围展示了工作的职责和相邻系统的职责起止之处。范围、利益相关者和目标不是独立确定的，工作范围说明了对工作感兴趣的利益相关者，利益相关者又决定了期望的项目结果即目标。利益相关者是需求的来源。项目目标是最高层次的需求。

目标——想达到什么目的

项目目标的主要方面

目标：关于产品要做什么的描述

好处：产品能提供怎样的业务好处

度量：如何对好处进行度量

合理性：考到的对限制条件的理解，产品是否可能实现业务好处

可行性：考虑到启动会议上得到的信息，产品能达到度量标准

可达到性：组织机构是否具备构建该产品的技能，在构建好之后是否能够操作它。

需求限制条件

需求限制条件是全局性的需求，有助于确定哪些需求子集可以包含到最终的产品之中。项目限制条件描述了项目的财务和时间预算，财务上的限制条件起到两个作用：它表明产品可以做到多精细，它也告诉自己是否真的需要该产品。

命名惯例与定义

每个项目都有一些特有的名称，在启动会议时开始定义术语有一个特别的好处就是让大家看到这些词，利益相关者可以讨论、修改它们，反映它们的一致含义。

估算产品的成本

精确的费用可以通过影响工作的业务事件的数目来确定。业务事件数据可以从上下文范围模型中确定，将每个事件的费用与事件的数目相乘，可以给出一个较为精确的需求收集费用。关键考虑不在于你使用了某种预估方法，而在于你使用了基于系统的度量，不是基于盲目的乐观。

风险

风险管理是一种常识性的项目管理，如果组织不进行风险管理，那么就要准备好预算超支或项目延迟的结果，风险评估人员要让管理层意识到风险。

小结

项目启动阶段是一个了解认知的过程，了解希望该产品做什么，要花多少成本来构建它，了解要研究的工作范围，以便为产品搜集需求。了解哪些人将参与项目，了解用户，从而了解产品的可用性需求。了解项目的限制条件，即可以花多少钱，有多少时间来完成该产品。了解项目要使用的术语，了解是否能成功。

第四章 业务用例

针对每个业务事件，有一个预先计划的对它的响应，被称为业务用例（BUC），业务用例是最方便研究的工作单元，换言之，业务用例就是一个功能单元。BUC中由自动化系统处理的部分就是产品用例产品用例（PUC），业务事件是相邻系统中发生的一件事，由此产生的信息流通知事件并触发响应（业务用例），需求分析师和利益相关者决定业务用例的多大部分由产品来完成（产品用例）。产品用例的选择在某种程度上是由技术考虑驱动的，必须既有最初的业务事件，必须能追溯到业务用例。

如果打算外部就可能不是确定产品用例，而是致力于业务用例，在询问外包商哪些部分能作为产品用例提交时，这些业务用例将作为谈判文档。从业务事件推导出业务用例，这意味着需求是根据工作对业务事件的响应方式来分组的。这导致工作以一种自然的方式划分，最终得到的产品对外部世界的真实要求响应得更好，从而为拥有者提供最佳价值。

第五章 工作调研

网罗业务

这里所讨论的网罗，关注的是发现和理解业务。当前的业务很重要，包括它的数据和处理过程，但同样重要的是不要花太多时间来做这件事。网罗需求的活动处于需求过程的中心位置，它使项目启动阶段的输出作为工作调研的起点，积累关于工作的知识。网罗活动利用项目启动阶段的输出信息，即工作的范围、项目的目标以及适用于所有解决方案的限制条件。考虑每次针对一个业务用例进行需求网罗。

Brown Cow模型

Brown Cow模型展示了工作的4个视图，两条轴分开了what和how，now和future。



从模型的左下象限开始How-Now展示了工作当前的实现，包括物理设备、人员和完成工作的处理节点。What-Now展示了真正的业务策略或者工作的本质。Future-What视图展示了拥有者希望的业务，它纯粹是建议业务领域的将来状态。右下角Future-How展示了将来业务策略的视图，加上使之成为现实的技术和人员。

业务用例研讨会

BUC研讨会对大多数项目都是有用的，是最常用的需求技巧。分析师与利益相关者共同探讨业务用例，并记录一下信息：

BUC的预期成果

正常场景，描述BUC完成的工作

异常场景，描述了哪些事情可能出错，以及工作通过哪些活动来纠正它们

适用于该业务用例的业务规则

草图原型，用于帮助利益相关者将业务用例可视化

考虑成果，而不是输出，寻找可服用的需求

快而不完美的过程建模

快而不完美的过程建模是一种技术，通过快速为业务过程建模来理解当前的工作，并达成一致意见。这种技术基本上是采用大量即时贴或索引卡片，针对过程中的每个活动，建立过程模型。原型和草图也可以是有效的需求提取技术。基本思路是用草图勾画建立的产品，然后逆向工程，从草图导出需求。原型是需求诱饵，让利益相关者感到产品足够真实，从而提出用其他方法可能遗漏的需求。如果每次针对一个PUC制作原型，就会更方便、更准确。

思维导图

用思维导图在访谈时做记录、计划项目或活动、对研讨会进行总结。实际上，只要我们需要简洁和智能的记录方式， 就会用到思维导图。思维导图是让所有业务分析师受益的技能。有很多思维导图的应用程序。