信息系统的功能需求分析方法研究

陈 垚，刘 奎，高 峰

(1.河北东软软件有限公司，河北 秦皇岛 066004；2.秦皇岛市政务数据治理及社会化应用工程技术研究中心，河北 秦皇岛 066004)

chenyao@neusoft.com;liuk@neusoft.com;gao-f@neusoft.com

1 引言(Introduction)

当前在大型信息系统开发中，大多数软件公司都能遵从软件工程的软件生命周期各阶段的划分，也能在实际工作中按照阶段执行，但实际成本与预估成本还是存在较大差异。通过实际工作发现，造成实际成本高的原因不是发生在内部开发阶段，而是发生在系统上线释放后。系统上线释放后，客户需求不断调整，系统反复修改，导致成本不断增加。

系统上线释放后的需求调整，可能有两种情况：一种情况是需求确实在上线后发生变化，造成较大规模的修改，一般这种情况可以通过商务谈判进行缓解。还有一种情况，就是前期的需求分析成果不能描述出业务的实际需求，不能满足客户的实际意愿，导致系统上线释放后发生大规模调整。通常第二种情况是造成实际成本与预估成本偏差较大的主要原因。

结合上述问题，建立一种功能需求分析方法，提高需求分析的成果质量，客观反映客户的实际意愿，避免系统上线释放后的大规模调整，有效控制开发成本。

2 需求过程中的问题(Issues in the requirement process)

软件系统需求常常分为功能需求、非功能需求和领域需求。功能需求包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需明确声明系统不应该做什么。需求过程是建立客户与软件开发工程师的桥梁，一方面使客户能够理解和确认，通过收集、沟通及汇总分析出的真实需求，另一方面为后续系统设计和开发提供依据，是未来系统设计的工作输入。在信息系统的功能需求分析时，主要存在以下几类问题。

一是需求分析仅是对现有业务流程的“翻译”。没有结合信息技术将现有业务流程进行重新构造，也没有发挥出信息技术便捷、高效的作用。

二是采用的基本方法难以清晰描述需求。采用基本流程图或基本框图将实际业务分解为功能模块，围绕功能模块开展需求调研，客户难以与实际业务相结合，不能反映真实需求。

三是需求分析不完整。需求分析仅描述正向业务流程，业务流程不完整，系统上线后的逆向业务难以应对。

结合上述问题，通过对需求工程中需求分析方法的研究，建立一种功能需求分析方法，提高需求分析的成果质量，使需求过程能够切实反映客户的实际意愿，避免软件系统上线释放后大规模调整，有效控制开发成本。

3 功能需求分析方法(Functional requirement analysis method)

信息系统实际是对信息的管理，信息也就是数据，是对业务流转过程中产生数据的管理。采用5W1H分析法能够易于客户对于需求的理解，明确反映出真实需求。5W1H指从原因(何因，Why)、目标(何事，What)、时间(何时，When)、地点(何地，Where)、角色(何人，Who)、方法(何法，How)等六个方面提出问题进行思考。首先明确解决什么问题或为什么要做，然后明确谁在什么时间、什么地点、做什么，最后明确如何去做。只要围绕以上几个要素来描述需求，获取真实的需求应该不是问题。

Why：为什么要做，是原因；

What：做什么，做成什么，是目标；

When：什么时候做，是时间；

Where：在哪儿做，是地点；

Who：谁来做，是角色；

How：怎么做，是方法。

功能需求分析方法主要由目的和范围表示方法、业务改变表示方法、业务流程表示方法、业务单据表示方法及接口需求表示方法五部分组成。

3.1 目的及范围表示方法

对于大型信息系统，可能由许多功能模块构成，功能需求围绕功能模块构建。功能需求不仅描述信息系统的建设目的，重点关注业务目标或解决的问题。对于业务目的，组织结构中不同的角色关注点可能也不一样。对于管理者来说，更关注管理过程的改变或业务流程的重构，由此带来的可能是相关政策、管理办法或组织结构的改变。对于最终用户来说，更关注业务流程的简便性或实际操作的便捷性。在业务目标中，需要关注组织结构中不同角色的期望。

