下面看看我们如何在软件开发背景中分析这个生活中的场景。

    软件开发背景中的场景分析

    首先在客户的电话来之前，我要满足的需求如表 1 所示：

    需求点：

    李明中午 2：00 到上海漕宝路 99 号拜访客户，进行 IBM Rational RequisitePro 产品的介绍。

    当客户的电话打来要求调整会议时间时，意味着开发中的需求变更登场了，那么再来看看我在上一章中每句话的含义：

    “不知道您会如何处理这件事情呢？” 如何处理变更？

    “也许您会说客户是上帝，客户是甲方，只能同意。” 无条件接受变更。

    “也许您会说没关系我可以等您，您先开会吧。” 无条件妥协。

    “也许您会想：”我还不知道我在哪里呢，怎么回答客户呀“ 既 不想接受，也不知道如何妥协。

    “看到这里，也许您会想现在什么时间？离那里多远？我需要先知道这些才能回答呀。” 已经萌芽了一些分析需求变更的想法，准备分析并处理需求变更请求，很好。

    那么我的每个步骤的含义又是什么：

    步骤 1：首先让客户挂机稍等。然后直接给我们的销售人员小鲍，告知情况，征询如何处理。小鲍此时有另外的事情正在忙碌，让我自己看着办。 我提交客户需求变更请求，小鲍分配我去审核变更。（责任划分明确，避免不必要的责任纠纷）

    拿到授权并规避完责任后，我需要判断是应该接受还是拒绝这个需求变更请求呢？下面分析步骤 2 和 3：

    步骤 2：判断我现在在哪里。从车窗可以看到我现在正在漕宝路 139 号和 137 号之间。 从距离上分析，结论不远。

    步骤 3：看表。现在 1：10，距离客户要求的 1：30 还有 20 分钟。 从时间上分析，时间充裕。

    看似我们应该接受这个需求变更请求，但是从步骤 4 至 7 分析，我们又可以得出：

    步骤 4：继续观察路况，发现堵车。怎么办？要是开飞经就好了，肯定没问题；要是想警车那样管路人借摩托车就好了；实在不成走路过去吧。 从实际进度分析，进展缓慢。希望通过引入新技术提高保障，但是新技术的引入风险大。

    步骤 5：继续观察路况，当前正中午，夏天天气炎热，而且漕宝路两边树木非常少。如果步行，不仅自己被暴晒而且由于行路匆匆，大汗淋淋导致仪表不庄，最终还有可能被客户投诉。 从舒适度角度分析，舒适度差，并且很有可能舍弃舒适度拼命为了满足客户的变更还最终受到埋怨。

    步骤 6：继续观察路况，需要穿过至少 2 个路口才有可能到达客户公司。步行不仅天气炎热，而且车来车往非常危险。 从安全性上分析，安全性差。

    步骤 7：继续观察，发现堵车严重，出租车计价器不停计价。步行虽然省钱，但是因公坐车公司负责报销车费，成本不是大问题。 从成本角度分析，成本低。

    于是现在脑海中形成了这样一个分析现象： 

    从时间和距离的角度看，我们会接受这个变更请求；

    从安全性和舒适度的角度看，我们肯定会拒绝这个请求；

    那我们到底优先关注的是哪个角度呢？我首要关心的是安全性，然后是舒适度，所以我选择了拒绝这个变更请求。当然您也许还有别的角度更关心，这就是仁者见仁，智者见智的事情了。对于门牌号这个小例子写了这么多，这和本文的需求数据和信息的关系有什么关系呢？我们接着看下一章。

    需求管理过程信息模型的建立对于管理需求数据的意义

    从表 1 和表 2 的对比有没有注意到，我们最初的文档变成表格了，这就是为什么软件开发团队的需求文档中有大量表格出现的原因，因为我们愈来愈发现文档的形式对于我们描述需求愈来愈不能满足我们的要求了，什么要求？！我们要求能够对需求进行有意义甚至拓扑结构（包括重要性，优先级等）的描述。稍等，好像这句话在前文中我们好像提到过，在哪里？让我们再看看数据和信息的定义：

    数据：数据是可定义为意义的实体，它涉及到事物的存在形式，是关于事件的一组离散的客观的事实描述，是构成信息和知识的原始材料。在软件开发过程中，所管理的很多文档，例如：项目可行性报告、需求规格说明书、概要设计说明书等都可以看作需求管理中的数据。

    信息：信息是一种消息，通常以文字或声音、图象的形式来表现， 是数据按有意义的关联拓扑结构的结果 .在软件开发过程中，所管理的很多文档中针对不同的数据条目通常附有相关的说明，这些说明起到的就是信息的作用。

    其实在门牌号这个例子中，漕宝路 99 号就是我们所具有的数据，而我们根据路况分析出来的距离，时间，新技术，安全性等是以属性的形式按照一系列关联拓扑结构描述了客观数据，其结果（例如：安全性差，舒适度低等）给我们带来了分析和判断事情（也就是需求变更）的信息，这些信息的汇总最终让我们做出准确地判断。这些通过需求点和属性关联起来的拓扑结构其实已经为我们搭建起了分析需求和处理变更的需求管理过程信息模型。

    也有客户曾就这个例子时候同我分析说，其实表 2 中的若干属性对于项目开发来说，就是对于需求进行波动分析和变更控制的经验值的积累，在需求管理过程中这些经验值或者属性的积累对于软件开发团队确保项目开发范围的控制是非常有益的。

    因此，上述的论述中我们可以看到通过对需求数据和信息关心的描述，我们可以得出需求管理过程信息模型的建立对于管理需求数据的 3 点意义：

    意义 1：通过基于需求数据和信息关系的分析，可以助力需求管理在变更管理过程中的应用。

    意义 2：需求管理中需求的信息模型的搭建，可以帮助开发团队积累有价值的分析需求变更和控制项目范围的经验。

    意义 3：需求管理中不仅注重抽取或捕获准确的数据，还要能搭建可以服务于企业的标准信息模型，这样在信息模型的架构下才能更高效地发挥需求管理的作用，保证开发的成功。

    那么现在我们也许能够理解下图所示的需求管理和变更管理的关系了。