基于敏捷开发的管理信息系统需求分析模型构建

张保丰 徐绪堪 林洁 张骥

[摘要]国内开发管理信息系统（MIS）的成功率并不高，经过调查分析，大多是由于需求的变化性和不确定性所致。需求分析在系统的开发过程中有着举足轻重的作用，因此有必要对需求分析进行深入的研究。为了应对快速变化的系统需求，本文采用敏捷项目管理的思想，利用增量式的迭代方法逐步明确系统需求，并用数值量化每一个需求的不确定性、不一致性和优先级，在三维模型中表示每项需求，方便需求分解、细化和明确，从而使需求更加全面、清晰，有利于开发人员更好地对信息系统需求变更趋势、需求变更主要原因进行掌控，有效地提高系统开发的成功率。

[关键词] 需求分析；Scrum；业务流程；三维模型；需求变更

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2012 . 23. 028

[中图分类号]TP391[文献标识码]A[文章编号]1673 - 0194（2012）23- 0045- 03

1前言

1.1 传统管理信息系统开发方法及缺陷

管理信息系统（MIS）因其在创造有竞争力的公司、管理全球化、增加企业价值和为客户提供有价值的产品与服务等方面有着重要的作用[1]，受到越来越多组织的青睐。信息技术发展的日新月异使得软件的功能越来越强大，同时也带来一系列的开发管理上的难题。传统的瀑布模型、螺旋模型、原型模型等方法也越来越不能适应快速变化的需求和市场环境。主要表现在：软件开发效率低，大量的人力、物力、财力浪费在重复开发上；软件质量得不到保证，后期服务费用大；技术积累困难，常常随着技术人员的流失而消失；企业内部、企业与外部缺乏有效、可靠、安全的信息交流方式等。

1.2 需求分析的重要性及不确定性

开发有效的信息系统的关键在于做好信息系统的需求分析工作，因为好的需求分析可以为信息系统的编写提供任务范围的框架，对信息系统的开发进行有效的控制，为信息系统的完成提供基线，为信息系统最终交付提供依据[2]。从项目管理知识体系来讲，也就是要根据管理科学的理论，对需求进行科学分析和有效的规划、管理及控制，使开发项目能够按照预定的成本和进度顺利完成，并保证信息系统的质量和最终的顺利实施。TTE、TRM和IBM三家公司的统计结果表明：发现错误的时间越晚，修改所需要花费的费用越大，如图1所示。另外，需求定义不准确会对系统开发人员的积极性以及用户实施信息系统的信心带来不可忽视的影响。

由此可以看出，需求阶段在系统开发的整个生命周期中处于最基础、最重要的位置。许多成本分析表明，系统60% ～ 80%的错误发生来源于需求的错误定义[3]，这又归结于需求分析具有很强的不确定性，表现为用户本身需求的不确定性：用户自我认识不清、员工因为利益原因故意隐藏需求、市场环境变化、业务调整等。然而更主要的原因是传统开发方法的局限性，使得需求不够明确，不能及时控制需求变更。而Scrum作为一种敏捷开发的代表，相对于传统方法具有很明显的优势。

2Scrum指导下的需求分析

2.1 敏捷开发Scrum

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在高度协作的开发环境中，使用迭代的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停地进行自我调整和完善。采用敏捷开发不仅保证了软件的质量，而且开发速度也提高了3～10倍。Scrum作为一种典型的迭代式增量软件开发过程，旨在寻求充分的发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，尽快让需求者看到结果[4]。越来越多的公司，例如Google、Microsoft、IBM、Oracle等，开始采用Scrum来解决软件开发过程中面临的困难和挑战。如果将项目开发过程视为一个黑箱，那么Scrum能更好地加强黑箱内部的混沌性，使项目组工作在混沌的边缘。不过，Scrum并没有提供核心的价值观和指导原则，也缺乏具体的实践方法。本文借助Scrum的思想，通过具体的方法来实现复杂系统的需求分析。

2.2 需求层次

信息系统需求具有一定的层次和分类，一般包括业务需求、用户需求、功能需求（包括非功能需求）3个层次。为了便于本文的研究和体现迭代思想的优越性，按照需求发现的难易程度，从纵向上将需求分为以下3个层次。①基础性需求：实现用户需求，用户主动提出的、显性的、基础的、迫切需要实现、必须满足的需求。②满意性需求：符合用户预期，此类需求相对独立，并且不对主要业务实现造成很大影响。③兴奋性需求：超出用户预期，深度隐性需求，主要为系统与用户未来需求的吻合度。

2.3 需求分析建模

在关于不确定性、不一致性和优先系数的分析中，开发团队要根据具体情况对每一项工作制定一份比较完整的评分细则，防止评分过程中的随意性。开发团队需要根据需求不确定性、不一致性以及优先级系数为坐标建立如图2所示的三维模型。将调查得到的每个需求的属性按（不确定性，不一致性，优先系数），例如需求A5（30，10，1）进行绘图定位。我们将整体分为8个象限，根据图形情况，开发团队和用户可以一目了然的发现某一项需求的具体情况。

