4.1 需求定义任务概述

需求定义是确定项目的宏观需求，也就是项目的目标和范围。

4.1.1 需求定义的时机

需求定义应该是项目启动时要解决的事情(应该是PMP里项目章程的一部分内容，应该在项目启动会前准备好)。

但在实际项目中很难达到要求，因为在项目立项阶段，开发团队包括需求分析人员可能还没有成立。在这种情况下，需求分析人员更应该审视和补救需求定义阶段的产物。

清晰的项目目标和范围定义，能够引导需求工作顺利进行。

4.1.2 需求定义的理念与策略

4.1.2.1 破解混沌不清的项目目标

对于项目目标经常会做的比较空洞，例如“全面提高企业的信息化应用水平”，这些空洞的目标难以落实。

对混沌不清的目标，可以通过内部寻根或外部溯源来破解。

》内部寻根

当你看到一个比较空洞的目标时，首先可以尝试寻找企业内部真正的项目发起人，跟他们深入沟通。

》外部溯源

项目有时并不是内部发起的，而是受到一些外部条件的影响，这时就要从外部寻找信息。

4.1.2.2 需求定义的理念

需求定义就是四个字：问题/机会。

具体步骤：GPOA模型。在需求定义或项目提案时，经常会采用目标Goal-问题Problem-可选方案Options-建议方案Answer的过程。

》目标Goal：通过内部寻根或外部溯源方法，将整个项目要解决的问题或机会罗列出来。

》问题Problem：找出该目标的问题/机会根源，然后全部罗列出来。

》可选方案Options：针对每个问题/机会，罗列出尽可能多的解决方案。

》建议方案Answer：从可选方案中挑出最可靠的方案。

4.2 RUP问题分析五步法

对于需求定义活动，RUP给出五步法，但在实际项目中会发现可操作性并不强，但它提供了一个很好的理论框架，我们先学习五步法，后续将介绍更适合落地的方法。

将问题分为五个步骤：第一步：在问题定义上达成共识。第二步：问题的根本原因分析。第三步：确定相关人员和用户。第四步：定义解决方案的界限；第五步：确定加在解决方案上的约束。

4.2.1 在问题定义上达成共识

要让大家达成共识，采用统一的格式描述问题就是一个有效的手段。

4.2.1.1 问题定义的技巧

对问题进行了正确的定义，意味着成功了一半，而在问题定义时应该善于运用转换和本源两个技巧。

》转换

需求定义阶段要善于将未知问题转换成已知问题

例如在实际项目过程中，在和客户沟通时就应该注意如何将客户的需求转换成自己的已有产品，而不是简单的重新开发。

》本源

问题经常会被表象所掩盖《你的灯亮着吗--发现问题的真正所在》中收录了一些案例。

在确定某问题的解决方案时，一定要思考是否会引发新的问题。

用一个成本很大的解决方案去弥补一个错误，是很常见的问题。

直接修改错误，不要用其他方案来弥补错误。

4.2.1.2 影响人群分析的技巧

4.2.2 问题的根本原因分析

根本原因分析有两个实用工具：鱼骨图，帕累托图。

4.2.2.1 鱼骨图

是一种找出根本原因的方法，主要用于定性分析。鱼骨图通常要结合头脑风暴，具体来说就是一个团队一起绘制鱼骨图。步骤如下：

1 选择问题。首选必须选择一个具体的问题或结果。

2 头脑风暴。头脑风暴的目的是寻找原因，不能将原因和解决方案混为一谈。

3 确定原因类型。对头脑风暴的结果汇总，一般来说类型不会超过六种：人，机，料，法，环。

4 分配原因。将头脑风暴得出的原因，归于相应的原因类型下，放在鱼骨图中。

5 分析根本原因。

6 小结。

4.2.2.2 帕累托图

帕累托图主要进行定量分析。主要用来识别最重要的事项，即关键原因。帕累托分析常常揭示出一个现象：少数失误应该为大量的质量成本负责，也就是大名鼎鼎的28法则。步骤如下：

1 确定问题和相关原因。这个工作实际上可以由鱼骨图来完成。