功能需求的范围通常包括两部分：业务范围和实施范围。业务范围需要描述功能模块覆盖的业务或流程，例如：本次业务范围为采购模块中的采购接收业务。实施范围需要描述系统上线后的使用范围或组织范围，包括组织、地点、角色等。通过实施范围的识别，可以界定功能需求覆盖的完整性，也为系统上线前的测试提供依据。实施范围也是容易遗漏或模糊的。

在必要时，为了使甲乙双方对功能需求的范围更加明确，可以补充不包含的业务范围和实施范围。例如：本次业务范围为采购模块中的采购接收业务，但不包含钢材类物料。

3.2 业务改变表示方法

首先，需要明确系统建设的相关原则。系统建设的相关原则指的是现有相关政策或管理办法，可以是业务管理要求、技术要求或实施要求，这些都是系统建设的依据，需要被获取及提及的。

其次，需要明确系统建设的业务改变。信息系统建设，如果只是业务流程的简单电子化，不能带来足够的经济效益或社会效益。在目的及范围表示方法中，我们提到对于管理者而言，更关注于管理过程的改变或业务流程的重构，希望通过新技术的引入带来现有业务流程的改变。需求分析需要结合信息技术手段，讨论并提出业务流程的重新设计及改善，使信息技术发挥出便捷、高效的作用。

再次，需要明确对组织结构改变的建议。为了达到业务目标，信息技术的引入带来管理过程的改变或业务流程的重构，有可能对现有组织结构、岗位和人员产生调整。那么在需求分析过程中，除了对业务流程重新设计，还需要提出组织结构、岗位和人员调整的必要建议与要求。这些很可能会构成未来系统上线释放后的依赖。

在现有业务原则下，通过需求分析和信息技术的引入，对管理过程或业务流程重构，对组织结构、岗位和人员进行优化，使信息系统建设切实带来经济效益或社会效益。

3.3 业务流程表示方法

通常业务流程分为正向业务流程、逆向业务流程、特殊业务流程。满足正向业务流程和逆向业务流程，操作场景就可以形成闭环，可以初步认为需求是完整的。正向业务流程指顺序发生或正常情况下发生的业务流程，多数情况都只发生正向业务流程。如：订单付款流程。逆向业务流程指当正向业务流程发生问题而产生的业务回退或反冲流程。如：订单退款流程。特殊业务流程指偶然或特例情况下的业务流程，与正向业务流程又不完全一致，为了满足系统上线后的业务符合，单独规划和设计的业务流程。如：订单付款流程中可能有内部付款业务。通常情况下，为了保证需求的完整性，正向业务流程、逆向业务流程是必须存在的，特殊业务流程只有当需要时才会出现。

业务流程采用泳道图的表示方法更容易理解。将业务流程中的角色划分为一个个泳道，每个角色对应的活动节点散落在各个角色对应的泳道里。泳道图是将模型中的活动按照角色组织起来，不同的角色通过不同的泳道区域来表示。当然，为了便于阅读和理解，泳道图的编制需要遵从流程图的基本规则要求，如：流程必须有开始节点和结束节点；流程结束必须连接结束节点；一个节点可以有多条输入，但只能有一条输出等。泳道代表的角色解决了Who的问题，业务流程中的先后顺序解决了When的问题。

业务流程需要描述业务的全貌，包括流程中的所有活动节点。通过业务流程图中的活动节点，解决What的问题，也就是做什么的问题。对于活动节点，通常采用“动词”加“名词”的命名方式，可以快速描述活动节点所完成的活动。比如：生成订单，核对库存等。为了便于客户及软件工程师的理解，需要建立一套活动节点示例，以区分不同节点代表的含义。活动节点示例如图1所示。

图1 活动节点示例Fig.1 Active node example

活动节点示例的描述如下。

开始：描述流程的开始；

结束：描述流程的结束；

系统内：本系统内的活动节点；

系统外：系统外的活动节点；

系统内单据：本系统内产生的业务单据；

系统外单据：系统外使用的业务单据；

子流程：系统的其他业务流程；

其他系统：其他系统的活动节点；

判断：系统多输出的判断分支。

