计算机软件项目管理中的需求分析

王海涛 马秀红

摘要:计算机软件项目的需求分析是项目开发的一个重要阶段，需求分析做的好坏直接关系到系统设计的工作质量，甚至影响到项目的成败。为此，软件项目的需求分析必须规范执行其流程，熟悉项目用户与开发人全貌及项目需求确认和需求评审等，只有这样才能保证软件开发的顺利完成。

关键词:需求分析；项目干系人；系统分析员

中图分类号：F270 文献标识码：A 文章编号：1003-3890（2012）05-0056-03

需求分析是软件开发过程的核心，其结果直接影响到整个的软件开发过程。据相关资料显示，因需求分析因素所造成的软件项目失败或缺陷约占60%，属于系统实施阶段的代码错误，而导致软件项目失败的比率约为40%。项目失败的根源在于需求分析不明确，需求调研不彻底，从而引发需求不断变更，最终导致项目停滞。这些变更不仅加大了开发成本、项目无法按时完成等严重问题，而且，还有可能引发用户方与开发方之间互相指责，导致项目搁浅。

一、软件项目需求分析的重要性

软件系统的开发主要分为五个阶段，分别是系统的需求分析阶段、系统设计阶段、系统实施阶段、系统测试阶段和系统维护阶段。而需求分析阶段是整个五阶段中的重中之重，在该阶段所占的工作量大概是整个软件开发项目的50%，逻辑方案是该阶段的最终成果。逻辑方案不仅是进行系统设计的依据，而且，还是系统最终验收的说明性文件。从以往的经验来看，需求分析做的不彻底，没有深层次的挖掘用户需求，往往可能导致整个项目无法达到预期的效果，或者说设计开发出来的产品不能满足用户的需求。

需求分析首先要对现有系统有充分的认识和了解，在此基础上，通过识别关键问题、分析项目的可行性、详细调查研究、系统化分析，最终设计完成该项目的新系统逻辑方案。只有系统分析员明白了用户的真正需求，才能开发出满足用户的软件产品。在这里，要强调一点的是，在做需求分析的时候，开发方一定要指派有实际工作经验的系统分析员来与用户沟通，而不是指派具体的开发人员，这将避免一些沟通不畅的问题发生。系统分析员在了解用户的基本需求之后，要以书面的形式，准确地制定出软件需求报告。该报告主要说明系统的行为属性，是项目开发过程中对系统的制约。要实现这一目标，就需要系统分析员与用户之间做到紧密协作，甚至系统分析员要深入到用户方的实际业务当中，把自己当做是用户，从用户的角度思考问题，只有这样，开发方才可以真正了解用户需要什么，系统应该做什么。

二、规范执行需求分析的流程

需求分析的过程，要严格执行规范化操作，囫囵吞枣式的需求调研是不可取的。开发方在做需求分析过程中，一定要严格把关，从对用户负责的角度出发，并且也为了降低自己的开发成本，对无法与用户实现很好沟通的项目经理要及时叫停，避免后续工作无法正常进行。

按照需求分析的过程，同样也可将其分为五个阶段：首先要获取用户需求，其次是分析用户的需求，第三是编写需求文档，第四是评审需求文档，最后是管理需求。规范执行需求分析的流程，是需求分析能否成功的关键。图1是根据实际工作经验总结出的需求分析工作流程：

在需求分析过程中，开发方要深入用户方的各个部门，最简单的项目也要做到用户确认需求和需求评审两个过程，复杂的项目甚至要做到多次。

三、尽快熟悉项目用户方干系人全貌

项目干系人又称为项目相关利益者，是指积极参与项目、或其利益会受到项目执行或完成情况影响的个人或组织，项目干系人对项目的目的和结果施加影响。项目管理团队，即开发方，必须识别项目干系人，确定他们的需求和期望，尽最大可能地管理与需求相关的因素，以获得项目的成功。因此，应当从项目的启动开始，系统分析员用户方相关人员的配合下，逐步分清项目用户方干系人具体包含哪些人和部门，通过开方法与其沟通加之用户方领导的协调以驱动他们对项目的支持，从而减小其对项目的阻力。

有些项目在做需求调研时，因受用户方提出的进度要求等因素影响，有些系统分析员不愿与用户过多地交流，只是发一些调研表做一些大概的了解。往往是因为开发方已有与该建设单位相似的原型，会亟不可待地去推广，这样会导致某些差异需求得不到深入了解，用户方只能被动地去适应原型系统，这样的做法是不可取的。另一种情况则是开发方与用户方的技术部门交流比较多，而向业务部门和实际使用人员调查的力度不够，往往容易造成原型试用后，与用户的需求不一致，不得不再对需求做较大调整，造成开发周期不断延期，开发成本大大增加。因此，熟悉项目用户方干系人全貌是进行需求调研的第一步，也是需求调研的基础。在定制的开发项目中，最重要的是要弄清楚用户方中的组织结构关系、业务流程关系、数据流程关系。制定该项目的牵头单位，在此基础上，使用图表的形式将这三种关系表现出来。