2 收集数据。针对鱼骨图的结果，随机抽取样品，收集分析每个原因的频率。

3 绘制直方图。将原因放在x轴上，比例或频率放在y轴上。

4 小结。

鱼骨图为解决问题找到了靶子，帕累托图则标上了环数。

以上两种方法都是站在问题的角度进行分析，需求人员应该判断哪些原因是可以通过信息系统解决的，从而使系统的确立更加科学。

4.2.3 确定相关人员和用户

当问题明确后，系统的目标也就明确了。接下来就是明确项目干系人了。

4.2.3.1 Stakeholder分析(PMP里的干系人分析)

项目干系人，涉众，利益人等项目管理书籍中常提到的词语，都源自Stakeholder，它的原意是筹码持有人。

4.2.3.2 用户分析

用户实际上也是Stakeholder的一类，他们是直接使用系统的人。

4.2.4 定义解决方案的界限

4.2.4.1 范围 vs 边界

范围是涉及的事，物。边界是人与系统的职责边界。

4.2.4.2 确定边界

4.2.4.3 边界谈判

用户永远会希望花同样的钱，获得尽可能多的功能。

这不能完全归于是客户的原因，因为交易双方处于信息不对称的时候，就一定会出现这种情况。

很多时候，你不能直接回复客户说你要的功能太多了，这些投资是不够的，而是应该找到更有力的理由。

4.2.4.3 创新边界

4.2.5 确定加载解决方案上的约束

主要包括技术约束和项目实施约束。

4.2.6 RUP问题分析五步法小结

五步法更多是从策略，思考方式的焦点入手，在实际操作上并没有给出清晰的指导，在接下来两章中，将重点分析需求分析人员在需求定义中应该完成哪些任务，具体应该做些什么。

4.3 需求定义的产物与要素

4.3.1 需求定义的产物

根据项目类型不同，产物可以分为POS(Project Overview Sprcify，项目综述) 和 Vision(愿景) 两大类。

4.3.1.1 POS类

对于项目型的软件开发工作，通常会在立项结束时完成立项报告，最典型的就是项目章程，可行性分析报告等。主要内容如下：

4.3.1.2 Vision类

对于生命周期相对较长，应用面相对较广的项目或产品而言，会在POS的基础上添加一些内容，主要是市场分析，规划方面，最典型的是RUP推荐的Vision文档。

从内容可以看出，Vision更重视市场机会分析，有时甚至会加入SWOT分析等市场分析内容。

4.3.2 需求定义的要素

4.3.2.1 目标

目标对于一个项目而言，其重要性不言而喻。一个好的目标应该满足SMART原则：

》具体(Sprcific)

》可以度量的(Measureable)

》可以达到的(Attainable)

》与其他目标具有相关性(Relevant)

》有明确的截至期限(Time-based)

而在具体写作过程中，从目标，业务优势，度量指标，合理性，可行性和可达成性方面进行编写，是一个不错的选择。

4.3.2.2 范围

很多书籍都推荐通过上下文关系图来描述范围，在这里将介绍一种“两图一纲”的方法，将在4.4节中详细介绍。

4.3.2.3 相关人员与用户

需求阶段描述的是用户的能力特点，以便提高系统可用性。

在进行需求定义时，对于用户而言，需要收集和分析的信息包括：与系统主题相关的经验，技术上的经验，智力能力，对工作的态度，对技术的态度，受教育程度，语言技能，年龄，性别等信息。

对于用户之外的干系人，则需要了解他们对于软件系统的关注点，想通过系统获得什么利益。

4.3.2.4 相关事实与假定

4.4 定义需求范围

需求方为很多时候都用程序分解结构(系统-子系统-模块-子模块)来表示，在前面已经描述这种结构的弊端。在这里将介绍两图一纲的方法，即构件图，上下文关系图和需求大纲。

4.4.2 划分主题域

当我们面对一个新系统时，可以将整个待开发的系统看做一个黑盒子；首先要判断是否需要划分成不同的主题域。如果需要，就通过一张构件图将主题域和他们之间的服务接口标识出来。