Ⅰ和Ⅴ区域是基本需求的集结区，是确定开发和优先开发区域，此处的需求得到用户和开发团队的一致同意，在此区域的需求的成功能够给员工工作带来很多的方便，完成基本作业流程，增强用户企业的市场优势。

Ⅶ区域是兴奋性需求的集结区，也是高风险发开和争议开发区域，因此在处理这一部分需求时要格外注意。高风险可能带来高收益。风险主要为需求本身的变化性致使开发成功的可能性减低，或者即使成功开发也不一定能发挥作用。它的价值更多的表现为满足用户的隐性需求和应对未来的不确定性。在开发过程中，开发团队应以战略的高度把更多的注意力放在位于Ⅶ区域的需求上，通过进一步的调查将其转化到其他区域，可以及时发现需求变化及其变化原因。

开发团队要综合考虑单个需求中三者的权重以及需求间的逻辑依赖关系来决定需求开发的先后顺序。权重的确定不是任意的，必须通过科学的方法和有效的经验确定。我们采用主成分分析法，数据来源应为已经公认的开发案例数据、开发团队以往开发中的有效的成功的案例以及客户所在公司的实际情况。

2.4 需求分析的基本流程及方法

借助Scrum的核心思想，结合需求分析自身的特殊性，我们采取如图3所示的流程。

从一般流程我们可以看出，它是一个迭代的、逐步完善的过程，而协调关系和协同设计[5]则贯穿始终。为此，我们采取如下策略：①总体规划，分步实施：由粗到细，有宏观到微观，由外到内，逐步精深；②以部门为单位，以业务领域为主线，借助泳道图搞清楚每个部门负责的业务以及每项业务流经的部门。

（1）环境识别：就是把企业作为一个社会和经济系统的子系统，即要认识企业所处的自然环境，又要认识企业所处的政治环境、人文环境，由外到内，由表及里地把握企业所处的地位[6]。将企业与上下游的供应商、客户，以及合作伙伴和竞争者纳入考虑范围。企业可以利用外部竞争威胁模型和价值链模型等来进行战略分析和选择，识别信息系统能够提供竞争优势的经营领域，然后确定信息系统的战略[7]。系统战略必须服从服务企业战略，系统功能必须支撑企业战术要求。

（2）成立开发团队。开发团队领导须由资深的项目经理担任，由技术人员、业务分析员、管理人员组成，形成知识、技术、经验、沟通能力的互补。开发团队领导没有真正的实权，只是负责主持会议、协调成员、营造更好的交流环境，开发团队成员都应该是全职的。开发团队首先要对客户的过去和现在进行了解，包括企业传统、企业哲学、核心价值、员工价值、主营业务等，方便调查工作的顺利和深入开展。

（3）理解愿景，识别目标。理解愿景，既要理解上级的意图，又要理解下属的愿景，上下沟通，层层协调。识别目标，既要从横向上把握整体、要素、环境的有机联系，在大环境下规划企业的目标、方针、宗旨，又要正确处理企业的过去、现在、未来的连贯性，合理制定企业的长短期目标。

以下进入一个迭代式的增量过程，首先从每个部门入手，实现各个击破，形成部门级需求，然后再通过接口进行需求整合，最终形成完整的公司级的需求文档和需求模型。

（4）模块分解和调查。首先根据公司现有组织结构和业务流程将公司划分为界限并不明显的职能/参谋部门，然后要对每个部门进行需求分析的时间做个排序，保持两个相邻部门之间具有一定的黏性，然后依次对每个部门分别进行需求分析。开发团队首先可以对部门内部进行问卷或者调查表调查，包括员工职务、职责以及对部门的整体描述，初步了解基本信息，这样可以在下一步的面谈中做到有针对性，节约时间。

（5）每日会议，需求发现。每个部门的需求分析将控制在一周内，开发团队会每天定时定点召集部门员工进行面谈，时间控制在一个小时内。为此我们建立一个“论战室”，提供公共的会议室，以保持客户和开发团队能够在协同工作下进行需求分析。客户将至少要回答下列问题：①你对昨天的需求陈述还有什么要补充的吗？②你今天有什么新的需求？③你明天将要做什么？有什么难度？④你认为现在迫切需要解决的问题是？⑤你认为你工作中的机会问题（probortunity）是什么？这一过程中要吸收头脑风暴[8]的优点，根据触发器放大原理，更大程度地发现每个客户个性化的理念理解和情景化的概念理解，实现各种需求最大化的外现。

（6）需求定义、编号及评审。开发团队根据以上活动记录总结、抽象出具体的需求文档并形成组件，同时要给每个需求进行唯一性编码。然后需要对此进行评审，评审会由开发团队、部门主管、员工代表组成，各人员可以对需求文档畅所欲言，发表自己的意见，并给需求评定优先级别。评审主要是针对需求的合理性、粒度、完整性、价值性（商业性）等方面给与一定的评价。在此过程中我们借助用例划分的测试方法“WAVE”，即What to do， Actors point of view， Value for the actor， Entire scenario，来检验每个需求的质量[9]。在需求评审最后评审会形成最终意见，开发团队对需求文档和组件进行修改。

