信息管理软件需求分析阶段的实践经验及论述（2010 年）

摘要：需求分析是信息管理软件开发中最重要的阶段。本文从需求分析的定义入手，结合实例介绍了需求的三个层次，并论述了需求分析在软件开发中的重要地位。文中结合实践经验，提出了有效获得用户需求的一些方法及应该注意的事项。然后，详细阐述了更好的分析用户需求的一些观点，并提出了引导用户，创造需求等思考分析方法。最后，结合项目的因素及信息管理软件项目管理的特点，分析了需求分析与项目管理之间的关系及权衡。



关键词：需求分析；项目管理；需求分析员



一、软件需求分析概述



（一）软件需求分析的定义



IEEE[1] 软件工程标准中将需求分析（Requirement Analysis）定义为：（1）用户为了解决问题或达到某些目标所需的条件或权能 (Capability) 。（2）系统或部件为了满足合同、标准、规范或其它正式规定文档所规定的要求而需要具备的条件或权能。（3）反映上面 (1) 或 (2) 所描述的条件或权能的文档化表述。



需求分析是解决“做什么”的问题，是定义“做”的范围和尺度，是将用户要求我们做什么，变成我们书面承诺为用户做什么的过程。需求分析结果应确保所有的风险承担者都明白其含义，并形成文档，从而作为下一步工作的基础。概括来说，需求分析包括三个要素需求、分析和文档。需求分析员是指负责收集分析客户需求并编写文档，以及负责客户与开发者之间沟通的人。



（二）软件需求的三个层次



软件需求一般分为三个层次：



1、业务需求：反映了组织或客户（Customer）对系统、产品高层次的目标要求。业务需求通常来自项目投资者、实际用户的管理者或产品策划部门。它们在项目视图与范围文档中予以说明，这些文档通常作为合同的附件。



2、用户需求：描述了用户（User）使用产品必须要完成的任务。它们一般使用用例文档或者方案提纲（Scenario）予以说明，这些文档通常作为需求调研报告。



3、功能需求：定义了设计开发人员必须实现的软件功能，使得用户能够通过软件来完成他们的任务，从而也满足了业务需求，用户需求和功能需求。其中也包括非功能性需求，如产品必须遵从的标准、规范、性能要求等。它们一般在软件需求规格说明书（Software Requirements Specification SRS）中说明。



在这里用一个关于超市会员多倍积分的例子来说明需求分析的三个层次：



业务需求：为了提高会员的忠诚度，使会员在其生日及重大节日当天消费可以得到多倍的会员积分。



用户需求：为实现业务需求，需要首先制定会员多倍积分规则，然后将该规则宣传给广大会员；通过在系统中设置会员的多倍积分方案，在会员刷卡消费的时候，系统根据会员资料信息自动执行多倍积分方案；用户要求在POS[2] 断网的时候也能执行。



功能需求：根据用户需求，系统中应该实现的功能是：一个设置会员多倍积分规则的界面；利用通讯机制将会员积分方案同步到前台POS；前台POS在会员缴款时自动计算积分；将积分计算结果同步到后台数据库中。相关的非功能需求：用户应该可以自定义通讯的间隔时间（范围：1分到24小时）；每1000笔销售数据的通讯时间不应该超过2分钟；界面易用性等。



（三）需求分析在信息管理软件开发中的重要地位



需求分析是软件工程中最重要的阶段。软件项目的生命周期一般分为计划阶段（项目立项、计划）、开发阶段（需求分析、概要设计、详细设计、编码、测试）、维护阶段（实施投产、维护）。需求分析作为项目开发阶段的开端，具有非常重要的作用，可以说它是软件工程的真正开始。需求分析是所有软件成功要素发挥作用的前提，它的好坏直接影响着后面的各个阶段，关系着软件的成败。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段留下的隐患[3] 。在软件工程的历史中，很长时间里人们都认为需求分析是整个软件工程中最简单的一个步骤，但在实践中人们才越来越认识到它是整个软件生命周期中最关键的一个过程。优秀的信息管理软件产品必须建立在优秀的需求基础之上。



需求分析阶段又是在软件工程中所有的风险承担者都关注的阶段。这些风险承担者包括客户、用户、商务及业务人员、需求分析员、设计人员、编码人员、测试人员、用户文档编写者、项目经理等。这部分工作如果处理不好，可能导致需求误解、开发挫折、项目延期、甚至纠纷和失败；若处理好了，能开发出很出色的项目，帮助客户实现价值，项目团队成员也有成就感。