在业务流程表示时，除了系统内的活动节点，同样需要关注系统外的活动节点或其他系统的活动节点。很多情况，需求工程师只描述系统内所涉及的活动节点，忽略了系统外的活动及其他系统中的活动，认为系统内的活动节点才是需要关注的。这种描述方式的问题在于难以将完整的业务流程连贯起来，或不能反映真实业务，也不利于客户的阅读与理解，对于系统的业务测试及系统上线后的业务难以起到指导作用。

在表示业务流程时，除了建立活动节点外，还需要描述活动节点的IPO，即数据输入(Input)、数据处理(Process)、数据输出(Output)。通过在业务流程中的活动节点上带入数据输入和数据输出，完成活动节点的完整描述。在信息系统中，信息通过活动节点的加工，进行信息的处理和存储，在这里的信息通常也称为“单据”。通常约定，在活动节点上方标注的“单据”作为该活动节点的数据输入，在活动节点下方标注的“单据”作为该活动节点的数据输出。上一活动节点的输出“单据”通常为下一活动节点的输入“单据”，这一原则也通常作为需求流程的完整性验证。业务流程图示例如图2所示。

图2 业务流程图示例Fig.2 Business process diagram example

由于业务流程图上的活动节点表示有限，需要在业务流程图后，针对每一个活动节点进行详细描述。详细描述重点从业务描述、数据输入、数据处理、数据输出和业务约束五个方面进行表示。业务描述是指从实际业务的角度描述该活动节点是何种角色，在何时、何地完成何种工作。数据输入指完成工作的输入数据或输入“单据”，数据输入可以是一张单据也可以是多张单据。数据处理是指如何完成工作，重点描述的是数据加工逻辑或加工算法，解决How的问题，就是怎么做的问题。如：单据编号的产生逻辑、数据的计算算法等。数据输出是指完成工作的输出结果或输出“单据”，数据输出可以是一张单据也可以是多张单据。业务约束是指在哪些限制或约束下可以完成工作，如：单据状态、数据权限、特殊业务约束等。

相对基本框图的表示方法，采用5W1H分析法及泳道图表示业务流程，能够更清晰地描述Why、When、Where、Who、What和How六个核心要素，明确反映出真实需求。

3.4 业务单据表示方法

业务单据指的是我们在业务流程图中用到输入“单据”和输出“单据”。在需求分析中，重点描述本业务流程产生的单据或输出“单据”。业务单据主要从单据样式、单据数据项、单据状态方面进行表示。通常现有业务规则中已经具有业务单据，通过信息技术的引入，可能对现有单据的样式产生变化或影响，通常需要重新设计单据样式、规划单据数据项及单据状态，以保证业务流程的正常流转。如：增加单据编号、各项小计与合计等。

3.5 接口需求表示方法

当前的信息系统建设，很少是建设一个孤立的系统，通常会与已建系统产生联系，接口是系统间交互方式，可能是使用其他系统的数据，也可能是产生的数据被其他系统使用，那么就需要进行接口需求分析。通常接口需求也为数据接口，分为数据输入的接口和数据输出的接口。在进行需求表示时，接口需求基于业务流程中的某个活动节点进行表示，同样需要对接口进行详细描述，接口需求的描述包括编号、名称、描述、类型、调用参数及回传参数等。

4 功能需求验证方法(Verification method of functional requirement)

功能需求的验证包括有效性验证、完整性验证、一致性验证。有效性主要验证是否清晰描述了业务需求的目的、业务范围及实施范围，识别由于信息技术的引入是否对现有业务流程进行重新设计等；完整性主要验证是否覆盖正向业务及逆向业务，活动节点的输入是否为前面活动节点的输出，业务流程的接口需求是否体现等；一致性主要验证需求的前后是否存在二义性，如：活动节点的输出单据与定义是否一致，活动节点中的单据状态与定义是否一致等。功能需求验证项如表1所示。

表1 功能需求验证项Tab.1 Functional requirement verification items

功能需求验证的审查方式主要采用人工审查的方式，讨论审查后形成需求成果基线，作为系统设计的输入。

5 方法应用(Method application)

5.1 项目背景