（7）需求文档/组件集成：通过对各个部门的需求分析完毕后，通过需求间的接口进行集成。在集成中要注意是否有超出范围的需求以及各种需求间的依赖关系。我们借助需求交互矩阵[10]来判断任意两个需求之间的依赖关系，并判断是否独立、相似、重叠或者矛盾。相似的需求要进一步细化明确，转化为独立需求和重叠需求；矛盾的需求需要与需求部门和更高的领导进行讨论交流协商，在两者兼顾下达到整体化更优；重叠的需求应当消除，减少不必要的资源浪费。

在前几轮的迭代后开发团队会发现基础性需求并设计模型和编制文档，模型能够给用户更加清晰的认识，加速需求的确定，同时也可以被重复利用。随着每轮迭代工作的进行，用户的隐性需求和潜在需求会不断明朗，此时要对需求进行修改、扩充，逐渐发现满意性需求和兴奋性需求。最后将各层次的需求文档和模型进行整合，实现需求分析的成功。

3模型质量保障措施

3.1 用户保障

在每次的面谈和评审会中要尽量保证客户自由地、无拘束地畅谈；要让用户认识到自己不仅仅是活动的参与人，也是变革推动者，确保每个需求优先系数（Priority）评分、每个需求不确定性（Uncertainty）评分以及需求不一致性（Disagreement）统计真实可靠。

3.2 开发团队保障

开发团队在整个过程中应该做到以下几个方面：每个部门作为一次增量，在划分部门时并不具有随意性，而是既要保证部门的独立性，又要保持部门之间的黏性，主要依据是业务流程；为了体现部门划分的连贯性和优越性，就要使得调研过程具有连续性和继承性；开发团队自治，在引入基于自我组织团队的变化驱动模式的过程中，要做到从高度个体自治、不注重团队自治向高度个体自治并且注重团队自治的转变[11-12]；开发团队中的每个人都没有专门的职责。开发团队是一个自组织、自管理的团队，项目的每个成员都具有项目中所有方面的参与权，不存在单一成员划分部门、问卷调查、构建需求模型的情况[3]，这样保证了不会因为开发团队成员的减少而影响需求分析的进度。

4结语

需求及需求变更对信息系统开发过程影响较大， 是影响信息系统质量的重要因素[14]。本文在敏捷开发思想的指导下，重在从实践的角度，以部门模块为单位，以业务流程为主线，数字量化已发现的需求后建立三维需求模型，有效的说明各种需求的关系以及其优先情况，有利于开发人员更好对信息系统需求变更趋势、需求变更主要原因进行掌控，方便后期开发工作的进行，有效的提高系统开发的成功率。

主要参考文献

[1][美] Kenneth C Laudon， Jane P Laudon.管理信息系统：管理数字化[M].第8版.周宣光，译.北京：清华大学出版社，2005.

[2]董红赞.中小企业信息管理系统需求分析流程研究[D].上海：上海交通大学，2009.

[3]罗晓沛，姜同强，等. 全国计算机等级考试三级教程——信息管理技术[M]. 北京：高等教育出版社，2011.

[4]张智海，周国祥.Scrum方法的研究与分析[J].合肥工业大学学报：自然科学版，2010，33（2）：198-200.

[5]陈丽. 基于共同价值的多维度组织协同机理和方法[D]. 天津：天津大学，2010.

[6]彭本红，吕永成，黎军.运用WSR方法探讨国有企业BPR的有效实施[C]//顾基发.西部开发与系统工程——中国系统工程学会第12届年会论文集，2002.

[7]杜栋.新编管理信息系统[M].北京：中国人民大学出版社，2005.

[8] 潘绵臻，毛基业.ERP实施中用户的有效参与——头脑风暴会议的作用[J].管理学报，2010，7（7）：1052-1063.

[9]Eric J Naibug，Robert A Maksimchuk.UML for Database Design[M]. Boston，MA：Addison-Wesley，2001.

[10]G Kotonya，I Sommerville.Requirements Engineering：Processes and Techniques[M].New York，NY：John Wiley& Sons，1998.

[11]Meo NB， Dingsoyr T.Understanding Self-Organizing Teaming Agile Software Development[C]//19th Australian Conference on Software Engineering，2008：76-85.

[12]杨帆，徐俊刚.一种改进的Scrum敏捷软件开发方法[J].电子技术，2011（9）：22-23.

[13]Robert C Martin.敏捷软件开发——原则、模式与实践[M].邓辉，译.北京：清华大学出版社，2003：7.

[14]张献国，刘铁英，徐智文.信息系统需求变更统计分析度量方法[J].内蒙古大学学报：自然科学版，2006（1）：89-94.