需求管理中数据和信息的关系及应用

                                                                                              需求管理中数据和信息的关系及应用
   

 

本文从需求管理的角度，对需求管理中数据和信息的关系进行分析，并将之结合应用到软件的需求分析和管理活动中。本文同时还介绍了如何运用 IBM Rational RequisitePro 进行需求管理。需求术语的概览

什么是需求？什么是需求分析？什么是需求跟踪？什么是需求获取？什么是需求规格？什么是需求验证？什么是需求变更？……一堆关于需求的问题，一堆关于需求和需求管理的恼人问题，需求真的很重要吗？那为什么如此难以把握？为什么在软件工程中如此难以应用呢？

您作为从事项目开发，尤其是软件项目开发的负责人，需求分析师，系统架构师，程序员，测试人员，维护人员，项目的使用者，只要您是项目开发和应用中的一位成员，您一定思考过上述的问题，或许您曾为此问题曾经与人激烈讨论过，或许您已经疲于争论已经在实际的项目中应用您的认识和体会了。

上述这些话，在 IBM 或者软件行业协会举办的需求管理讲座上，我以 IBM Rational 产品讲师的身份曾经多次询问过客户和听众，他们每每给予我的回应除了无奈的笑之，就是带着期许的眼光等待着我给出回答。

什么是需求

对于第一个问题：什么是需求？很多需求专家和权威机构已经给出了他们的描述，为什么是描述而不是定义呢？“因为软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义的“需求”对于开发者似乎是一个较高层次的产品概念。而开发人员所说的“需求”对用户来说又象是详细设计了。实际上，软件需求包含着多个层次，不同层次需求从不同角度与不同程度反映着细节问题：

---IEEE 软件工程标准词汇表（1997）中需求为：

（1）用户解决问题或达到目标所需的条件或能力

（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力

（3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。”

---Jones 认为“需求是用户所需要的并能触发一个程序或系统开发工作的说明 ----（Jones 1994）”

---Alan 认为“从系统外部能够发现系统所具有的满足于用户的特点、功能及属性等 ----（Alan Davis 1993）”

---S&S 认为“需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束 ----（Sommerville and Sawyer 1997）”

所以引出上述这些描述，是因为我们仔细阅读上述权威机构和专家的描述，可以发现，他们分别从用户，从系统，从系统部件，从作用，从实现等不同方面对需求进行了阐述，至少通过上述的描述我们可以知道，需求基于不同的立场和角度是可以有不同的理解的，这也是为什么总是会有人针对什么是需求喋喋不休的争论，而最终谁也无法说服谁的场景在软件开发过程中层出不穷的原因。那么谁会对需求有不同的立场和角度呢？干系人，同项目或者系统有关的干系人（Stakeholder），前文我们提到的软件项目开发的负责人，需求分析师，系统架构师，程序员，测试人员，维护人员，项目的使用者等等，这些都是需求的干系人，因为有干系人的存在，就会有基于不同立场和角度的需求认识，这样就会形成不同类型的需求，因此当我们在探讨什么是需求时，我建议大家不要忘了思考我们正在针对何种类型的需求在进行探讨，探讨的目的是什么。

至此如果我们接受了从需求分类的角度考虑什么是需求。那么什么是需求分析？什么是需求跟踪？什么是需求获取？什么是需求规格？什么是需求验证？什么是需求变更？……也就是我们该如何理解并组织这些需求活动和术语呢？

需求术语的组织结构

对于第二个问题，如何理解和组织众多需求术语和活动。本文借鉴需求管理专家 Wiegers 在《Software Requirements》一书中对于这些需求活动和概念的描述与分类，如下图所示：

图 1. 需求术语组织图

需求工程：需求开发和管理的过程。它包括了需求开发和需求管理两个部分。

需求开发：是指从问题获取、分析判断到编写规格说明文档、评审验证等一系列产生需求的活动。这些活动在需求开发中是相互独立和可以反复出现的。

