信息系统需求分析流程与方法

王 爽，马又良，刘 洋（.中讯邮电咨询设计院有限公司，北京00048；.中国联合网络通信集团有限公司，北京00033）

1 系统需求分析现状及现存问题

企业信息系统需求，是指业务部门根据企业运营发展或管理的需求向后台系统支撑部门提出，需要支撑部门安排时间、人员并通过IT系统实现的功能及要求。

需求管理是系统软件项目中非常重要的工作。它是软件开发的基础和前提。只有在明确了软件需求之后才能开展有针对性的软件开发工作，并确定时间、成本和工作计划。另外系统需求也是最终目标软件系统验收的标准。

企业信息系统需求管理工作中突出的问题包括以下几点。

1.1 需求分析管控分散独立

现有系统前期建设过程中，在一组业务需求被提出后，后台支撑部门通常会组织系统新建项目。此类需求未经过系统的分析论证，是否可在现有系统功能上稍加改动、或通过组合、引用的方式实现。这种方式导致集团企业范围内出现大量的“烟筒式”系统，造成重复建设，且给后续系统整合、数据共享带来巨大难度。

1.2 系统功能性需求描述不准确

集团型企业的信息系统非常复杂和庞大，系统功能涉及多个部门、多管理层级。如何将软件需求描述清楚、全面、准确，是一项非常艰巨的挑战。需求描述模糊和不一致是导致以往信息系统项目失败的重要原因。

需求分析人员与用户在业务术语表达上有所不同，交流过程中可能会理解有误。特别是对于有二义性的需求，会导致不同的理解。

1.3 缺失IT 管理手段

目前的系统需求管理主要依靠“文档+表格”记录的方式，难以有效应对集中化系统建设过程中的挑战。

a）市场环境及公司管理要求变化，凸显系统需求“多、快、急”。

b）运营职能细分和系统解耦趋势，需求管理的范围扩大、复杂度增高。

这些都要求后台支撑部门构建规范的需求管理流程和方法，以满足对外海量需求的高效管理，对内参与需求建设的各方有效协同。

2 需求分析总体流程

需求分析总体流程包括用户代表、需求管理职能、系统建设职能3类角色。根据企业信息系统需求开发工作的特点，总体流程可划分为需求收集归纳、需求建模、需求评审、开发实施、需求实现及跟踪5 个部分，5个部分之间相互影响、相互制约，形成需求管理的完整流程（见图1）。

3 需求分析重点环节及方法

3.1 需求收集归纳

需求收集的方法包括以下几类，目的是收集用户真正面临的问题和业务场景。

3.1.1 资料收集

资料收集是指尽可能获取更多的信息和资料，用于理解系统相关的术语概念、流程，掌握领域知识，包括以下几点。

a）业务管理办法（规范）、相关制度流程。

b）业务流水记录、合同协议等。

c）相关的会议记录、笔记、客户的投诉。

3.1.2 访谈

面对面访谈是发现事实和收集信息的基本技术。面谈有2种基本形式：结构化的和非结构化的。

a）结构化访谈需要有一个明确的问题列表。

b）非结构化访谈更像非正式的会议，没有预定的问题或者预设的目的。

3.1.3 问卷调查

问卷调查是一种收集用户信息的有效方法，一般用来作为访谈的补充形式。问卷调查这种方法的优点在于回答者有时间去考虑如何回答，并且可以是匿名的，可避免受调查人员倾向性意见的影响。当需要很多人的观点而他们又是在地理上分散的时候，调查表非常经济实用。精心设计的题目和对结果的统计分析技巧是调查问卷达到效果的关键因素。

3.1.4 观察实习

有些情况下访谈和问卷都不能获得完整的信息，为解决这个问题，观察实习可能是一种有效的方法。

要使观察更具有代表性，观察实习应该持续较长的一段时间，在不同的时间段和不同的工作负荷下挑选时间进行。同时观察实习也是其他需求收集方法所获得信息的重要校验手段。

3.1.5 现有系统研究

研究现有软件系统是发现系统需求的宝贵方法。企业现有软件系统的研究应包括现有系统操作手册、系统需求文档、系统设计文档、系统开发文档、数据结构、数据备份、维护日志等。其中特别要关注系统的现存问题以及系统的变更需求。

3.2 需求建模

前面一个环节（即需求收集归纳）所获取的文档化的软件需求存在一定的局限性：可能产生不准确、二义、歧义、不能直观揭示关联、不全面等。

