基于业务驱动的需求获取方法

邱会鲁等

摘要：针对需求获取中需求范围确定、需求沟通及理解、需求定义等方面存在的问题，对需求获取方法进行了新的探索，提出了一种基于业务驱动的需求获取方法，其中包括支撑业务驱动过程的业务-需求映射模型，维度-需求体系应用和业务驱动需求，采用了层次分析法、质量功能部署、业务分解结构和统一建模语言UML等技术。应用结果表明，该方法具有可操作性，能够有效提高需求获取工作效率和质量。

关键词：需求获取；业务驱动；业务-需求映射模型；维度-需求体系；层次分析法；质量功能部署

DOIDOI：10.11907/rjdk.143673

中图分类号：TP301

文献标识码：A 文章编号文章编号：16727800（2015）001000404

作者简介作者简介：邱会鲁（1990-），男，山东曲阜人，山东科技大学信息科学与工程学院硕士研究生，研究方向为软件工程。

0 引言

需求获取是软件开发的基础，对后续的分析设计及开发实施有重大影响，同时也决定着客户对需求完整性、正确性的认可度。Standish Group的研究表明，至少有1/3以上的项目是因为与需求获取、需求建档和需求管理相关的原因而陷入困境[1]。目前，需求获取仍是一个需要关注和深入研究的领域。

文献[2]中提出了与需求获取息息相关的3个至关重要的因素：①应搜集什么信息；②要求解决的问题列表；③用户对解系统行为或结构施加的约束。与这些因素相关的需求范围确定、需求沟通与理解和需求定义等存在诸多困难。针对需求获取的问题和难点，一些研究提出了基于领域知识和本体论的需求获取方法[35]，以及基于情景与基于用例驱动的需求获取方法[67]等，但对于如何从业务角度驱动软件需求获取过程的研究还比较少，本文提出的基于业务驱动的需求获取方法源于对需求层次化[8]及RUP业务建模的思考。需求获取具有层次化的特点，而且各层次之间存在紧密的关联。首先要有业务需求，业务不正确或不清楚，后续工作会受到很大影响；其次是用户需求，用户需求需要与具体的业务需求保持一致；最后是软件需求，涉及软件功能性和非功能性需求。这种思路提供了解决需求获取的主线，即业务驱动需求获取过程。

1 业务-需求映射模型

业务-需求映射模型由业务域和软件域组成，两个域之间存在选择性的映射关系。所谓选择性是指根据软件功能需求与用户需求进行业务筛选，此模型主要给系统分析人员提供界定软件产品范围依据。业务-需求映射模型如图1所示。

图1 业务-需求映射模型

1.1 业务-需求映射数据结构

根据业务-需求映射模型的特点，可以将需求数据抽象为以下基本结构：

（1）集合B、S、F与NF，B={x|x为业务需求}， F={yF|yF为软件功能需求}，NF={yNF| yNF为软件非功能性需求}，S={y|y∈F 或y∈NF}。

（2）序偶表示x与y的二元映射关系，R为映射关系集合，∈R。

1.2 业务-需求映射过程与规则

基于业务驱动的需求获取主要包括两方面映射：①用户需求与约束到软件的非功能性需求映射，这个过程通过质量功能展开技术QFD（Quality Function Deployment）进行选择映射；②业务需求到软件功能的映射，这个过程主要是通过层次分析法AHP（Analytic Hierarchy Process）标识业务需求优先级，并对其进行业务模型构建，通过用例转换方式转换为系统用例，并将其它相关业务模型转换为系统功能性描述。下面对两种映射进行介绍：

（1）用户及约束与软件非功能需求的映射。①标识与描述用户需求及约束条件；②对用户需求及约束进行重要度分析；③标识涉及的非功能性需求；④应用QFD关系矩阵；⑤整理出软件非功能需求。

（2）业务需求映射。①标识业务域需求；②利用AHP方法标识出业务需求优先级；③构建业务模型；④应用业务与软件功能映射规则；⑤整理出软件功能需求。

针对上述映射（1），通过建立QFD过程，对相关用户需求和约束条件进行映射，这种方法可以有效提高用户和软件项目内部横向和纵向沟通的有效性。而映射（2）各步骤制定了如表1所示的映射规则，映射规则从业务需求域元素入手，与软件需求元素进行关联，建立用户可以对照理解的系统概貌。

1.3 QFD与AHP应用

在映射（1）中主要采用广义的QFD技术，它是一种采用矩阵的形式量化评估目的和手段相互关系的分析工具，本文在传统关系矩阵的基础上进行了应用，对映射进行评估，确定非功能需求，确立的非功能需求关系矩阵如图2所示。

图2 QFD非功能需求关系矩阵