以某企业费用控制系统为具体场景，将该功能需求分析方法在差旅报销审批模块中加以应用。该企业的情况是，差旅报销审批没有使用系统管理，审批过程以纸质单据流转。问题主要在两个层面：一是审批周期长。审批人经常出差，难以及时审批；过程中存在票据异地邮寄审批的情况，也会增加审批周期。二是费用核算有待进一步提高。通过纸质单据填写的项目编号，可以将费用归集至项目，但不能明确至差旅出行和差旅借款。报销费用依据纸质单据手工计算，难免存在错误。希望通过信息系统建设解决以上问题。

5.2 需求分析

对于差旅报销审批模块的建设目的，针对管理者和最终用户给予清晰描述。对于企业管理者，希望进一步提升报销过程中的合规性，加强费用发生的成本中心与项目的归集。对于最终用户，更关注优化报销流程，提升报销效率。由于差旅费用审批只是费用控制系统中差旅报销的一个模块，在业务范围中需要清晰描述差旅报销审批业务，实施范围需要明确企业的组织机构及分支机构。

从前期的需求调研中了解到，该企业制定及发布了《差旅费借款与报销专项管理制度》，并且当前的业务流程也是按照该管理办法执行，系统建设也需要遵从该管理办法作为建设原则或建设依据。之前已经提到信息系统的建设不仅是业务流程的翻译或简单电子化，对于管理者和最终用户均有一定的改善期望。经过对管理办法分析，其中的部分内容已不适用，基于此提出以下业务改变：采用电子票据作为报销审批依据；审批结束后打印并粘贴纸质报销单据提交报销会计；为报销借款冲账，建议补充差旅出行申请流程和差旅借款流程等。在差旅报销审批模块，并未涉及对组织结构改变的调整。

经过需求调研分析，差旅报销审批模块的业务流程涉及报销人员、初级审批人、报销会计、费用审批人四个岗位角色，那么在业务流程图中建立四个泳道。结合建设目标和关键用户期望，新业务流程的改造思路是，审批过程中不再使用纸质票据，以电子单据及电子票据在系统中流转；审批结束后，由报销人员打印报销单据并粘贴纸质报销单据，提交报销会计。差旅报销审批业务流程如图3所示。

图3 差旅报销审批业务流程图Fig.3 Business flow chart of travel reimbursement approval

在图3差旅报销审批业务流程中，以CCS-AP-TV-1-01填写差旅报销单的活动节点为例，数据输入(Input)是旅费发票、住宿发票、差旅出行申请单，数据处理(Process)是填写差旅报销单，数据输出(Output)是差旅报销单。在业务流程图后还针对每个活动节点的数据输入、数据处理和数据输出进行了详细描述。该业务流程产生的单据是差旅报销单，结合纸质差旅报销单样式和系统需要重新进行规划设计。该业务流程会与邮件系统对接，发送审批通过邮件、发送审批不通过邮件，在接口需求中对邮件系统对接进行了详细描述。

5.3 需求验证

在需求分析成果完成后，组织关键用户、需求人员、开发人员和测试人员，依据表1功能需求验证项，以会议的方式对需求成果的有效性、完整性、一致性进行验证和审查。经过多次反复讨论和修改，最终形成需求成果基线版本。该基线版本作为系统设计和开发的工作输入。

5.4 应用效果

在某企业费用控制系统中引入该功能需求分析方法，对差旅报销审批流程进行了重新规划，解决了审批流程中传统纸质单据效率低的问题，提出的相关业务改变意见也被客户接受。结合5W1H分析法及泳道图方法的业务流程表示方法，易于客户理解，清晰反映实际需求。在需求验证和审查过程中，通过有效性、完整性、一致性验证，提高了需求分析的成果质量。该系统上线释放后运行平稳，未发生大规模调整，有效控制了开发成本。

6 结论(Conclusion)

结合5W1H分析法及泳道图方法，从需求分析、需求验证提出的这种功能需求分析方法，有效缓解需求分析过程中的实际问题，提升需求分析的成果质量，实现信息系统开发的质量控制前置。经过多个实际大型信息系统应用，该方法能够有效避免或减少软件系统上线释放后大规模调整，控制开发成本，尤其适合业务逻辑复杂的信息系统。