模型是对现实原型的一种抽象和模拟，以反映现实事物的某些特征。需求建模是指用模型描述系统的因果关系或相互关联关系的过程，为业务概念、对象之间建立模型。它是需求分析成果的进一步定型，为后续的系统开发做相应的技术准备。需求建模技术是软件需求分析与系统初步设计的主要技术手段，能够有效分析发现并纠正不一致、不准确和不全面的需求，对系统需求的不同方面形成形式化的准确描述。

3.2.1 环境图

环境图是一种有效的界定系统范围的方法，它描述了系统与外部系统的集成关系。

系统范围可以通过识别外部实体以及外部实体和系统之间的输入、输出数据流（或服务）来确定。系统获得输入信息，进行处理，产生输出信息。例如，智能监控系统的环境图（见图2）。图2 中圆角矩形表示智能监控系统，它周围的长方形表示外部实体，箭头描绘了数据交互的内容和方向，同时也明确了系统的边界。在上例中，智能监控从资源管理获得资源信息、资源关系、资源拓扑等，一旦发现设备故障，就向电子运维发出故障派单的请求，电子运维处理故障工单在各管理层级的流转、处理，并向电子运维反馈同步工单状态、割接信息、重保信息等。

从图2 可以看出，智能监控系统提供统一的网络监控和告警处理功能，与资源管理、电子运维分别存在交互接口。

3.2.2 活动图

活动图描述一个业务流程中活动的顺序，主要表示活动之间的控制关系（如判断分支、连接、合并等）。一般情况下，在活动和活动图之间具有一对一的关系，即一个活动图表示一项活动。

图3 示出的是以客服支撑系统中的“省内漫游用户无法主被叫”预处理流程。

图3 活动图

该流程包含如下动作、节点。

a）确认用户手机号、身份证号，询问用户姓名是否正确。如果“正确”，进入下一个节点，如果“不正确”返回重新查询。

b）判断用户是否为预付费用户。如果“是”，则转入预付费子流程，如果“否”则进入下一个节点。

c）判断用户是否为集团VPN用户。如果“是”，则转入集团VPN 处理流程，如果“否”则进入下一个节点。

d）判断用户是否欠费。如果“是”，则引导用户缴费，如果“否”则进入下一个节点。

e）询问用户是否有信号。如果“无”，则转入无信号处理流程，如果“有”，则进入下一个节点。

f）建议用户换手机、换SIM卡进行测试。

g）询问用户拨打是否正常，如果“否”，则派发故障工单，如果“是”则流程结束。

3.2.3 类图

类图表示系统的静态视图，用来表示数据模型、数据关系。类图可以定义那些捕获系统内部状态的结构。类的结构由其属性来定义，当类被加到模型中之后，要给类分配主要属性。而不同类之间的关系则需要在类图中用关联线来表示。

系统中的类包括实体类、表现类、控制类、资源类、调解类等5类，需求分析主要关注实体类，它是指与业务流程、业务处理，紧密相关的类。

发现并定义类及其属性的过程是一项反复迭代的工作，需要深入理解需求，并归纳、抽象。以客服支撑系统为例，产品、产品类型、故障原因、产品动作的相关类图如图4所示。

图4中，包含4个类。

a）产品类型：产品类型ID 为主键，包含产品类型名称一个属性。产品类型包括固话、宽带、IPTV等。

b）障碍原因：障碍原因ID 为主键，包含障碍原因名称、父障碍原因列ID、产品类型、显示顺序4 个属性。与产品类型关联，一个产品类型包含多个障碍原因。如产品类型为宽带，障碍原因包含无法连接、连接成功但网页无法打开等。

c）产品动作：产品动作ID 为主键，包含产品动作名称、父产品动作ID、产品类型、显示顺序4 个属性。与产品类型关联，一个产品类型包含多个产品动作。如产品类型为宽带，产品动作包含装机、拆机、移机、修机。

d）产品：产品ID 为主键，包含产品编码、产品名称、产品类型、显示顺序4 个属性。与产品类型关联，一个产品类型包含多个产品。如产品类型为宽带，产品包括xDSL专线、LAN专线等。

3.2.4 交互视图

图4 类图示意图