问题获取：需求的收集、分析、细化、核实并组织的步骤，该活动包括干系人分类，筛选典型客户代表，组建需求团队，召开会议，判断需求质量属性等多项具体内容。

分析：根据需求获取中得到的需求文档，分析系统实现方案。具体的方法包括：鱼刺图，上下文关系图，用例图等分析方法。

编写规格说明：需求开发的最终成果是客户和开发小组对将要开发的产品达成一致协议，这一协议就是通过文档化的需求规格说明书来体现。对于不同类型的需求可以有不同的规格说明相对应，例如所常见的用户需求，业务需求等。

验证：确保需求说明准确、完整，表达必要的质量特点，需求将要作为系统设计和最终验证的依据，因此一定要保证它的正确性。需求验证务必确保符合完整性、正确性、灵活性、必要性、无二义性、一致性、可跟踪性及可验证性这些良好特征。

需求管理：是计划、组织、指导和控制需求的系统方法，也是指软件项目开发过程中控制和维护需求约定的活动，通常包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。

版本控制：版本控制是需求管理的一个必要方面，需求文档的每个版本必须统一确定。以保证每个成员可以准确地得到需求的当前版本，并了解需求文档每个版本的修改原因和结果。

需求跟踪：是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，其他设计部件，源代码模块，测试，帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。

需求状态跟踪：不同类型的需求都有不同的需求状态相对应作为需求优先级划分标准的补充说明，通过需求状态跟踪能够确保需求按照优先级先后实现的完整性。

变更控制：变更控制给项目风险承担者提供了正式的建议需求变更处理机制，通过变更处理机制需求的决策人可以准确地分析需求变更所带了的影响和波动，从而决判断是否接受、拒绝或者延迟需求变更，最终准确控制项目开发范围。

至此，我们了解了应如何理解和组织众多需求术语和活动。但是也有许多人看到这里会认为这又是一篇堆砌了很多术语介绍的文章，晦涩而难以应用。其实不然，本文重点论述的就是 --- 通过数据和信息的关系理解需求管理在变更管理中的重要性。为什么有此想法和立意呢？

我在拜访很多软件开发企业的时候发现大多数软件开发团队都已经有了成熟的变更管理概念和管理基础，已经能够将变更管理到位了，于是他们就想进一步管理需求，但是不久就会发现从很多书本或者权威的书籍中得到的需求管理的理论，往往向我上面介绍的术语那样大而全，但是确苦于无从下手，担心需求管理同变更管理结合使用的学习成本太高并且风险太大，最终不了了之，很多软件开发企业和团队只能继续忍耐由于需求变更所带来的项目延期或者利润下降的噩梦。

那么我们可以怎样使用需求管理呢？我们首先从一个生活中的小例子介绍。

需求管理过程中的数据和信息的关系

想看小例子了？看例子之前先让我们再了解两个必须的术语定义 --- 数据和信息：

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

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

也许上述晦涩的定义不易理解二者之间的关系，我们这就看看下面的小例子，然后再来解读我们是如何潜移默化的应用二者的。

有趣的小例子 - 门牌号

生活中的场景分析

背景

话说某天 IBM 北京 Rational 部门的销售人员小鲍告诉我第二天中午 2：00 到上海漕宝 路 99 号拜访一位客户，主要目的是介绍 Rational 大名鼎鼎的需求管理工具 RequisitePro，我答应了。

第二天上午坐飞机由北京飞到上海，出了机场打车直奔客户处。上车后同司机说去漕宝路 99 号，可是司机只知道漕宝路不知道 99 号在哪里？看来只能到了漕宝路再自己找了。

刚到漕宝路上，突然接到客户电话声称因其公司有重要的会议挪到 2：00 点钟开，因此希望将我们的会面提前到 1：30 开始，问我可以吗？

情景

不知道您会如何处理这件事情呢？

也许您会说客户是上帝，客户是甲方，只能同意。

