《软件项目开发过程中的需求分析和范围管理》由会员分享，可在线阅读，更多相关《软件项目开发过程中的需求分析和范围管理（4页珍藏版）》请在金锄头文库上搜索。
1、软件项目开发过程中的需求分析和范围管理0引言对于一个软件系统的开发来说，最困难的部分就是准确说明开发什么，最困难的概念性 工作就是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作 一旦出现纸漏，将会给系统带来极大的损害，并且以后对它修改也极为困难.所以，需求是整 个软件产品链的源头，需求工作的优劣将直接影响到产品的设计、生产、销售和维护的全过 程。而对于项目中哪些该做，哪些不该做，做到什么程度，则都是由范围管理来决定的。软 件项目开发过程中,花费大量时间用于需求调研和分析，也都是为了准确控制好项目范围， 以便于对整个项目的进行实施有效的管理.所以说，明确的需求、准确的项
2、目范围控制和管 理，是项目成功的基础所在.1需求分析需求分析是一个项目的开端，也是项目建设的基石。由于需求不明确而造成项目产生 风险甚至失败的比例是相当高的。因此一个项目成功的关键因素之一,就是对需求的把握程 度，即所谓的需求开发与管理.1。1需求开发与管理的概念需求分析的过程包括了需求开发和需求管理两个部分。需求开发指的是从情况收集、 分析和评价到编写文档、评审等一系列产生需求的活动，这几个阶段的活动可以是相互独 立和反复的，不一定非要遵循线性的顺序。需求管理则是与需求直接相关的活动即软件项 目开发过程中控制和维持需求约定的活动，主要包括：变更控制、版本控制、需求跟踪、需 求状态跟踪等工作.
3、和传统的产业相比，由于软件项目的需求具有模糊性、不确定性、变化性和主观性的特 点，它不像生产汽车、电脑硬件的需求，是有形的、客观的、可描述的、可检测的，同时由 于需求分析的参与人员、业务模式、投资、时间等客观因素的影响，造成了软件需求分析 是软件项目开发中最难把握的问题。需求分析工作的复杂性及面临的潜在风险主要体现在 以下方面：（1）需求描述的准确性问题；（2）需求的完备程度问题；（3）需求开发的时间 问题；（4）需求的细化程度问题；（5）需求的变更问题。1。2需求变更在软件开发过程中需求的变化是永恒的,需求不可能是完备的，软件开发的过程实际上 是同变化做斗争的过程，而造成需求变化的原因也有很
4、多。比如：随着项目的进展开发方 和客户方对需求的了解越来越深入，原先的需求文档可能存在这样或那样的错误和不足， 因此要变更需求；由于市场和业务发生了变化，原先的需求文档可能跟不上当前市场的要 求,因此要变更需求等等。需求的变化问题是每个开发人员、项目经理都会遇到的问题，需 求的变更不一定是坏事，常常提出需求变更的动机是好的，目的是希望产品更加符合用户 的需求.但是一旦需求发生了变化，随之而来的将是不得不修改设计、重写代码、修改测试 用例、调整项目计划等问题，对项目开发小组而言，变更需求意味着要调整资源、重新分配 任务、修改前期工作成果等，这将为项目的正常进展带来诸多的麻烦，开发小组也要为此付
5、出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。 而在需求变更过程中最难办的事情是莫过于拒绝客户提出的需求变更请求，通常情况下开 发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的 办法是事先将需求分析工作尽量做完备，即在需求分析上遵循一定的方法步骤，在需求管理 上遵循一定的策略。1。3需求分析的步骤在需求分析工作上应定位三个阶段。第一阶段：访谈式。这一阶段是和具体用户方的 领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势， 了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体情况、客 观
6、的信息，建立起良好的沟通渠道和方式.第二阶段：诱导式.这一阶段是在开发方已经了解 了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体实 际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面同时 结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务 流程设计的合理性、准确性、便易性、习惯性.用户可以操作简单演示的DEMO，来感受一下 整个业务流程的设计合理性、准确性等问题,及时地提出改进意见和方法。第三阶段:确认 式。这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据确认这个阶段 开发方必须提供原型系统和明确的业
7、务流程报告、数据项表并能清晰地向用户描述系统的 业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及承建方提供的DEMO系 统，来提出反馈意见，并对已经可接受的报告、文档签字确认。三个阶段或者说三步法的实 施和采用，对用户和承建方都同样提供了项目成功的保证.1。4需求管理的策略在需求管理上应遵循以下策略：（1）需求一定要与投入有必然的联系，否则如果需求 变更的成本由开发方来承担，则项目需求的变更就成为了必然。在项目的开始无论是开发 方还是出资方都要明确这点:需求发生变化，软件开发的投入也要变.（2）需求的变更要经 过出资者的认可.需求的变更将引起投入的变化，所以要通过出资者的认可，这样
8、才会对需 求的变更有成本的概念，能够慎重地对待需求的变更。（3）小的需求变更也要经过正规的 需求管理流程。小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中 人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率浪费了 时间。正是由于这种观念才使需求的渐变不可控，最终导致项目的失败。（4）精确的需求与 范围定义并不会阻止需求的变更。并非对需求定义的越细,越能避免需求的渐变，这是两个 层面的问题。太细的需求定义对需求渐变没有任何效果，因为需求的变化是永恒的并不会 因为需求写细了，它就不变化了.（5）注意沟通的技巧。实际情况是用户、开发者都认识 了到了上面的几点问题
9、，但是由于需求的变更可能来自客户方、也可能来自开发方作为客 户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他 们的目的可能是使软件做的更精致，于是作为需求管理者、项目经理需要采用各种沟通技巧 来使项目的各方各得其所。基于上述的问题,必须对需求进行管理，使需求能够真正成为软 件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持一致，使需求可以复 用.1。5监理方责任为了保证项目的成功，作为第三方的监理公司也必须加强项目管理和项目分析工作，要 提醒开发方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研。在原 则上，需求阶段监理应尊重承建方的项目
10、管理和项目分析能力；在具体的任务开展上以不 深入、不干扰承建方的自主权为主，除非在项目合作过程中发现承建方的项目管理以及项目 分析能力存在很大的差距和不足；在具体的操作上可以坚持吸收、同化、贯彻的方法和手 段.只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、开发范围上 有发言权。2范围管理对于项目中哪些该做，哪些不该做，做到什么程度等问题，都是由范围管理来决定 的。与需求相关的一系列问题，都属于项目范围管理的问题2.1产品范围与项目范围项目中花费大量时间和精力用于需求调研分柝也是为了确定项目范围。范围的概念应 包含两个方面，一个是产品范围，即产品或服务所包含的特征或功能；另一
11、个是项目范围， 即为交付具有规定特征和功能的产品或服务所必须完成的工作.在确定范围时首先要确定最 终产生的是什么，它具有哪些可清晰界定的特性。要注意的是特性必须要清晰以认可的形 式表达出来，比如文字、图表或某种标准，能被项目参与人理解，绝不能含含糊糊、模棱两可, 在此基础之上才能进一步明确需要做什么工作才能产生所需要的产品。也就是说有了明确 的产品范围，才可以确定为达到这个目的需要做哪些工作，即项目范围，换句话说产品范围 决定项目范围。2.2范围管理实施方法如何做好范围管理，应注意做好以下几方面的工作：（1）编制范围说明和范围管理计 划；（2）范围分解；（3）范围变更控制。2。2.1编制范围计
12、划具体的说，范围说明是在项目参与人之间确认或建立了一个项目范围的共识，作为未来 项目决策的文档基准。范围说明中至少要说明项目论证、项目产品、项目可交付成果和项 目目标。范围管理计划是描述对项目范围如何进行管理、项目范围怎样变化才能与项目要 求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估。范围管理计 划还应该包括对变化范围怎样确定以及对变化应归为哪一类等问题的清楚描述。2。2.2范围分解完成项目是一个复杂的过程，计划明确了，还应采取分解的手段把主要的可交付成果分 成更容易管理的单元才能一目了然，最终得出项目的工作分解结构（WBS）。比较常用的方 式是以项目进度为依据划分WBS
13、，第一层是大的项目成果框架，每层下面再把工作分解，这 种方式的优点是结合进度划分，直观、时间感强，评审中容易发现遗漏或多出的部分，也更 容易被大多数人理解.2。2。3范围变更管理一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的，因此 对变更的管理是项目经理必备的素质之一。变更并不可怕，糟糕的是缺乏规范的变更管理过 程。范围变更的原因是多方面的，项目经理在管理过程中必须通过监督绩效报告、当前进展 情况等来分析和预测可能出现的范围变更，在发生变更时遵循规范的变更程序来管理变更综上所述,工欲善其事，必先利其器.对于一个项目经理要想真正管理好项目，没有必要 的技术和方法是肯定不行的。只有把需求分析与管理、项目范围管理的功课做充分，把基 础打牢固，才能在项目的开发过程中减少不必要的麻烦，项目才有可能获得最后的成功。