二、如何有效地获得用户需求



（一）有效进行需求调研的方法



1、明确整体思路



软件项目一般会包含客户的很多种需求，涉及客户的多方面业务和多个部门，因此需求调研一定要有一个明确的思路，从大处着眼，然后逐渐细化，直到详细的需求细节。比如，首先是客户的整体要求和目标，然后是各个部门的各种业务项目及主要的业务流程，再到业务过程的每一个单据，每一条记录，以及表现形式等等。需求纷繁芜杂，在需求调用的过程中要经常查看项目规格说明书，明确项目最初提出的目标和范围，主要是为用户解决什么样的问题，这样才能从众多的需求中分清主次，提取用户核心的、主要的业务。



2、进行充分准备



无论是面对面的需求会议，还是电话沟通，都应该注意在交流之前尽量取得更多的信息以准备。每次需求会议前先根据当前掌握的信息和需求列出问题提纲，这样在调研的时候才能问到点上，既提高效率，又增加用户对我们专业素养的信任。不仅我们要充分准备，也可以先让用户提供一份用户自己写的书面需求，事先做一个较明晰的阐述。另外，还要提醒用户必要的材料和数据准备，这些准备将有助于会议的进行，以免用户在会议开始后再找材料查资料，中断会议的进行，影响调研的效果。



3、区分调研对象



对不同的调研对象，询问和讨论的主题和内容应注意区分：一般对于用户的高层领导，不要讨论细节问题，要讨论高层的业务需求，讨论目标、方向等问题，另外要把握好时间，不宜过长；对于用户的业务层领导，要多询问一些业务流程方面的问题，他们在这方面最熟悉并有见解，一般来说，软件的大部分需求都是这个层次的人员提出的，和这个层次的人员要注意关系上的协调；对于具体操作人员，可以多询问一些对方的操作习惯、业务处理的细节等问题；对于系统管理员，则可以讨论一些技术上的问题，比如，通过其了解客户公司的软硬件及网络环境，用户的操作水平等。



4、详细明确的记录



记录包括会议记录和需求记录。每次沟通都应有详细的书面记录。这是形成需求分析结果的基础和下次需求调研的前提。如果不这样做，结束调研的时候只有一个模糊的印象，需求分析的结果仍然遥不可及，应力争每次需求会议都使需求分析向前推进一个阶段。讨论结束前将记录的文档向客户确认一下，让客户进行评论和更正，以保证没有错误和歧义。记录使用的语言须是用户熟悉的词汇，要使用明确肯定性语句，不要使用模糊的说法。比如，不能描述为一天产生的POS业务流水很多，应该明确到10的3次方的数量级，不能仅记录为要求日结账要快，应该明确到在200秒内完成等。



5、多思考多提问



软件需求是分层次的，用户对我们描述的往往只是用户需求层次的表面问题，只了解这些是不够的，还要理解用户为什么要提出这样的需求，做到知其然又知其所以然。作为需求分析员，必须要深入地理解客户的业务逻辑和需求目的。在大多数的软件系统中，最终用户可能都不清楚他的需求是什么。如果只知道用户提出的要求，而不知道其为什么有这个要求，那么很可能会误入歧途，获取不了用户的真正需求。比如针对上述会员多倍积分需求，用户要求在POS断网的时候也能实时执行。事实上如果不采用无线通讯这根本不可能，采用无线成本又太高。询问原因后，才知道实际上用户是担心数据丢失，我们只要保证数据不丢失，在网络连接正常后再执行就可以了。



（二）容易忽视的事项



1、确定权利与义务



只有当双方参与者都明白促成当前信息管理系统建设的成功，自己需要做什么，合作方需要做什么时，才能建立起一种好的合作关系。为了需求调研的有效进行，可以在开始之前向客户明确其需求权利和应尽义务。可以通过需求权利书规定客户在项目需求调研过程中的合理要求，这些权利同时对应着分析人员和开发人员的义务；而通过需求义务书规定客户在需求过程中应承担的义务，当然这些也可以认为是分析人员和开发人员的权利。



2、搜集用户资料



