需求管理摘要：2011年7月，我参与了某企业“高清卡口式智能电子警察“项目的建设。

在项目中担任项目经理职务，主要负责项目的管理工作。

该项目是受某市公安局交警指挥中心的委托而开发的，目的是为了改善城市道路交通环境，提升公众出行安全系数。

系统兼具电子警察和卡口功能。

（121）本文结合作者的经验，以“高清卡口式智能电子警察“项目为例，讨论了项目的需求管理过程以及采用的措施和方法。

作为建设方的项目经理，我认为需求管理在信息系统项目中目的是确保项目各方对需求的一致理解，管理和控制需求的变更，实现从需求到最终产品的双向跟踪。

在具体工作中，采取了利用头脑风暴法获取需求，利用业务流程分析、数据流图等进行需求分析，利用评审进行需求验证，制定双向跟踪矩阵进行需求管理等相关管理方案。

通过这些措施和方法，有效地控制了项目范围和成本，成功地完成了项目，受到用户方的高度评价。

正文：项目概述；随着我国国民经济的持续快速发展，车辆剧增，由此导致交通阻塞，交通事故发生频率高，交通环境污染，交通治安混乱等一系列问题，严重影响了人民的生活。

在城市交通的关键点——道路交叉口，由于汇聚了多个方向的交通流量，加上机动车非机动车混行等因素，成为城市路网中交通拥堵发生的重点地段。

而车辆闯红灯等违法现象，更是成为引发道路交通事故的主要诱因之一。

单纯依靠人为管理，浪费人力资源，效果也不明显。

因此，向科技要警力，向管理要效益成为各个城市交通管理部门进行违法自动检测系统建设的动力。

为进一步利用科技手段实现对闯红灯、逆行等违法行为进行有力地治理，防止此类交通违章行为的发生，减少由此引起的事故，并促进交通秩序良性循环，提升公众出行安全系数，某市公安局交警指挥中心特委托我公司开发“高清卡口式电子警察”。

项目启动后，我被任命为该项目的项目经理，全面主持项目的管理工作。

该项目规模庞大，一期投资投资600万，要求在2012年1月1日前全面竣工并投入使用。

该项目将负责某市110万辆机动车数据，涉及部门人员众多，涵盖的知识技术领域范围广，是一个大型、复杂的综合性项目。

在有关领导的亲切关怀下，在项目干系人的配合与支持下，我与项目组全体组员并肩作战，通过近6个月的努力，终于在2011年12月20日全面通过验收。

项目总成本为万原，比计划提前10天，为公司挣得万利润。

项目采用B/S架构，Windows为开发平台，c#，c++为开发语言，数据库使用的是oracle 10g。

该项目除了具备实时监控功能外，还具有高清抓拍、大容量高速存储、自动检测车辆及车牌识别、全程轨迹跟踪、自动预警拦截等系统功能。

项目涉及的子系统较多，主要包括车辆检测模块、图像采集模块、信息处理模块、数据检索模块、违章检测模块等几个部分。

该项目的成功与合理的需求管理以及项目干系人的大力支持是密不可分的，下面分别对项目需求管理过程中需求获取、需求分析、需求定义、需求验证、需求管理（制定需求管理计划、需求变更管理、需求跟踪）等几个方面加以简要论述。

需求管理和范围管理的关系：需求开发、需求管理、范围管理的区别和联系主要如下:1)首先通过需求开发来获取项目的需求,在此基础上确定项目的范围、进行项目范围管理。

项目管理者联盟2)对于项目需求,可以根据需求的紧急重要程度、项目本身和项目双方的实际情况,分步或分期满足。

确定每期应满足的需求后,本期的范围管理就有了基础。

3)需求管理处理需求的变更,需求的变更同时会引起项目范围的变更。

需求获取：首先联系并了解用户方。

我同用户进行联系并取得了对方相关人员的名单，了解了他们的角色及职责。

将可能使用产品的客户分成不同类别。

详细描述出它们的个性特点及任务状况。

为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。

制定需求管理计划，包括如何规划、跟踪和汇报各种需求活动；需求管理需要使用的资源；培训计划；项目干系人参与需求管理的策略；判断项目范围与需求不一致的准则和纠正规程；需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求；配置管理活动等。

制定需求管理计划后，我召开了联合讨论会。

联合各类关键客户代表，分析人员，开发团队代表一起，采用头脑风暴法来讨论需求。

由此拟出需求文档的底稿，确定了项目的质量属性和其它非功能需求。

需求分析：需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有的干系人都明白其含义并找出其中的错误、遗漏或其它不足的地方。

分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要。

其目的是确保所有干系人尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

我们从以下几方面对收集的需求进行分析：1）分析需求可行性。