四、采取正确的方法获取用户需求

软件开发项目的首要目标就是要发现用户的需求。在对用户进行需求调研过程中，使用的方式很多，初期调研可以采用会议的形式，后续的详细调研以及需求确认，可以采用电话、邮件、小组讨论等方式，模拟演示也是一种很有效的形式，用户比较直观，容易发现、提出问题，但每一次调研过程当中，都要做好笔录，当与用户交流完毕以后，要对交流的结果进行整理、分类，便于后续的分析活动。系统分析人员要对收集到需求做进一步的梳理和分析工作，在这个过程中，首先要对用户提出的具体需求，包括可能该项目目前不涉及的需求，都要知道“为什么”，并且判断用户提出的需求是否合理，对于不合理的需求，开发方要给出不合理的理由和原因。其次，要集中精力，把关注点放在需求分析阶段关注的目标上，即“做什么”，而不是“如何做”，第三就是要分析用户提出的需求当中所衍生出的隐含需求，这一点往往容易忽略掉，这就需要系统分析员在与用户交流当中，关注用户的表情、眼神、用语，因为对隐含需求不加以考虑或考虑不充分，往往会引起永无止境的需求变更。

在需求调研中，还要把握要求相关业务人员与领导同时出席，这将避免用户所提需求的不负责任性和随意性，以及对需求的确认不够积极等问题。项目开发方应掌握用户干系人需求，用户干系人也应具有一定的技术基础，两者缺一不可，只有这样双方沟通起来才比较容易达成一致。对某些需求，用户可能无法想到，系统分析员要做到引导用户的作用，并且要有足够的耐心聆听用户的讲述。

五、分析用户需求并编写需求调研报告

调研结束后，开发方要根据用户的需求编写需求调研报告，即提出新系统的逻辑方案。获取用户需求与分析用户需求二者之间并不冲突，完全可以同时进行，关键问题是如何详细地描述用户的需求，常用的方式是通过建立相关的模型来操作。通过建立模型，抽象出用户的需求，以一种可视化的方式与用户进一步沟通。获取用户需求与分析需求二者之间有着类似的步骤，不同之处仅在于分析用户需求时采用模型来描述。分析用户需求所执行的活动如下：

1. 用业务流程图描述系统的整体业务活动，包括系统之间的接口和边界。

2. 用数据流程图模型来描述系统的数据流关系。可以采用多层次的数据流程图加以描述，对于复杂的数据流关系或功能处理模块要配以数据字典。

3. 通过原型向用户展示系统界面以及各项功能模块，用户可以拿自己的需求与其相比较，存优去劣。

4. 采用实体关系图描述实体、属性、关系三者之间的联系。

在编写需求说明书时，可以采用自然语言或结构化语言来加以描述，当然，可以将需求分析阶段的各类图表列入到需求调研报告中，需求文档应该包括用户的所有需求（包括功能性需求和非功能性需求），这便于在需求确认和需求评审阶段，使用户一目了然，容易理解。

六、项目的需求确认和需求评审

开发方要从两个角度出发来描述系统，一是全面详细地描述现行系统的缺陷和不足，以及业务流程存在的不合理之处。二是在业务流程重组的基础上，提出新系统所优化的各项业务流程和系统所具有的优点。并将二者业务流程文档化后与客户进行探讨，对于描述不准确不精确的地方要加以细化，对于错误的地方要进行修改，最终让客户进行确认。需求评审的目的就是对需求分析阶段的成果做出评价，提出不足，进一步优化流程，纠偏、完善需求调研报告。需求确认与评审是不可逾越的两个阶段，有研究表明：由客户发现的一个错误，然后更正错误，约需要多花90倍的时间，可以看出，需求确认和评审阶段的重要性。

需求评审的关键在于邀请这方面的专家、用户、领导对新系统进行评价。当然，在确认评审阶段，开发使用双方都要在场，开发方在讲解需求报告时，要做到细致入微，不能放过任何一个功能模块，使得双方共同找出需求调研中不合理的、不完善的、有歧义的、遗漏的问题。需求评审的目的是要获得用户的认可，如果用户用户以种种理由不以确认，那么系统分析员要尽快拿出原型系统来给用户确认，否则后续的工作将无法顺利开展，并伴随着无穷无尽的需求变更。

参考文献：

[1]黄梯云.管理信息系统（第四版）[Ｍ].北京:高等教育出版社，2008.

[2]吴洁明.软件工程应用实践教程[M].北京：清华大学出版社，2003，（８）.

[3]赵池龙.实用软件工程[M].北京:电子工业出版社，2006.

[4]徐锋.软件需求最佳实践:SERU过程框架原理与应用[Ｍ].北京：电子工业出版社，2008.

责任编辑、校对：秦学诗