很多时候用户对自己需求的语言描述带有随意性和模糊性，又加上思维角度的不同，往往会造成我们理解上的偏差，而企业中的文档资料则真实地反应了用户的业务。它们包括，打印出来的各种单据、报表，企业的业务管理规则、制度，内外部考核办法等。这些资料将有助于直观、具体、高效的获取需求。比如，可以询问用户是否已经制定出多倍积分的书面草案，有没有相关的会员积分政策文档作为参考等。



3、到工作现场考察



对于难于理解的用户业务或性能方面的需求，一定要进行操作现场的实地考察，观察正在工作的用户，亲身感受实际业务流程、了解操作情况。现场考察是理解用户需求的最好的方式。主观推断往往和实际的业务操作有很大的出入。比如，有些开发人员不重视快捷键的设置，如果观察超市POS终端操作员的工作，将会明白这非常重要。再如，离岸BPO[4]用来提交业务数据的软件系统对网路传输的速度、操作响应的速度等有非常高的要求，否则操作员难以忍受，并且大大影响工作效率。如果只实现了功能，而不能达到性能要求则远远没有满足客户的需求。



4、非功能性需求



非功能性需求包括，客户现有的服务器资源、网络资源及环境、硬件条件、操作系统、操作人员水平、由用户的工作特点决定的对性能的特殊要求等。如果不事先了解这些情况，或事先告知客户进行必要的资源环境准备，可能会导致最终软件无法部署，操作人员无法使用等情况。比如，用户服务器用的是免费的Linux操作系统，而我们开发的软件只能在收费的Windows操作系统上运行，将直接宣告项目的阶段性失败。



5、旧版本，相关软件系统和接口



如果项目是对原有的软件重新开发或升级，那么一定要仔细研究旧的软件系统的功能，并询问客户旧系统不能满足当前需求的原因，以期在新的系统中得以改善和提高，同时旧系统中优秀的功能特点要予以保留。如果用户当前已经使用了其他系统，一定要了解这些系统，看有没有重复开发，或功能不足的补充。还应注意相关系统中的数据编码规范、操作规范，用户操作界面，以便于用户对新系统的适应、培训和维护。如果用户要求软件和现有的系统进行数据交互或经过调研发现需要数据交互，那么一定要弄清数据接口的规范、接口双方的通信方式、数据存储方式、采用的数据库系统、数据结构等。比如，增加会员多倍积分模块，就要考虑数据接口，通信方式，界面一致性，尤其是POS端快捷键不能冲突等多个方面。



三、如何更好地分析用户需求



需求分析的工作是需求加分析的工作，需求是沟通，分析是思考，两者相结合决定了这是一种方法性很强的工作。需求分析员应充分发挥主观能动性，适当运用一些思维方法和策略，这样才能使需求分析做的更完善，把握更到位，项目更成功，双方更满意。



（一） 关于“做什么”和“怎么做”



通常从软件开发不同阶段任务的角度说，需求分析是解决“做什么”的问题，系统设计是解决“怎么做”的问题。但对于“做什么”和“怎么做”应该正确理解。



一方面，在做需求分析的时候不要有“怎么做”的思维。尤其在需求的早期阶段，如果用户每提出一个需求，总是思考这个需求能不能实现怎么实现，那么需求分析将进行的非常艰难和缓慢，而且在这种“怎么做”的思维的影响下做出的需求是带有主观色彩的，是有偏离的，很可能回避了用户真正想要实现的功能或性能，从而做出的需求分析也不能真正解决“做什么”的问题，不能真正为用户解决问题。刚刚从编码人员成长为系统分析员的人容易产生这种思维。



另一方面，虽然是解决“做什么”，仍然要对“怎么做”心中有数。只有对可行性心中有数，才能避免在设计和编码中出现不能实现的需求。软件工程是技术含量很高的工作，任何人都不可能解决所有的问题，尤其面对跨平台，多系统，复杂的网络环境的时候。因此，系统分析人员应该在技术上有很好的储备和经验，能够敏感的判断出客户提出的需求的可行性。



另外，应正确理解需求阶段“做什么”的概念。“做什么”并不是不考虑怎么处理的问题，业务流程上的“怎么做”正是需求分析阶段应该解决的重要问题，完全不应该到了系统设计阶段再去考虑如何实现业务流程。如果不认真考虑业务需求流程如何处理，等到设计阶段再考虑，那么需求分析就失去了意义，设计工作只能凭空想象无法展开。系统设计阶段的“怎么做”，不是指从业务上怎么做，而是指从技术实现上怎么做。需求分析中的“做什么”，实际上就是规定系统设计阶段在业务上该如何做，设计阶段解决编码阶段在技术上该如何做。



