一种基于EA的需求管理实施方案

孟祥文

摘要：良好的需求管理是软件项目圆满完成的保障，基于IBM Rational系列产品的需求管理方案代价高，安装使用复杂，不能有效满足中小型软件公司的需要。针对中小规模项目，給出一种利用EA及其扩展机制实现的轻量级需求管理实施方案，可以提高中小型软件开发团队需求管理的效率和效果。

关键词：需求管理；扩展机制；需求跟踪；需求变更

中图分类号： TP319

文献标识码： A

文章编号： 16727800（2017）004016602

0引言 在软件开发领域，需求工程越来越受到重视，需求建模质量往往是决定项目成败的关键，在面向对象方法中通常采用用例（Usecase）模型来描述需求。然而用例模型主要用来描述系统的功能需求，对于非功能需求及需求管理则必须借助于其它手段。 需求管理是一种用于定义、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致[1]。实际项目中需要借助工具辅助进行需求管理工作。 IT168作的一项调查显示[2]，需求管理工具在国内企业和开发者中的使用比率是 Rational Requisite Pro 占 48.7%，Borland Caliber RM占20.6%，而TelelogicDoors占3.2%，很多中小公司还在使用 Word 或者 Excel 管理需求。目前影响最大的需求管理工具是IBM公司的Rational RequisitePro，它以数据库为核心，同时提供 与Microsoft Word的整合。它将与数据库集成在一起，支持用自然语言清晰地表达需求，并同时组织它们，用户对数据库中特性的修改可以同步到Word文档中，同时用户对文档的修改也可以同步到数据库中[3]。通过与其它Rational系列软件产品的广泛集成，给软件工程生命周期内的各个阶段都提供了强大、方便的需求信息查询、跟踪、管理功能。然而使用Rational系列产品代价较高，安装和使用也比较复杂，提供的是一个重量级的需求管理解决方案，对于大多数中小公司并不适合。 Enterprise Architect（EA）是澳大利亚Sparx软件公司的UML建模工具[4]，是为数不多的可将需求管理与其它软件开发规范集成为一体的UML工具。经过项目实践发现，通过EA的需求模型和提供的扩展机制，可以完成需求管理的主要任务，能够满足大多数项目对需求管理属性的描述要求、需求模型的变更控制要求以及与其它模型间的可跟踪要求等。本文将介绍利用EA进行需求管理的解决方案。1需求属性定义与扩展 需求是指系统必须符合的条件或具备的功能，要确定项目的宏观要求，定义项目的业务需求，明确项目的目标与范围，还包括对系统开发过程的约束。在进行需求管理时，往往需要从多个角度描述一项需求的属性。在EA提供的需求模型中，定义了一些标准的需求属性，如：状态、难度、优先权、阶段、作者、版本和类型等，用户可以直接选用这些属性描述需求的基本性质，如图1所示。实际项目开发中可能经常需要描述某些需求的一些额外管理属性，例如：任务开始时间、稳定性、延迟处罚、花费等。如果需要的额外需求管理属性数量较少，可以利用UML提供的标记值技术（Tagged Value）扩展技术定义外部需求标记。图2描述了一个枚举类型的Review Status标记的定义，定义一个标记时需要描述。 Type=Enum；//标记为枚举类型 Values=Not Reviewed，Accepted，Rejected； //枚举取值集合 Default=Not Reviewed；//默认值自定义的标记Tag默认不会显示在需求视图中，但可以通过设置需求显示开关中的Feature and Compartment Visuality Tags选项，以控制自定义需求管理属性的显示。

如果扩展的需求管理属性数量较多且具有一定的通用性，为了方便在其它项目中使用，可以利用Profile机制定义一组EA标准元素的扩展并设置相应的工具箱，并把这组扩展保存到文件中以便于重用。图3是利用Profile机制对功能需求和非功能需求管理属性进行扩展的扩展视图，可以将该Profile视图存贮为XMI格式的文件，在其它项目中只要导入该Profile文件，就可直接描述功能需求的RequiredBy、ReviewCompleted、ReviewStatus、 Reviewer、Reviewercomments、Riskstatus、Risktype等和非功能需求的Costinvolved、 RequiredBy、Risk、Risk status等管理属性。

2需求变更 随着用户业务及外部环境的变化，用户对系统提出的需求经常会发生变化，因此需求变更会不可避免地频繁出现。EA可以通过建立需求基线，制定变更控制流程，并形成文档来处理需求的变更问题。 针对外部需求的更改请求和问题，可以用两种不同方式来定义： （1）使用需求的Maintenance View描述和管理每项需求变化所要解决的问题、变更的内容、必须修改的问题及完成需求变更的具体任务。图4的需求维护视图可以描述需求变更的内容、变更报告人、提出日期、变更状态、变更解决责任人、变更解决日期、变更优先级等信息。

（2）先定义常规元素类型“Issue”（问题）and “Change”（变化），描述需求变更所解决的问题及变更的内容，然后链接到某个变化的外部需求上。 在项目的整个生命周期中，需求变更可能会发生很多次，有时需要管理某些需求元素的变化历史，这可以通过审计视图（Audit View）来实现，开启审计功能可以记录 Enterprise Architect 中的模型变化。它将记录谁修改了一个元素，什么时间和怎样修改的，并附有这个元素之前的状态。这在记录需求模型历史记录方面极为有用。3需求跟踪 在实际项目开发中，经常会发生这样的情况：测试人员在进行测试时，发现某些需求并未实现，诸如此类问题，很大一部分原因是需求跟踪未做好。EA中的需求跟踪可通过建立与维护“关系矩阵”来实现，在关系矩阵中，可以定义不同抽象级别、不同阶段模型元素之间的语义联系。EA中支持的关系类型较多，也可以根据需要通过UML扩展机制进行扩展。其中Trace、Realize和Refinement经常用来表达追踪关系，通过需求跟踪矩阵可以描述每个需求同后期系统模型元素之间的联系，确保后期软件制品产品与用户需求的一致性。这些元素包括其它类型的需求、体系结构、其它设计部件、源代码模块、测试及帮助文件等。图5描述了需求模型与用例模型之间的跟踪关系，纵向的需求模型元素作为源，横向的用例模型元素作为目标，右下角矩阵中的箭头代表两个模型元素之间存在跟踪关系。4结语 针对中小规模软件企业需求管理的现实问题，本文利用UML标记值扩展技术及Profile机制弥补EA标准需求管理属性的不足，利用维护视图处理需求变更的记录和控制，利用需求跟踪矩阵定义有组织的层次需求模型，跟踪从系统需求到模型元素的实施，对于中小规模项目中的需求管理问题给出了利用EA工具实现的一种轻量级解决方案。

参考文献：

[1]DEAN LEFFINGWELL，DON WIDRIG.软件需求管理：统一方法[M].蒋慧，林东，译.北京：机械工业出版社，2002：914.

[2]姬晓鹏，吴朝晖.需求管理的一个系统解决方案[J].计算机工程，2003（19）：7779.

[3]赖信仁.UML与Enterprise Architect 7.5团队开发实务手册[M].北京：电子工业出版社，2010：1020.

[4]秦众森，李娟.需求变更管理过程及其工具分析与展望[J].计算机工程与设计，2009（11）：26012605，2614.（责任编辑：孙娟）