1、软件需求管理思考摘 要：针对需求评审过程中存在的不容易记录和跟踪评审问题、需求的变更申请不能很好与需求条款相对应问题、需求管理工具中管理的需求文档不能直接进入软件配置管理系统导致需求文档的源头不唯一问题以及通过手工方式进行需求追踪的问题等，考虑到需求管理活动包含的需求变更管理与版本控制属于软件配置管理需要控制的核心要素，从理论上将需求管理与软件配置管理有机融合，以两者融合解决需求管理过程中存在的问题为出发点，在此基础上提出了一种新的需求管理模式，并将该模式通过嵌入式软件产品平台来实现，以有效解决需求管理过程中存在的问题。 关键词：需求管理；需求评审；需求变更；版本控制；需求跟踪 0 引言 St
2、andish Group 从 1994 年到 2001 年的 CHAOS Reports 证实导致项目失败的最多的原因就是“变更用户需求”1。因此避免失败和提高项目的成功率需要进行需求管理。 目前对需求进行管理主要是使用 IBM Rational RequisitePro、IBM Rational Doors 等工具或使用 excel 进行人工管理， 但对需求的变更管理和版本管理往往借助第三方工具（如 IBM Rational ClearCase、IBM Rational ClearQuest） ，不能在同一个平台中对需求进行有效管理，导致相关技术文档的源头不唯一，需求追溯性变差，同时增加了管
3、理成本。1 需求管理过程概述 需求管理的主要活动包括需求确认（主要由用户和项目组共同对软件研制任务书和需求规格说明进行评审） 、需求变更（包括需求更改和版本控制）和需求跟踪控制。 2 需求管理存在的问题 2.1 需求评审的问题 当前对需求的评审一般都是基于文档化的文件进行评审，评审的时候不容易记录问题对应的需求项，问题的提出人等信息。这带来的问题为：给手工记录带来了很大的压力；评审结束之后，很多问题不知下文；不能充分统计需求评审问题以便跟踪问题并作为组织改进的依据。 2.2 需求变更控制问题 当基于问题、客户新需求等对需求进行变更时，目前国内相关单位基本上都参考2提交更改申请，但更改申请往往是
4、纸质的或是基于变更管理系统的，没有与需求管理工具进行集成（IBM Rational Doors 除外） ，且对需求变更的描述一般比较粗，不能有效记录需求变更历史（如需求项、问题提交人、需求修改时间等信息） 。 2.3 需求版本控制问题 目前业界内相关商业需求管理工具3（如 IBM Rational Doors 等）基本不具备或不能与版本管理工具进行集成，从而使得相关技术文档不能直接进入版本管理系统中，使得技术文档管理源头不唯一，可能导致各个系统中软件技术状态不唯一，增加了管理的难度。 2.4 需求跟踪问题 目前业界内很多相关单位通过手工方式使用 excel 进行需求追踪管理，导致需要额外存储需
5、求跟踪矩阵，且记录不方便。 3 解决问题的方法 因此，需求管理的理想模式（见附图）是：在需求评审的过程中能够通过一个工具自动记录需求评审的问题，自动记录需求变更的历史并做好需求追踪、在时机成熟时将需求文档提交到开发库、受控库或产品库。为了实现该模式，在嵌入式软件产品平台中借助配置管理手段辅助需求管理，确保需求的变更控制、版本管理与配置管理融合的同时，解决 2.1、2.2、2.3、2.4 的问题。 3.1 有效的评审 针对 2.1 中存在的不能有效记录评审人、评审问题、问题落实情况、问题对应的需求项、分析统计问题等问题，在软件需求管理的过程中，相关人员在嵌入式软件产品平台上按附图对需求管理范畴内
6、所有文档（软件研制任务书、需求规格说明、软件设计说明、软件代码、单元测试用例、部件测试用例、配置项/系统测试用例）进行项目级评审，对软件研制任务书、需求规格说明、配置项/系统级测试用例及项目级评审达不成一致意见的问题进行院级评审。在需求评审的过程中设置一名精通软件工程过程改进并从事过软件研发与管理的人员担任项目管理秘书，负责跟踪、协调评审过程中问题，并从评审问题中提炼相关内容纳入到组织的评审检查单中。 首先进行项目级评审。软件研制任务书、软件需求规格说明等需求文档（一个需求文档包含若干个需求项）的编制人首先按照4格式要求在嵌入式软件产品平台中进行需求定义（需求定义内容主要包括需求项名称、需求项
7、内容） ，然后提交需求定义内容，使其转换为需求项列表（需求项列表主要内容包括每一个需求项唯一编号、需求项名称、需求项内容、版本（初始版本为 1） 、审查列表等信息）在评审人员的审查界面中显示。评审人员参考组织的评审检查单在审查列表中填写评审问题，并给出评审结论（通过或不通过） 。对每一需求项，如果有一个人的结论为不通过，则该需求项评审的结论为不通过（其中初始结论为待审状态） ，否则为通过。对于不通过的需求项，如果编制人接受修改意见，则修改完成之后，所有评审人员对修改的需求项重新进行项目级评审直至问题关闭。对于编制人和评审人员达不成一致意见的需求项，则由项目管理秘书提交院级评审进行决策。 院级评
8、审时机为项目级评审结束（包含项目级评审通过、项目级评审未通过但需要项目管理秘书提交院级评审进行决策）之后，对属于院级评审范畴内的内容进行评审。如果院级评审不通过，则按图 1 反馈问题给修改人进行修改，然后重新进行项目级评审和院级评审，直到通过。与项目级评审相比，院级评审需要院级型号副总师和用户参与评审。 在评审的过程中，通过在嵌入式软件产品平台中进行问题记录和跟踪，确保了被评需求文档的质量，并有利于组织过程改进。 3.2 需求与变更、版本紧密关联 对 2.2、2.3 中存在的需求管理与变更管理、版本管理分离的问题，相关人员在嵌入式软件产品平台中按图 1 对需求的变更与版本控制采取以下处理方式：
9、 （1）对于提交项目级评审之前的需求项，文档编制人员在嵌入式软件产品平台中可以任意对需求进行修改，且不形成需求项版本； （2）对于已提交项目级评审，未进行院级评审的需求项，文档编制人员可以对需求项进行修改，但每修改 1 次都会记录修改前后的状态，且当前需求项版本在原有版本上加 1（如只修改了 1 次的需求项版本为2） 。当所有的需求项都通过项目级评审之后（即需求文档具备提交开发库条件） ，需求文档编制人在嵌入式软件产品平台中提交入开发库申请，开发库配置管理员依据配置管理规定在嵌入式软件产品平台中对需求文档给出开发库配置标识（以便冻结状态，供软件测试人员进行单元测试、部件测试等） ； （3）对于
10、项目级评审结束（包含项目级评审通过、项目级评审未通过但需要项目管理秘书提交院级评审进行决策）之后提交院级评审的需求文档，如果院级评审不通过，则文档编制人员修改需求项，系统自动记录需求项修改历史；如果院级评审通过（即需求文档具备提交受控库条件） ，需求文档编制人在嵌入式软件产品平台中提交入受控库申请，受控库配置管理员依据配置管理规定在嵌入式软件产品平台中对需求文档给出受控库配置标识（以便冻结状态，供测试人员开展配置项/系统测试等） ； （4）当需求文档入受控库或产品库之后，如果需求需要变更（含测试发现问题等原因需要更改的非新增需求，新增需求等） ，则文档编制人员必须提交需求变更申请并选择需要修改
11、的需求项（说明更改原因、进行影响域分析等） ，并通过型号副总师审批之后，需要修改的需求项才处于可修改（对于非新增需求）或可评审（新增需求）状态。然后相关人员重新进行需求修改、进行项目级评审、提交开发库、进行院级评审、提交受控库、提交产品库操作等。 在需求的变更与版本控制的过程中，通过在嵌入式软件产品平台中融合需求管理与配置管理，解决了需求变更历史不能有效记录，需求文档不能直接进入软件版本管理系统导致源头不唯一可能产生的技术状态不唯一的问题。 3.3 基于平台的需求跟踪 对 2.4 中存在的用 excel 进行需求跟踪不利于记录的维护和存储的问题，通过在嵌入式软件产品平台中设置需求追踪功能，相关
12、文档编制人只需在下游的需求项列表中选择上游的需求项并进行关联，系统自动建立任务书-需求规格说明-设计说明-代码-测试用例之间的需求跟踪矩阵并可随时查询。通过此方式解决了使用 excel 等进行追踪不方便管理的问题。 4 结语 本文针对业界内需求评审、需求的变更与版本控制等过程中存在的问题，从理论上将需求管理与软件配置管理（包括软件变更管理和配置管理）有机融合，并在此基础上创新性提出了一种新的需求管理模式，并将该模式通过工具来实现，确保了需求能够有效评审与跟踪，需求的变更和版本管理能够与软件配置管理业务有效融合， 使得企业能够高效进行需求管理，从而保证了软件产品的质量，并减少了管理成本。 参考文献： 1需求管理： IBM Rational 技术白皮书 EB/OL. 2004-08-01.http：/ 2中国人民解放军总装备部. GJB 5235-2004， 军用软件配置管理S. 北京：总装备部军标出版发行部，2004. 3国内外需求管理工具比较 R/OL. 2014-07-11.http：/ 4中国人民解放军总装备部. GJB 438B-2009 军用软件开发文档通用要求S.北京：总装备部军标出版发行部，2009.