计算机不能代替现实世界中的所有工作。

在允许的成本、性能要求下，对每项需求进行业务流程分析，分析业务流程中哪些是需要信息化管理的，而哪些不需要。

同时为业务流程的合理化改造提供建议。

明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

2) 确定需求的优先级别。

以优先级为基础确定产品版本将包括哪些特性或哪类需求。

给每个需求建立优先级有助于解决冲突，安排阶段交付，并且做出必要的取舍。

3) 为需求建立数据流图。

用来表达系统内数据的流动并通过数据流描述系统功能。

数据流图还有助于找到不正确的、不一致的、遗漏的和冗余的需求。

4) 创建数据字典。

在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。

需求定义：用户需求要用一种标准使用实例模板编写成文档。

而软件需求规格说明则包含了软件的功能需求和非功能需求。

我们根据下面几方面定义了软件的需求规格说明文档。

1) 采用S R S模板：定义了软件需求文档标准模板。

该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。

2) 指明需求的来源：为了让所有干系人明白S R S中为何提供这些功能需求，每项需求都要能追溯来源。

3) 为每项需求注上标号:制定一种惯例来为S R S中的每项需求提供一个独立的可识别的标号或记号。

这种惯例应当很健全，允许增加、删除和修改。

作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。

4) 记录业务规范:业务规范是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。

将这些编写成S R S中的一个独立部分。

5) 创建需求跟踪能力矩阵:建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。

这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。

需求验证：验证是为了确保需求说明准确、完整地表达必要的质量特点。

避免需求说明中的二义性。

在本项目中通过评审的方式进行需求验证。

审查需求文档。

组织一个由不同代表（分析人员，客户，设计人员，测试人员）组成的小组，对S R S及相关模型进行仔细的检查，尽最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。

需求评审之后，开发方和客户方的责任人对《需求规格说明书》作书面承诺。

需求管理：完成需求说明之后，不可避免地还会遇到项目需求的变更。

有效的变更管理需要对变更带来的潜在影响及可能的成本费用进行评估。

变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。

同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。

建立起良好的配置管理方法是进行有效需求管理（ requirement management）的先决条件。

可以使用版本控制和其它管理配置技术来管理代码和文档。

在本项目中我们采用如下流程进行需求的变更管理：1) 确定需求变更控制过程。

确定一个选择、分析和决策需求变更的过程。

所有的需求变更都需遵循此过程。

2) 建立变更控制委员会。

变更控制委员会由项目经理、用户代表、质量管理人员、配置管理人员、公司技术专家组成。

3) 进行需求变更影响分析：评估每项需求变更，以确定它对项目计划安排和其它需求的影响。

明确与变更相关的任务并评估完成这些任务需要的工作量。

对于审核通过的需求变更，该需求变更将由后续的实施人员(如开发修改代码、需求人员修改需求文档等)进行实施。

需求跟踪本项目中采用如下措施进行需求跟踪：1) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。

2) 建立需求基准版本和需求控制版本文档：确定一个需求基准，之后的需求变更就遵循变更控制过程即可。

每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

3) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。

4) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。

保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。

5) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）数量。

过多的需求变更“是一个报警信号”，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。

6) 使用需求管理工具：商业化的需求管理工具能帮助在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它软件开发工作产品间建立跟踪能力联系链。

需求跟踪的目的：在某种程度上，需求跟踪提供了一个表明与合同或说明一致的方法。

更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用。

需求跟踪能力矩阵：表示需求和别的系统元素之间的联系链的最普遍方式是使用需求跟踪能力矩阵。

正向跟踪：从需求到设计、源码、测试用例的过程，用于明确是否所有需求都被设计了、被编码了，被测试了等。

一旦某个需求需要变更，就可以快速找到所有影响的范围。

反向跟踪：从缺陷到测试用例、源码、设计、需求的过程，用于明确所有的工作成果都是有对应的需求，避免测试多余、设计多余的情况发生。

同时，一旦某项设计因多种原因发现需要变更，也可快速找到对应的需求，以便快速确认相应的需求是否需要变更。

不管是正向追踪还是反向追踪，都需要建立需求能力跟踪矩阵。

下表展示了这种矩阵，这是一个“化学制品跟踪系统”实例的跟踪能力矩阵的一部分。

这个表说明了每个功能性需求向后连接一个特定的使用实例，向前连接一个或多个设计、代码和测试元素。

需求跟踪能力工具：在本项目里，我们采用RP （RequisitePro）实现了上述双向跟踪。

通过该工具，大大减少我们人为进行需求双向跟踪所需的工作量。

需求跟踪能力过程：应用需求跟踪能力来管理工程时，采用下列步骤：•决定定义哪几种联系链。