（二）让问题尽早的暴露出来



信息管理系统项目的最终目的是为用户解决问题，而需求分析是这个解决问题过程的开始。既然是解决问题就应当面对问题，而不是回避问题。



大型复杂项目的需求分析是一个复杂的过程，可能会遇到很多业务流程处理方面或技术实现方面非常复杂甚至难以解决的问题。那么该如何对待这些问题，我认为应直接面对这些问题，不要拖延，不要回避，不要等以后再说，以后再想，应该让问题尽早的暴露出来。一是，只有直面这些问题才能和用户坐下来一起找到解决问题的办法，或者变通处理的办法；二是，即使这些问题确实不能解决，双方可及早的做出应对和选择，如果在项目开发进行中，甚至在交付时才暴露出问题，将会造成很多的损失，甚至是失去用户的信任。



一个成熟的需求分析员，应该能够判读出用户需求背后隐藏的问题，或随着系统的使用，业务的扩大和发展在不久的将来会遇到的问题。一个好的软件系统不应当是仅仅满足了用户当前提出的表面需求，还应当一定程度上经得起时间及风险的考验。如果回避一个数据量快速增长的业务需求背后潜在的异地数据的处理，数据库系统的选择，数据查询分析的速度，业务数据的备份，磁盘空间的准备等需求，那么将会在项目投产后面对很多棘手问题，甚至可能导致整个系统推倒重来。



（三）引导用户



需求分析员在客户方的定义中应该是“行业专家”，是一个既懂业务又懂技术的人，是用专业知识为用户创造性的提出解决问题的方案的人。因此，需求分析人员应该以行业专家的身份来引导用户的需求，给出建议，帮助用户合理化其业务流程。比如，用户提出多倍积分需求后，可能没有考虑到是否限制某些或某类商品参与多倍积分，购买超市促销产品是否仍然享有多倍积分等需求，这个时候应帮用户想到这些问题，和用户讨论处理方案。



1、帮助客户优化流程



信息管理系统是管理软件，其目的是帮助客户解决管理问题。那么用户提出的信息化管理方式是否有效，业务流程是否合理，就需要我们进行分析，给出建议。我们要引导客户怎样用信息化管理的方式有效解决问题，提高工作效率，降低管理成本，甚至在软件中融入更先进的管理思想。通常当信息化代替手工和电话方式后，用户在信息的传递，业务的流转，数据的处理，信息共享等方面必将改变原有的业务流程；当客户对软件有更高的期望，希望通过软件带动管理，融入先进的管理方式的时候，可能要进行业务流程的深度调整和重组。一旦牵涉到业务流程的修改或大的系统功能的取舍一定要与客户的管理者或决策者进行充分的沟通，只有取得客户认同和确认才能确定需求分析结果。



2、否定不合理需求



不合理的需求包括，如，不在项目的定义范围内，没有可行性，可能带来隐患，开发难度的增加和需求严重失调，时机或时间不合理等。需求分析员应该用专业的眼光和经验，迅速发现用户提出的需求中的不合理部分，并能给出合理的建议或解释理由。这些原因可能包括行业领先者的参照，目前行业技术上的现实，维护成本和资源开支，系统稳定性，对客户利益有潜在危害等。



（四）创造需求



一方面，作为软件提供商，我们总希望开发出更好的项目；另一方面，软件项目的预算虽然是按照立项时签订的项目框架，但软件的特殊性决定了很多项目的预算需要在需求分析后重新评估。在时间、技术和客户业务需求及预算等条件下，调整可伸缩性需求，适当的创造需求，是一个信息管理软件做的更加完善的重要方面。有些需求可能客户想不到，需求分析人员应根据具体情况酌情提出，既有利于软件功能的增强，也有利于软件额度的增加。



软件工程项目虽有其严格的生命周期，但用户的管理和业务是不断变化的，这就决定了需求的变化性。在系统维护或软件二次开发的阶段，可以引导客户提出更多的需求，如原来因工期原因没有实现的优先级较低的需求、增强性的功能、业务扩展产生的需求、数据量增大带来的需求等。甚至，当现有的软件已经不能适应不断变化的管理和不多扩展的业务时，可合理果断的建议客户进行版本升级，或新系统的开发。比如，对多倍积分模块，如果无线实时传输的需求之前没有实现此时可以提出。同时可以询问客户是否需要在会员生日及节日发提醒短信，是否同时提醒余额（余额不多怎么消费）。还可以建议客户增加统计多倍积分实施效果功能，包括实行后的消费动态，消费统计，消费行为分析，历史同期比较等。这些都是对客户非常实用的功能需求。