也许您会说没关系我可以等您，您先开会吧。

也许您会想：“我还不知道我在哪里呢，怎么回答客户呀”

看到这里，也许您会想现在什么时间？离那里多远？我需要先知道这些才能回答呀。

那么让我来告诉您我是怎么处理的：

步骤 1:首先让客户挂机稍等。然后直接给我们的销售人员小鲍，告知情况，征询如何处理。小鲍此时有另外的事情正在忙碌，让我自己看着办。

步骤 2:判断我现在在哪里。参见图 3 ，从车窗可以看到我现在正在漕宝路 139 号和 137 号之间。

步骤 3:看表。现在 1：10，距离客户要求的 1：30 还有 20 分钟。

图 2. 门牌号图一门牌号

图 3. 步骤 3 之前的分析场景

图 2显示我脑海中的门牌号也就是目的地，图 3 给出了路况，我们可以判断距离客户公司应该还有 20 个商户，具体多远不知道，但是应该不远了，所以在图 2 中给出了两个虚线框出的 99 号来标示客户公司大概的位置，那么经过步骤 1-3 的分析是否有读者认为我们可以告诉客户我们可以在 1：30 赶到客户公司进行产品介绍了呢？

那么让我们继续看看我下面的步骤，参见图 4 ：

步骤 4:继续观察路况，发现堵车。怎么办？方法一：要是开飞经就好了，肯定没问题，可惜不会开飞机，而且也没有飞机，妄想；方法二：要是能象警察办理紧急公务那样可以同路人借摩托车就好了，可惜不是警察，做梦；方法三：实在不成我可以走路过去，因为不太远，最笨但是最可控的方法。

步骤 5:继续观察路况，当前正中午，夏天天气炎热，漕宝路两边树木稀少。如果步行，不仅自己被暴晒不舒服而且由于行路匆匆，很可能大汗淋淋感到客户公司，最终虽然克服了困难拼命满足客户的变更要求，但很有可能被客户投诉仪表不庄。

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

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

图 4. 步骤 7 后的场景

到目前为止，通过权衡这些问题的利弊后我给客户致电说我估计不能在中午 1：30 的时候赶到客户公司，我可以等客户参加公司重要的会议后再进行 Rational 产品介绍，客户在电话中表示抱歉后挂机，问题解决完毕。

看到这里也许读者不明白为什么我大费周折地给你们介绍这个小例子，其实我想告诉大家的是：我们不需要将软件过程改进中关于变更管理和需求管理的过程看得过于复杂化，我们现在待改进的开发过程看似杂乱无章，其实它们是由于我们在开发活动中每个角色获取利益并规避责任后的本能反应，这些本能的反应活动构成了无序的结果，只要细心梳理这些活动，就可以形成为各自公司所用的变更管理和需求管理过程。

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

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

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

表 1. 文档形式描述的需求点
　 需求点： 李明中午 2：00 到上海漕宝路 99 号拜访客户，进行 IBM Rational RequisitePro 产品的介绍。

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

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

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

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

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

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

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

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

如下图所示：

图 5. 批准需求变更的流程

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

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

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

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

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

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

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

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

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

表 2 表格形式描述的需求点 需求点 新技术 安全性 成本 时间 距离 舒适度 李明中午 2：00 到上海漕宝路 99 号拜访客户，进行 IBM Rational RequisitePro 产品的介绍。 无 差 低 充裕 近 差

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图 6. 需求管理和变更管理的应用

作为 IBM Rational 产品家族的需求管理产品 RequisitePro 是怎样支持数据和信息的呢？换句话说，RequisitePro 是如何管理需求和需求属性的呢？在下一章，我们专门针对这一点进行介绍。

产品 Rational RequisitePro 的介绍

让我们看看在 IBM Rational SDP（软件交付平台）上 IBM Rational 需求管理产品 RequisitePro 是如何同变更管理产品 ClearQuest 完成上述这个小例子的：