4.4.2.1 什么是主题域

主题域划分跟传统的子系统划分是有很大区别的。首先看看传统的子系统划分：

传统划分方法经常是“业务名词+管理”的方式命名，本质上是以物为线索。虽然体现了系统的分解结构，但忽略了每个系统/模块之间的关系。

主题域划分则是以事为线索，通过构件图来展现系统。

主题域划分的思考过程

》以组织结构为线索

》以分管领导为突破

》借鉴典型业务区块

在最终决定主题域之前，还需要结合目标来考虑这些主题域，如果主题域跟目标无关，就可以将它移除。

目标决定范围。

4.4.2.2 使用构件图

》构件图可以体现服务接口的重要性

》构件图解析

× 构件

× 服务接口

× 构件与接口之间的关系：提供，使用

4.4.3 确定主题域范围

上下文关系图是绘制系统范围很重要的一种工具。在划分完主题域之后，针对每个主题域来绘制上下文关系图，以确定每个主题域的范围。

4.4.3.1 上下文关系图绘制要点

在绘制上下文关系图时应采用以下步骤：

1 首先用一个矩形表示系统

2 找到该系统的所有Customer，考虑每个Customer会发起什么事件，这些事件会引发Worker什么工作，将这些序列逐一表示出来。

3 最后看看每个Worker还有没有主动发起的事件。

在绘制上下文关系图时，先考虑Customer再考虑Worker是关键。

上下文关系图应该是在于用户代表沟通时绘制的，是一种团队建模的产物。

4.4.4 标识业务事件与报表

构件图和上下文关系图绘制完成之后，需求范围也就框定出来了。但它还不足以为后续的需求捕获分析与建模活动提供良好的基础，也就是将主题域的内容以业务事件列表和报表列表标识出来。

在“第二章 不同软件项目的需求视图”中，我们曾总结，联机事务处理系统的核心是业务事件(流程)，管理信息系统的核心是报表(包括各种查询，分析，统计)。而通常的业务系统都包含了这两种成分，因此在需求定义阶段应该将这两个线索都明确的标识出来。

而业务事件和报表，都以上下文关系图为基础。

4.4.4.1 业务事件解析

业务事件是业务流程的触发点，而业务流程是为了响应业务事件而触发的一系列业务活动。

业务流程通常由不同部门不同岗位协作完成，因此业务流程信息掌握在中层管理人员手里，属于脉络信息。

业务活动从属于特定的业务流程，它是一个人的活动，因此业务活动或业务步骤信息掌握在操作人员手里，属于细节信息。

》业务事件类型

》业务事件标识要点

业务事件应该是主动触发的，并且将会产生一系列后续行为。

业务事件是直接作用于系统的，要跟导致事件的条件去分开。

梳理业务事件时应该把数据备份，数据准备之类的技术性活动放在一边，因为我们梳理的是业务，不是系统事件。

》报表列表梳理

根据“第二章 不同系统的需求视图”，我们了解到报表一般分为以下几种：

在实际项目中，应该通过与中层用户代表访谈，来确定所需的报表类型。

4.4.5 生成需求大纲

通过划分主题域，确定主题域范围，标识业务事件与报表后，就可以把它填入到POS或Vision文档中的“项目范围”中了，先从主题域划分，然后每个主题域一个小结，分别阐述业务事件和报表需求。

同时，我们也可以利用这些范围信息把软件需求规格说明书(SRS)的框架搭建出来了，以便在后面的环节中不断演化，填充。下面分别是Word和Rose的组织形式。

4.4.5.1 Word文档组织示例

4.4.5.2 Rose组织示例

最顶层是一个构件图。

4.5 小结

需求定义工作的重点在于明确项目目标和范围，这是后续需求工作的基础。

解决目标问题后，就是界定范围。介绍了SERU模型，通过主题域，业务事件，报表，用例的角度分析范围，最后通过构件图，上下文关系图和需求大纲来描述范围。

接下来，我们就可以用业务事件列表和报表列表作为线索，展开进一步的需求捕获，需求分析和建模工作。