交互视图捕获对象之间的交互，为了执行一个用例或用例的一部分，这些对象之间需要通信。与活动图相比，交互图更详细。活动图描述整个活动的各个环节，交互视图则对活动图中的单个活动建模。以客服支撑系统为例，查询用户欠费信息的交互视图如图5所示。图5中包含2个参与者（用户、客服人员），3个类（系统界面、用户验证、用户）。

图5 交互视图示意图

图5中，一个箭头表示一条消息，消息可以只有名字也可以包括消息的参数及其他信息。

a）用户拨通客服电话，向客服人员描述产品类型及障碍现象（3G手机无法主叫）。

b）根据用户描述的产品类型、现象，客服人员在系统界面上选择产品类型及障碍现象，并获取用户号码，传递给用户验证类。

c）用户验证类是一个控制对象，负责程序的逻辑。由于当前系统界面发起的验证用户请求与特定的用户对象有关，用户验证类将这个请求发送给用户类。

d）用户类将查询结果（余额不足）返回给用户验证类，系统界面接收返回结果并显示在屏幕上。

e）客服人员根据系统界面显示结果，告知用户无法主叫的故障是由余额不足引起的，并引导用户缴费。

3.2.5 状态机视图

状态机视图描述对象生命周期中的属性变化情况，属性变化的原因可能是满足某些条件、执行某些活动等。

状态机视图一般会附到类图上，也可以附到其他建模概念上。状态机视图决定当对象接收到一个事件时，它执行什么动作。以客服支撑系统为例，工单实体“工单状态”属性的状态机图如图6所示。图6中，工单状态有6个，它们之间的转换过程如下。

图6 状态机视图

a）预处理流程未解决用户的问题，系统生成工单后，状态机模型开始启动，首先判断用户描述的故障是否是由群障引起的，如果“是”，则转换为群障状态，如果“否”，则转换为综合调度状态。

b）工单以人工或自动的方式派发给指定施工人员后，状态转换为“处理”。施工正常竣工后状态转换为“回访”。施工过程中出现异常，则状态转换为“异常”。

c）异常解决后，需要重新派单施工，状态由“异常”转换为“综合调度”。

d）“回访”状态的工单在电话回访或人工回访、且回访通过后，进入“归档”状态，最终到达终态。

e）“群障”状态的工单，经过群障解除的动作后，进入“归档”状态，最终到达终态。

3.3 需求评审

需求评审是指将整理好的需求规格进行评审，最终决定开发工作如何执行。

需求的评审一般由专业人士来完成，主要包括：a）系统建设职能方：部门开发经理、维护经理、项目经理及资深开发人员。

b）需求管理职能方：需求分析设计人员。

c）用户代表：典型客户代表、实施人员代表。

d）公司的内部专家及外部专家：公司内部一般包括高层管理人员、中层管理人员；外部专家包括技术专家等。

评审的目的主要就软件需求规格中定义的各事项做进一步讨论，根据评审过程中各专家提出的问题再作整理、修改，最终确定需求的状态。并确认开发所需的工作量、时间、成本，及开发实施初步计划。

3.4 需求实现及跟踪

3.4.1 功能性测试

功能性测试用于验证开发成果是否满足目标用户的业务需求，目的是尽可能早的发现，并纠正实际开发与预期需求的偏差。

功能性测试也叫黑盒测试，只需考虑需要测试的各个功能，不需要考虑整个软件的内部结构及代码，一般从软件产品的界面或模块出发，包括以下步骤。

a）按照需求编写出测试用例，规定每个功能的输入、操作方法、输出，如有必要可提前准备部分表单数据。

b）测试人员按照测试用例中的输入、操作方法，在系统上进行测试操作。

c）在预期输出结果和实际结果之间进行评测、改进，使产品更加满足用户使用的要求。

验证全部完成后，下发相关业务上线文件及管理要求文件，并视情况组织培训。

3.4.2 需求评估

评估需求开发成本、需求实现的满意程度等。定期对上线使用的需求使用率进行统计，通过客观、科学的量化指标，评估IT需求管理的最终效果。

根据需求后评估的管理目标，可以将需求后评估分为以下5个维度。

a）目标评估。关注需求达成的情况，例如业务偏差、需求的完成及时率等。

b）质量过程评估。关注需求开发、交付的质量，例如交付质量、开发交付及时率等。

c）影响评估。关注对最终客户感知的影响情况，例如对业务的中断影响、需求引起的投诉情况。