用户与约束需求重要度评估：用户需求与约束需求重要度分别用UHi（i=1，2，…，m）和CHi（i=1，2，…，n）表示，取值为5个等级：1表示不影响基本需求；2表示不影响主要需求；3表示比较重要；4表示重要的影响；5表示特别重要的影响。关系矩阵中关系度URij与CRij评估采用1、3、5、7、9等关系度等级：1表示该交点多对应的非功能需求和用户需求之间存在微弱的关系；3表示存在较弱的关系；5表示存在一般的关系；7表示存在密切的关系；9表示非常密切的关系；必要时采用中间等级，2表示介于1与3之间；4表示介于5与7之间；6表示介于7与0之间；0：表示空白，不存在关系。加权后的重要度定义为公式（1）：

Hj=∑mi=1UHiURij+∑ni=1CHiCRij（1）

如果第j项非功能性需求与多项用户需求和约束密切相关，并且这些用户需求和约束需求比较重要，那么Hj取值就越大，就表示这项非功能性需求越重要。在映射（2）中应用AHP方法。AHP方法即层次分析法，它将给定描述的目标进行成对比较，分析其相对重要程度，据此定量地得出各目标的权重，从而确定优先级。首先，以B=[bij]m×m表示业务需求重要度组成的判断矩阵：

在问题空间到软件空间的需求映射中，业务需求、用户及约束需求重要度的引入是十分重要的环节。首先，重要度的引入有效避免了需求收集与定义的随意性，加强了需求收集的管理；其次，可量化的需求为系统分析人员进行软件功能与非功能需求分析提供了重要的数据支持，保证了需求映射转换的可靠性。重要度计算的结果与定性分析的结果基本一致，但在各参量计算过程中，从大量的业务需求、用户及约束需求中确定参量的比较规模十分复杂，这要求系统分析人员考虑业务需求集的划分、对用户需求的合理性判定及用户对约束需求的重视程度等因素，这增加了需求定义的工作量。

2 维度-需求体系

2.1 维度-需求体系表示

维度-需求体系（Dimension Requirements System），以下简称为DRS，是依据维度的思想构建一种多视角获取需求的可视化工具。已有的多维度需求获取工具研究有三维需求模型[9]和对等多维度需求映射模型[10]，前者主要对技术、过程及人3个维度进行定义与应用，发现和解决冲突，后者主要探讨需求及功能维度的关系，并对两维度进行夹角定义。在基于业务驱动的需求获取方法中，DRS为每个维度预先定义需求工程中的相关概念，根据需要建立二维度-需求体系（2-DRS）（见图3）和三维度-需求体系（3-DRS）（见图4），DRS主要从业务维度入手，展开对业务需求、用户需求和软件需求的收集和挖掘。

图3 二维度-需求体系

2.2 维度-需求体系应用

维度-需求体系选取业务需求a、用户角色b、用户需求c、功能需求d及非功能性需求e为关注维度，首先以业务为第一关注维度，构建维度-需求体系进行需求获取，然后在获取结果的基础上进行不含业务维度的维度-需求体系获取。这样做的主要目的是按照业务驱动的总体思想进行需求获取，保证需求获取的层次性和有效性。

维度-需求体系的应用特点：

（1）维度-需求体系提供了一种可视化的需求交流环境，它可以将用户与系统分析员各自熟知的领域集合在一起进行展示，方便双方进行交流。

（2）维度-需求体系具有潜在的分析特性，它的维度点在计算机中存储为二元组或三元组结构，这就为计算机自动进行静态需求分析提供了基础。

3 需求获取方法

基于业务驱动需求获取方法，要求系统分析人员与用户通过业务诱导方式逐步推进需求获取过程，通过业务分解结构BBS（Business Breakdown Structure）建立业务域，在业务映射模型基础上构造维度-需求体系，在收集过程中应用统一建模语言UML（Unified Modeling Language）建立相关模型。图5给出了基于业务驱动的需求获取过程。

（1）明确需求涉众。明确需求涉众是软件项目开始的首要环节，也是需求获取工作能否顺利完成的关键要素。理想情况是在软件需求发展中有许多参与者参加，但现实并非如此，重要的是，我们认识到这些不同利益者和特定角色的存在，以确保正确的人在正确的时间参与，并且使正确的期望得到实现。

（2）建立业务域。建立业务域是驱动整个过程的基础，要明确与业务相关的组织结构、业务术语、业务内容、业务实体、业务规则、业务流程和业务前景。下面以软件工程人才实践教学平台项目为研究实例，按照基于业务驱动需求获取方法流程，其中BBS应用实例如图6所示。

在完成BBS结构收集的同时进行相应业务记录，综合实践评价业务明细记录举例如表3所示。

（4）构造与应用维度-需求体系。根据业务映射模型构造维度-需求体系。维度-需求体系作为一种展现与交流的工具，提供了一种多角度需求获取的方式，帮助用户和系统分析员在某一维度上进一步收集需求，这个过程可以查缺补漏和消除部分冲突需求。图9是综合实践授课模块中几项业务与软件功能的二维度需求体系应用示例，它清晰标注了相应的业务与软件功能，方便用户理解及与系统分析人员沟通。

（5）需求获取确认。需求获取确认是一个分析与评价的过程，对基于业务驱动的过程进行审查，最后与用户达成共识。要对建模过程中的业务用例、业务活动图及业务实体类图等进行建模检查，对系统建模与文档进行检查。