最后，所有需求的引导及创造性的提出，都应该适当把握“度”，始终以客户利益的增大和软件功能的完善为根本出发点。



四、用项目管理的思维来做需求分析



（一）需求分析应当考虑的项目管理因素



信息管理系统项目是在时间、预算和客户需求的约束下利用现有的资源完成的复杂性的任务。因此，信息系统的功能和性能特点应当与项目时间和成本的预算相一致，信息系统采用的技术应当是现有的人力资源已经储备或能够提供或研发出来的。项目经理应在最终满足客户要求的前提下对时间，成本和软件功能及性能进行权衡。



需求分析人员在进行分析之前，应当对时间、成本等项目的关键因素有所了解，以便在需求中对功能在满足客户需求的前提下进行适当控制，对性能进行适当把握，和用户达成一致。项目有生命周期，有明确的起点和终点。所有的需求都应该在这个时间范围内完成。需求分析人员应当对需求分析最终形成的结果，即SRS中所规定的需求在这个时间范围内的完成程度心中有数，不能有太大的偏离。



另外，需求分析人员还应利用客户方的资源，选择合适的调研对象，正确处理和各个需求层面的人的关系。这些是需求分析顺利进行的保证，也是项目成功的重要因素。



（二）划分需求优先级



每一个具有有限资源的软件项目必须明确功能需求和性能要求的相对优先级。优先级的设定有助于项目经理解决冲突、安排阶段性交付，并且在交付进度安排很紧且不可改变日期的情况下做出必要的取舍。因为客户希望最早看到最重要的功能，我们希望用最少成本提供最大化的功能。优先级应基于需求重要性、成本开支和风险。需求分析员应了解项目范围和进度安排、预算、人力资源以及质量目标等约束，从而对优先级做出初步划分。



优先级的确定应该由需求分析人员和客户共同讨论决定。客户总是希望那些能给他们带来最大利益的需求享有最高优先级，但需求分析者应该指出难度、时间开支、技术风险及是否在项目定义范围内等，这个时候客户会重新权衡优先级，最终达成一致。另外，有些功能是系统必须的，如果不首先开发将影响系统的架构和后续工作，需求分析人员应向客户说明。



（三）需求分析的“完整”和“完美”



软件技术工作者普遍有追求完美的天性。在需求分析过程中，许多人希望自己的软件功能强大，不仅能满足客户所提的每一项需求，而且能尽可能增加丰富的功能，甚至过多的预计未来的需求,包括对软件的可扩展性、跨平台、可移植性、硬件的适应性、内存资源优化、界面丰富性等方面过多的考虑,而不是立足于项目的实际条件和用户的需求。片面的追求完美，容易使软件工程误入歧途，顾此失彼，轻则加大工作量，增加成本预算，重则陷入泥潭，工期延误。



所用项目风险承担者或利益相关者应该共同努力的目标是项目所规定任务的按时、完整交付，是满足需求不是追求完美。根据NASA的统计，在软件发布后发现的需求错误，49%来源于需求与实际情况不符，31%来源于实际需求遗漏[5] 。另有统计资料表明只有25%的IT项目能在预算时间内按时完成并使客户满意，有一半以上已完成的项目预算被高估了60%以上，而可用性只有原来承诺的70%[6] 。可见，对需求完整性的追求才是软件项目的工作重点，应该抓住主要矛盾，着眼于解决用户最直接最现实的问题。需求分析的首要目标应该是力求“完整”，而不是追求“完美”。





[1] Institute of Electrical and Electronics Engineers (IEEE) ，美国电气和电子工程师协会，网址： http://www.ieee.org/ 。



[2] Point Of Sale(POS)， 销售终端。



[3]《软件需求》，（美）威伊格斯，Leffingwell，1997，第3页。



[4] Offshore Business Process Outsourcing (BPO)，离岸业务流程外包。



[5]《需求分析：高质量军用软件开发的关键过程》，黄锡滋，陈光宇撰，转载网址：http://www.docin.com/p-18373151.html 。



[6] 《项目管理》，高懿编写，对外经济贸易大学教材，第3页。