d）效益评估。关注需求的成本与收益情况，例如需求开发工作量、业务用户数等。针对占用资源较大的系统功能，跟踪使用频次、使用效果等。清理使用频次低、重要性低的需求，将资源向高价值需求倾斜。

e）持续性评估。关注需求的可持续发展情况，例如系统重用率、系统的可配置性等。

4 需求管理的电子化支撑方案

对于集团型企业来说，信息系统需求管理存在范围广、复杂度高的特点。采用邮件和人力维护的传统需求管理方式难以对需求进行有效的管理。因此有必要引入专业化的需求管理电子化支撑手段，即需求管理系统。

4.1 需求管理系统目标定位

a）面向业务部门的对外窗口。所有IT 需求统一由需求管理系统接入、管理，提高IT服务水平，实现需求全生命周期管理与实时监控预警。

b）需求管理工作人员的工作平台。需求管理职能、系统建设职能、用户代表的需求工作均在系统内操作，固化IT 需求管理流程，确保全流程电子化、可追溯、可计量。

4.2 需求管理系统整体功能架构

通过对IT需求管理重点环节梳理总结，结合项目管理、质量管理、知识管理、运维管理的要求，IT 需求管理系统功能包括以下几点。

a）需求收集。支持使用专业需求模板在线拟写需求，提供需求模板说明帮助规范填写。

b）需求归纳整理。支持自动编号、逐级分解、标记优先级、关联关系维护等。

c）需求跟踪。动态更新IT需求的进度和状态，流程关键环节透明可见，并记录过程中的关键成果文档，与需求建立关联。

d）功能性测试。记录测试方案、测试过程、测试结果、测试中的问题与后续跟踪；记录与跟踪系统上线、初验等关键环节。

e）需求评估。采集评估指标所需数据，支持评估结果的记录与分析。

f）需求管理关键指标实时获取，支持报表图形化展示，为决策、考核提供量化依据。

g）需求知识库。将以往需求中形成的经验、收集的资料形成知识库，方便学习共享。

5 总结与展望

随着企业信息系统建设的不断推进，需求管理将作为贯穿项目始终的重要内容，通过需求收集归纳、需求建模、需求评审、需求实现及跟踪等流程环节，大大提高信息系统建设的效率与满意度，有利于降低企业的管理成本，更好地发挥信息系统在企业运营中的核心支撑作用。

［1］ 麦沙塞克. 需求分析与系统设计［M］. 北京：机械工业出版社,2003.

［2］ 孔军，孙怡宁，蒋敏，等.基于UML的系统需求分析［J］.计算机工程域应用，2003（15）：58-61.

［3］ 吕冠艳，李奋华.基于UML的信息系统需求分析模型［J］.微型机与应用，2010（20）：10-13.

［4］ 姜天慧.某成人高校招生信息系统分析与设计［D］.北京：北京邮电大学，2011：32-49.

［5］ 王枫，石冰心，罗莉敏.UML 建模机制研究及在系统需求分析中的应用［J］.计算机工程与设计，2005（4）：27-29.

［6］ 孙铁昆，杨新轩.管理信息系统需求管理工具的研究与实现［J］.计算机工程与设计，2006（12）：53-57.

［7］ 郝建青，张仲义.信息系统需求分析方法研究［J］.管理工程学报，2001（2）：13-16.

［8］ 王小明，冯德民.信息系统需求分析的面向对象层次分析方法及应用［J］.计算机工程与应用，2001（3）：67-71.

［9］ 贾晓辉，韩恺，乐嘉锦.基于UML 的系统需求分析［J］.计算机应用与软件，2007（8）：45-49.

［10］刘峰，王颍，伊文敏. UML 在信息管理系统需求分析中的应用［J］.河北建筑工程学院学报，2006（2）：46-50.

［11］徐建民，刘进坡，邵艳华.一种基于UML 的信息系统需求分析方法［J］.河北大学学报(自然科学版)，2005（2）：46-50.

［12］张太武，刘珊艳.UML在系统需求分析中的应用［J］.长江大学学报（自然科学版），2006（1）：23-25.

［13］杨志磊，秦晓，杨新轩.基于自定义状态机制的需求管理工具的研究与实现［J］.计算机工程与设计，2005（4）：84-88.

［14］谢越伟.军用软件需求工程中部队用户的地位与作用研究［J］.军事运筹与系统工程，2004（1）：3-7.

［15］马丽，李平.信息管理系统开发中的需求管理过程实践［J］.微计算机信息，2006（4）：13-17.