第一：在 IBM Rational SDP 中创建集成项目“门牌号小例子”，如图所示：

图 7. 在 IBM Rational SDP 中创建项目

第二：创建完集成项目“门牌号小例子”后，、再创建 RequisitePro 所管理的需求工程“门牌号的小例子”，所有需求数据（需求项，或者需求点），需求属性交由 RequisitePro 管理；然后为再创建 ClearQuest 的变更管理数据库，所有变更条目，变更状态等数据交由 ClearQuest 管理（创建 ClearQuest 变更数据库的操作不属于本文重点，所以不赘述了），如下图所示：

在 RequisitePro 中创建不同的需求类型，如本生活情景中我们有业务需求：

图 8. 在 RequisitePro 中创建需求类型

第三：创建完需求类型后，成熟的需求管理在需求管理计划中会针对不同的需求类型定义不同的需求属性，例如本生活情景中分析信息所用到的属性有：安全性，成本，距离，舒适度等，其中不同的属性的类型不一，例如：安全性属性属于枚举类型，成本属于数值类型，距离属于文本类型等，这些属性类型，甚至默认值都可以在 RequisitePro 中定义，如下图所示：安全性属性的创建过程

图 9. 在 RequisitePro 中基于不同的需求类型创建属性

第四：到此为止，我们可以说按照需求管理计划的要求在 RequisitePro 中创建了一个名为“门牌号的小例子”需求工程，然后我们再去创建 ClearQuest 的变更数据库以及流程（前面说过，ClearQuest 不是本文重点，所以这里不在具体制作关于 ClearQuest 流程定制和数据库创建的过程），默认我们已经创建完 ClearQuest 中的变更管理的数据库和流程，我们直接进入 RequisitePro 和 ClearQuest 在 SDP 中的集成配置过程，如下图所示：

图 10. 在 IBM Rational SDP 中配置 RequisitePro 和 ClearQuest

第五：配置好 RequisitePro 同 ClearQuest 集成后，在 RequisitePro 输入需求点的具体内容，如下图所示：

图 11. 在 RequisitePro 中增加需求

RequisitePro 中需求点的详细描述：

图 12. 详细的需求点

第六：假设此时客户变更出现，可以在 ClearQuest 中提交变更请求，如图所示：在 ClearQuest 中提交 SAMPL00000042

图 13. 在 ClearQuest(CQTM) 中创建需求变更

然后可以直接在 SAMPL00000042 号变更单中的“需求”Tab 页中选择“门牌号的小例子”需求工程，同相关联的需求点进行关联，如下图所示：

图 14. 创建需求变更时，将变更同需求点关联


图 15. 关联 RequisitePro 中的需求点

第七：关联好后，进入 RequisitePro 后可以直接看到刚才的变更请求同需求点关联的视图，在视图中可以看到需求点旁边有许多有用的属性，这就是 RequisitePro 所管理的需求属性矩阵，这个矩阵可以帮助我们基于已有的数据分析出有用的信息，如下图所示：

图 16. 在 RequisitePro 中分析矩阵

正如上文例子中所分析的原因，最终我们决定拒绝 SAMPL00000042 号变更请求。

总结

本文为了读者便于理解，将生活中的小例子刻意从软件工程的角度进行解决。但是通过上面的介绍，读者可以感受到，在软件开发过程中其实我们已经有了许多项目数据了，可是这些项目数据只是被几个项目的专家和骨干掌握，只有他们才能做出有效而准确地决定，为什么？正是因为他们有项目经验，而需求管理中的属性矩阵可以很好地将这些专家或者骨干头脑中的经验挖掘出来并固化到平台上面，这样对于其他人员是非常有益的，可以很快提高团队的战斗力，从这一方面，也在此强调了需求管理中的需求数据和信息的分析对于产品的质量是有很大保证的。只要我们掌握了数据和信息的本质联系，是可以在项目的需求管理中活学活用的。

原文转自：http://www.ltesting.net