软件项目的需求变更

软件项目的需求变更（共7篇）

软件项目的需求变更 篇1

一、问题的提出

什么是需求分析?

要知道需求变更是什么, 首先要知道什么是需求分析。

需求分析是指理解客户需求, 就软件功能与客户达成一致, 估计软件风险和评估项目成本代价, 最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。

什么是需求变更?

根据软件工程思想定义, 需求说明书一般要经过论证, 如果在需求说明书经过论证以后, 需要在原有需求基础上追加和补充新的需求, 或对原有需求进行修改和削减, 均属于需求变更。

二、需求变更的原因及影响

1. 需求变更原因

一方面是用户:他们是项目需求的提出者。一个十分常见的现象是用户提出需求以后, 在软件开发过程中用户改变了需求, 这只能迫使开发工作返工, 丢弃一些无法修正的部分。无疑这会造成一定的损失, 但又无法完全避免。要求用户一次性把需求讲清楚, 并且不允许此后需求有任何变更, 这是不现实的。只能尽量减少需求变更, 降低它所造成的影响。

二是系统因素:在系统内部, 如计算机硬件、系统软件或数据的变更要求与其相适应。

三是外部环境因素:与软件运行相关的工作制度或法规、政策的变更, 或是业务要求变更导致的需求变更。

四是需求分析阶段工作缺陷:需求调研、分析、定义和评审工作不够充分, 致使需求规格说明中隐含着问题, 在开发过程中才有所发现。或者需求开发中开发人员与用户沟通不够充分, 如未能如实获得用户的潜在需求等。

软件需求一旦出现变更, 它可能要涉及到一些相关的代码和文档的修改, 为此要把这一变更通知到所有相关人员。提出需求变更有可能在开发的任何阶段, 并且随着项目的进展, 越晚的需求变更引起的损失越大。

2. 需求变更给软件的开发工作带来的影响

需求变更对软件开发的影响是多方面的, 概括的看, 包括以下三个方面:

(1) 增加项目的人员、费用开支, 影响开发进度。需求变意味着原先的需求调研、分析的结果与预期的软件实现存在偏差, 需要进行需求变更。这无疑要增加项目的人员、费用的开支, 并对开发进度造成影响。更有甚者, 如果变更频繁, 可能对项目造成较大影响, 严重时可能直接导致项目的失败。

(2) 影响软件质量。在一个复杂的软件系统中, 需求之间具有一定的联系, 相关需求可构成需求链。如果由于需求变更导致需求链的某些环节脱节, 就可能引起一些难以察觉的错误。当需求变更没能及时修改项目的设计、开发文档时, 这些错误一般难以被测试人员发现, 将直接影响系统质量, 严重时可导致系统崩溃。

(3) 影响开发者与用户之间的合作关系。需求变更的实施是用户和开发者相互协作的过程。开发者和用户在是否采用变更问题上常常产生分歧, 如果没有恰当处理, 影响双方的互信, 从而影响项目开发进程。同时需求变更也会在项目开发人员之间产生分歧, 影响合作关系。

三、采取的对策

1. 首先是预防

尽量做好需求分析工作, 以期减少需求变更的频次, 为此在需求分析阶段着重处理好以下问题, 力图使需求分析的结果更接近目标。

(1) 培养正确的需求意识。优秀软件产品建立在优秀的需求基础之上, 而高质量的需求又来源于客户与开发人员之间有效的交流与合作。因此, 双方的参与者都需要认识到:要想获得成功, 自己需要什么, 合作方又需要什么。只有这样, 才能建立融洽的合作关系。因此, 培养正确的需求意识是双方都需要努力的, 而开发人员在这个阶段应该发挥更加积极主动的作用。

首先, 需求分析人员应该接受一定的正规培训, 以提高与人沟通的能力、缓解矛盾的能力、善于倾听和询问的技巧, 以及收集整理资料的能力等。在参与具体项目时, 分析人员也应主动学习一些项目所涉及的具体应用领域的基本知识, 以更好地理解用户的需求。

其次, 开发单位应该对那些不想花时间在需求分析上的用户明确指出:如果用户不能充分地支持并参与, 项目很可能会失败;开发单位还可以通过学习一些前车之鉴的真实案例警告用户:低质量的需求分析可能导致严重的后果。通过对用户代表和管理人员的培训, 使他们真正理解需求分析的重要性和忽略需求带来的风险, 并对计算机系统有一个大体的了解, 这样用户才能够主动地参与需求分析。

同时, 正因为不可能一次就完全了解用户的需求, 而且在系统开发过程中还需要不断地请用户参与, 因此与用户的沟通是需要贯穿始终的。需求分析中所采取的一些策略可能会让用户觉得意外和难以接受。因此, 需求分析人员需要对用户解释一些做法的必要性和合理性, 以得到用户最大的支持与合作。

(2) 从业务需求入手。用户认识到了需求分析的重要性, 但可能仍然不知道从何处入手表达自己的需求。这时可以从业务需求入手, 任何企业对自己的经营运作目标应该是比较清楚的, 这样的经营背景让用户不仅有话说, 也让开发者有章可循。需求分析不可以完全与它所处的背景相脱离, 只有当系统真正置身于它的社会和组织环境中, 它的需求才能清晰地反映出来。

(3) 充分利用需求来源。有了以上需求背景, 就比较容易做到有的放矢了。需求分析人员可以直接与系统未来的操作者探讨他们希望有什么样的软件;观察系统的潜在用户当前的日常工作以获取有价值的信息;系统的使用者可能有很多, 可以将他们分类以简化需求;最后一定要与真正的决定者达成协议:对于有冲突的需求如何权衡, 对于直接用户的众多需求如何取舍等。

同时, 用户往往对计算机期望过高, 认为计算机可以解决当前存在的所有问题, 因此会提出很多的功能需求, 并且希望在很短的时间内看到成效。但是, 由于技术、人力等资源的限制, 并不一定能够在设定的时间期限内满足用户所有的期望, 这时就应该尽早确定出交付的产品应具备的最重要功能, 即设定需求的优先级。

在这个阶段, 可以采用UML中的用例图帮助用户和需求分析人员之间的交流。一个用例图描述用户可以用软件产品执行的一个任务。它不是从软件的性能和系统的行为方面出发, 而是从用户到底能够用这个软件产品干什么入手。这样的方式用户比较熟悉, 容易沟通;而且不会在需求分析的一开始就陷入过于细节化的设计, 也有助于避免分析人员添加一些与所需任务无关的自认为很好的功能。

(4) 提供选择方案。由于用户对软件系统缺乏经验, 或者由于用户的运作机制还未完善, 或者由于其他种种原因, 用户可能仍然不能对一些需求做出明确的说明, 收集整理的需求中可能仍然存在一些不确定因素。这时可提出几份比较详细的方案。附带不同做法的优点, 供用户选择或者启发用户确定需求。

如果需求分析做得好, 文档清晰且又有客户签字, 那么后期客户提出的变更就超出了合同范围, 需要另外收费。这个时候, 开发方一定要据理力争, 此时这并非要刻意赚取客户的钱财, 而是不能让客户养成经常变更的习惯, 否则后患无穷。

2. 分级管理客户需求

软件开发项目中, “客户永远是对的”和“客户是上帝”并不完全的正确, 因为在已经签定的项目合同中, 任何新需求的变更和增加除了影响项目的正常进行以外, 还影响到了客户的投入收益, 所以有的时候项目经理反倒应该为客户着想。

对于项目中的需求变更, 可以实行分级管理, 以达到对需求变更的控制。

一级需求变更是关键性的需求, 这种需求如果不满足, 意味着整个项目不能正常交付使用, 前期工作也会被全部否定。这个级别的需求是必须满足的, 否则就意味着否定自已的项目成员和成员的所有努力, 所以定为“Urgent”。

二级需求变更是后续关键性需求, 它不影响前面工作内容的交付, 但不加以满足, 新的项目内容无法提交或继续, 所以是“Necessary”。一般新模块关键性的基础组件, 属于这个级别。

三级需求是后续重要的需求, 如果不被满足会令整体项目工作的价值下降, 为了体现项目价值, 也是开发人员自已的技术价值的证明, 所以定为“Needed”。一般性的重大的有价值的全新模块开发, 属于这个级别。

以上三个等级是应该实施的, 但时间性上可以作优先级的排列。

四级需求是改良性需求, 没有满足这类需求并不影响已有功能的使用, 但如果实现了则会更好, 定级为“Better”。界面和使用方式的需求, 一般在这个档次。

五级需求是可选性需求, 更多的是一种设想, 以及一种可能, 通常只是客户的的一种个人喜好而已, 定级为“Maybe”。

对于四级需求, 如果时间和资源条件都允许的话, 不妨做下去。对于五级需求, 正如对它的描述一样做与不做是“Maybe”。

3. 加强需求变更的控制

在需求分析阶段工作完成后, 需求变更仍可以会发生, 因此就要加强对需求变更的控制, 主要有以下原则:

(1) 建立需求基线。需求基线是需求变更的依据。在开发过程中, 需求确定并经过评审后 (用户参与评审) , 可以建立第一个需求基线。此后每次变更并经过评审后, 都要重新确定新的需求基线。

(2) 制订简单、有效的变更控制流程, 并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时, 这个流程具有一定的普遍性, 对以后的项目开发和其他项目都有借鉴作用。

(3) 成立项目变更控制委员会 (CCB) 或相关职能的类似组织, 负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成, 应该包括用户方和开发方的决策人员在内。

(4) 需求变更一定要先申请然后再评估, 最后经过与变更大小相当级别的评审确认。

(5) 需求变更后, 受影响的软件计划、产品、活动都要进行相应的变更, 以保持和更新的需求一致。

(6) 妥善保存变更产生的相关文档。

这六大原则看起来简单, 但真正实施起来有难度, 还需要依据理论知识配合开发项目组的实际工作情况, 在实践中不断摸索总结。

四、总结

软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理, 将需求变更的频次大幅度降低, 从而为软件项目的顺利实施打下坚实基础。

参考文献

[1]王莉吴洁明:软件项目中的需求变更管理的研究[J].计算机技术与发展, 2007, 17 (1) :120～121

[2]王强:软件开发项目中的需求变更管理[J].电脑知识与技术 (学术交流) , 2007, (11)

[3]李师贤张珞玲:需求分析的常见问题及其对策分析[J].计算机工程, 2002, 28 (1) :7～8

[4]小庄:软件开发项目中的需求变更分析和解决之道[EB/OL].http://www.mypm.net/articles/show_article_content.asp?articleID=11472&pageNO=1, 2007～6～28

软件项目需求变更与应对策略 篇2

1 软件项目需求变更分析

1.1 需求不精确、软件项目的任务范围主要是由项目开发团队定义

在项目开始阶段, 一方面, 由于用户以前没有相关软件的使用经验, 他们对要开发的软件没有明确的想法, 不能确切地定义自己需要什么样的功能需求;另一方面, 用户有类似软件的使用经历, 但是他们常常只是依据当前的工作所需, 提出一些初步的功能需求, 而采用的新设备、新技术通常会改变他们的工作方式, 引入一些崭新的功能需求。

1.2 用户需求随项目进展而变

尽管开发团队已经做好了可行性研究, 与用户签订了较明确的技术合同, 然而随着项目实施的进展, 软件开始展现功能的雏形, 用户对软件的了解也逐步深入。用户的需求不断地被激发。于是, 他们可能会想到各种新的功能和特色, 或对以前提出的要求进行改动。他们了解得越多, 新的要求也就越多, 导致软件实现的功能、程序界面以及相关文档需要经常修改, 需求变更因此不可避免地一次又一次出现。

在这种情况下, 假设开发团队不能有效地控制需求变更, 或是采用一些不能产生效用的的需求变更措施, 都有可能使开发项目不能按时完成, 加上一些控制管理流程不到位, 最终将导致项目成本上升、人员不足, 甚至可能导致整个项目不成功。因此, 加强软件需求管理对于保证软件质量具有重要作用, 并且能很大程度控制需求的变更情况, 最终达到满足顾客的需要, 这就是我们进行需求变更的最大目的。

2 软件项目需求变更管理实践中的几点对策

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受, 还要增加实施变更和验证两个步骤, 有时还会有取消变更的步骤。针对变更控制流程, 笔者在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策:

2.1 加强协调沟通, 充分交流

需求获取是系统开发过程中最困难、最关键和最易出错的环节, 同时也是最需要沟通交流的活动。大型复杂软件的成功研制是建立在成功的需求获取基础上的, 高质量的需求获取来源于用户与系统参研人员之间有效的交流、沟通与合作。

很难想像遭到用户抵制的项目能够成功。在探讨需求的时候, 开发人员和用用户应该相互理解、相互合作, 双方在共同努力下, 一起解决问题。如果用户提出了一些苛刻的要求, 开发人员一定要耐心地听取意见, 并认真地分析问题的关键, 进一步提高用户需求的满意程度。

所谓的需求变更, 其实就是用户与开发人员不断进行沟通交流的一个过程。作为一名软件的开发人员一定要对用户提出的意见认真思考和设想, 通过仔细分析得出结论。此外, 在软件开发项目动工以前, 开发人员要和客户说明一些事项, 例如, 软件开发进入实施阶段以后, 用户提出的需求变更会给整个设计工作带来很大的困难和不良的影响。

2.2 合同约束

众所周知, 需求变更会给软件开发带来很大的影响, 因此, 开发之前应该与用户签订保障合同, 限制用户在软件开发阶段提出不合理的需求变更, 或是规定用户在一定的时间范围以内提出变更需求。

2.3 区别对待

对需求变更不能简单拒绝或同意, 而是通过一系列成本和时间的评估由客户做判断。需求变更在软件生命周期内的任何阶段都有可能发生, 如果变更提出时系统需求正在开发, 那么必须评估该变更对需求产生的影响;如果变更提出时系统正在执行开发或已进入下一阶段, 那么就要评估该变更对需求、系统设计和开发的一系列影响。在软件开发阶段, 某些用户会向开发项目组提出一些不可能变更的需求, 这样就会导致开发项目组的工作量变大, 对项目进程产生很大的影响。如果遇到这种情况, 软件开发相关人员就要和用户进行商榷, 项目的开发是根据最开始的需求而确定的, 如果有重大的需求变更, 就会对开发的项目带来很大的困难和一些不必要的工作量。如果用户依然坚持要变更需求, 那么就要求用户根据新需求的重要程度进行排列, 并且划分出紧迫的档次, 把它作为需求变更的重要依据。此外, 对于用户提出变更的频率要严格控制。

2.4 选择恰当的开发模型

对于那些需求不明确的开发项目可以采用建立原型的开发模型。根据用户的需求, 开发人员建立一个系统的原型, 然后在和用户进行沟通交流。通常情况下, 用户看到实际的模型后, 对需求就有了更明确的要求, 开发人员再依据用户的一些要求对系统进行完善。经过几轮的商榷以后, 系统原型最终会达到用户的满意程度, 从而减少了在开发过程中需求的变更。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。

2.5 用户参与需求评审

用户是需求的最初提供者, 因此, 也是最有权对需求进行评审的人。其实, 在整个软件的开发过程中, 用户往往能提出一些建设性的意见, 非常具有价值。此外, 这也是用户提出需求的最后一次机会, 从而进一步减少了用户的需求变更情况。

3 结语

软件项目开发过程中, 一方面在项目初期用户不能提供很完整、明确的需求, 另一方面由于与用户交流沟通不够, 导致不能完全理解用户需求, 造成用户不满意, 使需求不断发生变更, 带来一定风险。应对措施是一方面在业务建模阶段多让用户参与, 及时得到反馈意见, 达成共识;另一方面及时做好变更控制和配置管理工作, 及时针对需求变化, 更新相应设计, 降低风险造成的影响。

摘要：本文主要阐述了软件项目开发过程中需求变更的原因及其应对策略。

软件项目的需求变更 篇3

1 常用的需求变更控制流程

“需求管理”是C M M 2级的一个K P A (Key Process Area, 关键过程域) 。CMM2级中对”需求管理”的目的定义为:分配给软件的系统需求是受控的, 建立供软件工程和管理使用的需求基线;软件的计划, 产品和活动和系统需求是一致的

CMM对需求管理的建议可以归纳为三点:首先, 应该让有经验和有能力的人来做需求分析活动和需求管理活动;相关的人员应该接受培训。其次, 要对需求分析活动进行评审, 保证他们是可控制和管理的, 并且是软件需求是合适的。最后, 如果需求更改了, 必须对由此造成的其它软件计划, 工作产品等的更改必须加以规划, 识别, 评价;对这些更改要做风险评估;所以这些都需要文档化;并且传达给相关的人员并且一直跟踪这些变化。其中最后一点对需求变更控制提出了明确的要求。

鉴于以上要求, 很多公司和培训、咨询机构都设计了非常严密变更控制流程。

以本文作者所服务的通信行业软件公司 (以下简称“公司”) 为例, 为实施CMM管理体系, 将变更控制流程分为:变更请求、变更评审和分析、变更实施三大子过程。

在进行变更请求时, 需要提供 (预评估) 如下内容: (1) 需求变更内容的描述:变更类型 (增加/删除/修改) 、要求、对应的当前需求等; (2) 由此带来的对已有成果的影响 (设计、编码、测试等) ; (3) 对项目的影响 (项目进度的变化、资源需求的变化等) 。

为了表示对需求变更控制的重视, 公司特别强调了“需求变更评审”的重要性, 要求评审应该由项目经理组织, 高级经理 (项目经理的管理者) 、产品经理、市场 (代表客户) 、质量代表 (代表质量部和流程改进组) 、研发人员、需求管理员等各种角色应该参与到评审过程中, 并对变更负责。

分析公司制定的需求变更控制流程, 以及咨询公司的改进建议等, 给人形成了一种很不好的感觉, 那就是“变更是不好的, 所以应该严格控制变更”。而事实上, 在软件定义阶段, 由于客户对产品往往还不能形成一个完整的印象, 需求不明几乎是所有项目的共同起点。在需求变更时, 客户也不会很好的对变更带来的影响做详细评估, 而是简单的提出要求, 并且要求实时响应。而对于小型软件公司来说, 如果僵化的坚持“需求及其变更必须明确后再开始项目”, 就无法体现小公司灵活, 快速的特点, 在业界根本就无存活的可能。

公司制定的整个流程看起来完美无缺, 非常符合C M M审核的要求, 但是在执行中, 却遇到了以下问题:对于变更申请时必须填报的变更申请表, 客户及其接口都觉得内容过于繁复, 不愿意配合填报。客户更希望提出需求, 并得到响应。由于要求需求变更必须得到高级经理, 项目经理, 公司产品部, 客户, 需求管理人员等各方人员的认可, 并且在进行了深入评估后才能实施变更。因此, 任何变更都不可能实时实施, 实际执行结果是客户不能接受此过程, 认为公司效率低下, 给公司管理层和开发人员造成了很大压力。由于流程未遵循闭环管理原则, 因此, 一些需求公司已经实施, 但是未能及时反馈到需求提出者, 客户感觉需求未得到响应, 降低了客户感受。总之, 从根本上来说, 每个公司实施质量管理体系的目的都是为了更好的满足用户, 因此, 一个不能让客户满意的流程肯定不能说是一个好的管理流程。

2 简化的需求变更控制流程

2.1 流程设计原则

我们回头来看C M M的要求, 其关键是识别变更、评估变更、文档化变更、跟踪变更。要求这些并非一定要由客户来完成, 或者说公司级别来完成。CMM对评审的要求准则是应评审需求的变更, 而对评审的目的, 则可以遵循对需求管理的目的:在顾客和软件项目之间建立对顾客需求的共同理解。而对评审的方式, 参与人员并无机械的要求。

遵照以上要求, 本文提出了一种简化的需求变更控制流程。在小型软件企业中, 可以在如下几个方面来简化变更控制: (1) 简化变更请求。客户只要提出变更的要求, 变更的分析交由公司内部完成。 (2) 变更的权利交由项目级别决定。 (3) 改变变更评审为变更上报和跟踪。项目经理可以根据客户需求, 首先在项目层面实施变更, 但是, 项目经理必须对变更可能的影响等及时通知给高级经理、产品经理、公司级需求管理人员和客户。 (4) 在变更申请人、需求跟踪人员和项目经理发生变更冲突或者以上人员认为必要时, 再启动公司级别的变更控制评审。

2.2 简化需求变更控制流程

图1给出了简化后的需求管理流程。

[活动1-1]的负责人为需求提出者。

任何人都可以提出需求。即新的需求或者需求变更可以来源于和客户直接交流的市场人员, 产品人员, 客服服务人员, 也可以来源于研发者。客户交流的邮件、会议纪要等文件可以作为需求变更申请的附件。

[活动2-1]需求变更确认

活动2的负责人为项目经理, 活动2的实施者则包括含项目经理在内的所有项目组成员。

项目经理根据需求变更申请中的中描述的内容, 考虑其影响程度, 自行、召集项目成员, 或者将需求提交RRM进行需求变更的评审, 针对需求变更申请中的相关描述, 以及参考产品, 市场, 以及对相关组的影响等各方面的综合因素, 确认是否需进行修改, 修改人, 验证变更人, 修改方案等内容, 并及时跟踪将此信息。

项目经理是负责督促实施需求的人, 因此, 其有责任去了解需求, 分析需求, 以确保需求的清晰明确。

[活动2-2]需求设计和实现

[活动2-3]需求测试

以上可统称为需求实施活动。活动2中的需求实施活动和普通研发活动并无特别之处, 这里不做详述。

在活动2的描述中, 还提到了一个非常设的机构RRM (RequirementReview Meeting) 来处理异常流程和争端。作为流程的规定, 以下条件可促发RRM。

1) 未处理的新需求或者需求变更超过门限值。

2) 两次RRM的时间间隔超过门限值;

3) 需求提出者和项目经理对“不合理”“不合格”存在异议时, 或者其他项目经理、需求管理、项目负责部门、产品市场部等需求干系人觉得存在重大需求, 在项目级别不能达成解决, 或者一致意见而需要公司级别集体讨论时。

以上任何一个条件符合, 项目经理将组织RRM, 就项目遗留的需求进行讨论, 并给出结论。

管理好需求变更, 才能管理好项目。需求变更是不可避免的, 只要项目存在一日, 变更便会随时产生, 逃避变更、排斥变更都不能改变需求变更的事实。本文遵循CMM要求, 提出了一种需求变更控制方法。本文设计的方法主要应用于小型软件项目, 当然管理一个小型软件项目, 除了流程和工具的支持, 更重要的是项目管理者, 参与者, 支持者都应该在需求管理过程中多沟通, 勤实践, 并能积极借鉴业界管理体系的有益指导意见, 唯有如此, 才能更好的完成客户需求, 提高客户满意度。

参考文献

[1]SEI, Key Practices of the Capability Maturity ModelSM, Version1.1, 1993.

[2]中国标准研究中心.ISO9001:2000标准, 2000.

软件开发中的需求分析和需求变更 篇4

关键词：需求分析,需求变更,需求管理

1、引言

软件需求分析工作是软件生存周期中重要的一步，也是决定性的一步，只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。

随着社会工业化、信息化以及计算机及其应用技术的迅速发展，各种各样的软件和系统也随之出现，软件开发人员所面临的应用系统的复杂性越来越高，规模也越来越大，支持系统开发的基础软件面临着系统的复杂性、多样性、不间断性和自适应性等一系列关键问题的挑战。需求分析的重要性和必要性也就体现出来了，需求分析的质量好坏直接影响整个软件工程的进展及最终的结果。Bell和Thayer提出，"不充分、相互矛盾以及非完全的软件需求描述是影响软件设计质量的一个非常关键的因素"。他们指出"设计一个系统的需求并不总是非常清楚的，特别是对于较为复杂的系统设计，需要采用工程的观点，对待开发软件系统的需求进行系统地分析和设计"。

2、需求分析概述

2.1 需求分析

需求分析的工作就是通过和用户进行交互以获取软件系统的需求，对它们进行描述和分析，产生规范化的需求文档，并要确保所产生的用户需求是完整的、一致的和准确的。

需求分析的类型我们可分为两大类：功能性需求和非功能性需求。功能性需求主要说明了系统可以完成的所有事情，涉及与本系统有接口的其他系统的所有事情。它是用户最主要的需求，通常包括系统的输入、系统要完成的功能、系统的输出以及其他。非功能性需求是软件开发过程中必须遵守的约束，是对可以使用的资源和软件质量的各个方面的限制。

2.2 需求分析的任务

软件需求分析的任务是确定系统要完成的工作，而不是怎样完成它的工作。它所做的工作就是深入描述软件的功能和性能，确定软件设计的限制和软件同其他元素的接口细节，定义软件的有效性要求，研究用户要求，准确地表达被接受的用户要求，确定被开发软件系统的系统元素，最后将功能和信息结构分配到这些系统元素中。因此，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的"做什么"的问题，如图1。

由此可知，实现步骤是：

·获得当前系统的物理模型；

·抽象出当前系统的逻辑模型；

·建立目标系统的逻辑模型。

最终目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。

2.3 需求分析过程

软件需求分析的过程具体可分为信息获取、需求建模和需求报告产生三个阶段。

2.3.1 信息获取阶段：

主要任务是将各种信息从不同的用户角度不加选择地收集到一起。信息的收集过程可采用很多种方式，比如：采访、访谈、问卷调查、直接参与业务实践等方法，无论采用哪种方法，其主要目的是用户都能够表达他们的需求目标。在信息获取过程中，用户所表达的需求会有产生冲突和矛盾的地方，这时就需要需求人员进行协调，最终达成一致意见。在此过程中，需求分析人员应具有与人沟通能力，有良好的理解和表达能力，同时能总体规划，抽象和分解，确认事务本质。通过该阶段的工作，得到一个目标明确，需求完整的描述文档。

2.3.2 需求建模阶段：

需求分析的目的是通过对待开发软件系统预期实现目标的分析，识别出所有相关的概念和关系，建立需求模型。建立需求模型需要一套完善的需求分析理论的支持。现在有许多建模语言，其中最常用的有统一建模语言（UML）、统一开发过程（RUP）以及自动规约的知识获取（KAOS）等等。

2.3.3 需求报告产生阶段：

基于前两个阶段的工作，需求分析人员最终将提交出待开发软件系统的需求分析报告。其中重点包括分析系统的组件对象、领域约束和行为需求，以及从模型中抽取出基本的领域概念字典和涉及的资源信息等。这样的模型必须是一致的，明确的和完整的。这份报告将作为下一步开发的规范文件，并成为衡量设计是否达到需求要求的唯一标准。

3、需求变更及对策

自上个世纪60年代以来，软件工程思想逐渐形成与发展，出现了很多软件开发模型和方法，例如瀑布模型、演化模型、螺旋模型和智能模型等。而在90年代以后，卡耐基软件学院推出了CMM（软件过程成熟度模型），更是对于软件开发的过程管理，提出了确切的衡量指标。但是，近期的研究表明，仍有50%的项目会拖延交付，有30%以上的项目会超出预算，软件开发领域的项目情况比软件工程刚刚提出的时候相比，只是有很小的提高。分析项目失败的主要原因，大概有需求变更、沟通、技术能力、管理方法等方面的原因，但其中需求变更是导致项目没有按照预期完成而失败的最主要原因之一。所以如何处理好需求的变更将对项目的成败产生重要的影响。

3.1 需求变更的原因

3.1.1 问题域的复杂性越来越高。

在我国，从宏观上讲，正处于改革开放的历史时期，各行各业的体制改革正在热火朝天的开展，国家大力提倡管理创新和科技创新，因此，企业的各种标准、流程、事务都处于重组规范的过程中，因而系统需求的不明确、处于不断变化的状态也合情合理，导致问题域的复杂性越来越高。

3.1.2 交流障碍。

需求分析过程所涉及人员具备的背景知识不同，需求人员一般是以软件及其相关专业为主体的专业，而用户方是以自身业务为主体的专业的，他们考虑问题的角度不同，扮演的角色不同，认识上容易混淆，产生误解（自然语言的多义性，一语双关等），相互之间的交流存在一定的困难。

3.1.3 完整性问题。

因专业背景，技术等方面的原因，导致用户很难准确地把系统需求表达给需求分析人员，业务方面的局限导致开发方也很难准确获取客户方的真实的需求。这样的结果就导致用户对问题的陈述往往是不完备的，导致需求也是不完整的。

3.1.4 需求变动过多。

客户方对需求的重视程度不够，对自身业务的抽象程度不够，导致需求不够细化明确，对需求经常做变动，而需求的不断变更，导致后继工作不能按计划完成，从而影响整个系统的开发。

3.2 相应对策

软件需求变更是不可避免的，也是不可回避的，既然如此，就应该以正确的心态去面对它，解决它所带来的一系列问题。在进行软件需求分析的过程中，可以从以下几个方面来积极地应对需求变更。

3.2.1 思想认识上

好的软件产品取决于好的需求分析，而这是需要客户和开发人员之间的很好的交流和合作，因此，培养正确的需求意识是必要的，也是合作双方需要努力的，同时，开发人员更应该发挥积极主动的作用。

需求分析人员的思想意识：应对需求变化的意识，随着用户对系统需求的认识在不断加深和业务流程在不断变化，需求也在不断的增加、变化，这就需要需求人员正确对待用户需求的变化，运用新技术主动应对需求的不断变化。寻求用户支持的意识，因为不可能一次就完全了解用户的需求，而且在系统开发过程中还需要用户不断的参与到其中，因而寻求用户的支持是必须的。维权意识, 在系统的开发过程中，为了避免出现和减少与用户间的摩擦，合作的双方应该签订一份协议，在协议中明确规定双方应承担的责任和义务，在一定程度上减少双方之间的摩擦和随意的需求变更。

客户的思想意识：充分认识需求分析的重要性，认识到低质量的需求可能导致的严重后果，主动地参与需求分析。同时也要意识到由于技术、人力等资源的限制，计算机并不能解决当前存在的所有问题，并且软件产品的开发需要一定的时间，所以在向开发人员提出系统需求时，不能需求过多。最后，客户方还要有减少需求变化的意识，因为需求的变更，在一定程度上，会增加开发的成本和工期的延长。

3.2.2 项目管理上

需求调研前期的准备工作。在需求调研前将掌握的资料进行汇总，制定需求开发的计划，制定人员培训计划，对项目参与人员进行培训。

划定项目范围，拟定协议，明确项目的范围，有效地防止在开发过程范围不受控制的扩展，同时，要与客户方拟定一个协议，明确指出项目包括和不包括的特性和功能界线。

需求版本的控制。应该有专人负责需求文档的更新、管理、发布和版本控制等，组内每个成员必须能够得到当前版本，每一个公布的需求文档应该包括一个修正版本的历史状况，包括变更内容、日期和原因等。

3.2.3 技术支持上

当需求变更时，为了更好的适应需求的变化，需求人员可采用技术对策，比如：原型法、敏捷开发方法和软件复用技术等。需求人员还可以采用需求管理工具，需求管理工具有：CA公司的CA-Super Project&Project Software和Rational公司的Analys Studio等。

4、结束语

需求分析，在软件开发过程中是必须要面临的一个环节，由于自身的特点，软件需求分析过程中发生的变化也较多，如何有效的减少需求的变更，要求需求人员和客户方都要有正确的思想认识，在开发过程中积极合作，通过制定协议制定各方要承担的责任和义务，树立减少需求变更的意识，积极地采用新的技术支持来应对变更。需求分析文档要规范，合作的双方要精诚合作，分析和总结实践经验，努力提高技术水平，确保软件开发工作按照正确的方向进行，最终获得成功。

参考文献

[1].郑人杰殷人昆陶永雷.实用软件工程[M].清华大学出版社, 1997

[2].李师贤张珞玲.需求分析的常见问题及其对策分析[J].计算机工程, 2002, (1)

[3].陈宏烨赵文刚.基于软件开发的需求分析及需求管理[J].甘肃科技, 2008, (1)

软件项目的需求变更 篇5

软件的设计过程与迭代

在开发软件的过程中, 迭代是一个重要的风险源。因为软件体系内各个组件间的依赖关系十分复杂, 需求变更影响的传播, 让设计软件的过程必须不断重复、迭代设计:首先, 下游活动经常会因为上游活动过程的变化而不断重组或更改;其次, 在上游的活动需要下游活动进行信息反馈时, 上游活动就会因为下游活动的改变而重新进行设计;最后, 当下游活动因某些情况而不可用时, 基本都会导致相关活动的重做。所以要想减少不必要的迭代, 加强对设计活动的理解将是一个很好的方法, 同时这个方法, 还能帮助降低开发软件的风险。

对需求变更传播风险的评估需要确定的变更影响的波及范围, 而软件体系中的各种依赖关系则是进行分析的基础。传统的如PERT网、CMP等项目管理工具, 只能应用在平行与顺序结构的活动中, 是无法对迭代处理进行直接处理的, 而且对设计过程中的变化与重组也是不支持的。而DSM这种分析变更需求传播风险的工具, 不但可以将元素间复杂的依赖关系清晰的反映出来, 同时还可以将设计过程中的各种迭代与反馈都表示出来, 这种紧凑的形式对于可视化分析复杂系统来说是非常有利的。此外, DSM还能同时支持聚类或划分等算法的优化, 并且因为这些算法都是基于矩阵运算之上的, 所以更方便在计算机上进行操作。

DSM建模

DSM模型是一种通过n×n方阵像是来分析复杂系统并对其进行建模的工具。在DSM中, 各种组成系统的元素都通过相同的顺序排列在矩阵的第一列、第一行。对软件的体系结构进行分解, 使其成为一组相互关联的组件, 通过DSM模型对组件的依赖关系进行描述。对角线元素在其中并不是用来秒速系统关系的, 予以填充;而行与列间的关系, 则是每列中的元素对相应行中的元素的影响。对角线下的元素代表组件进行的正向前馈信息, 而其上的信息则代表逆向反馈信息。在进行软件设计时, 反馈信息的出现将会导致设计活动的迭代与反复, 进而致使工期延误与成本超支。

DSM模型不但可以将系统中的迭代与反馈都直观的表现出来, 同时还可以支持模块的重组, 并最大限度的消除反馈, 下图为某个较为简单的软件系统的DSM模型和划分结果:

在这一模型中, 组件B、C被组件A影响, 而组件A依赖组件C, 组件C与A之间是耦合关系。在进行划分前, DSM模型中有两个反馈信息, 在划分后就只余下一个反馈信息。因为组件C和组件A间的耦合关系, 是无法将反馈信息完全消除的。但是若将组件C与A当做一个整体, 两者间的耦合关系就成了内部关系, 而整个系统也就分成了{A, C}、{B}和{D}这三个模块, 这样也就消除了其中的反馈信息。而进行划分运算就是为了利用对系统组成元素的重组, 最大限度的将模块间反馈信息消除, 进而使设计迭代的风险得以降低。

分析变更传播风险的具体内容

从变更传播过程的角度来说, 变更传播就是从变更源头通过某些变更路径达到变更的目标。这种有变更传播而带来的风险不但会通过变更目标体现出来, 同时还和变更路径与源头有关。变更从某一角度来说, 变更目标的风险是由变更源与进行变更传播的实体来决定如何表现的。所以, 本文的观点是, 完整的变更传播风险在进行分析时应该包括以下几点:

在这些内容中, 变更传播风险值代表的是软件体系中潜藏与组件中的风险的大小。而变更传播所带来的影响则是变更源与参与实体能够对软件设计造成的整体影响结果。

变更传播风险有何含义

虽然软件需求的改变是确定, 但同时它也是不确定的。它的确定是因为在开发软件的过程中, 需求是一定会发生改变的。它的不确定指的则是发生变更的需求是哪些、发生变更的可能性有多大和这种变更会对软件系统造成怎样的影响, 这些都是不确定的。而这种不确定性也正是对需求变更风险进行评估的基础。

所谓风险, 指的就是在某中特定的危险情况到到来的后果及这种可能性的组合。本文的观点是, 变更传播风险是需求变更影响程度、传播概率的总和。软件的需求变更传播所带来的风险就可以化为两个方面, 即与影响性相关以及与发生可能性相关, 以下是相关定义:

第一, 所谓变更传播概率, 指的就是某一个组件在出现变更时, 和它有直接关联的其他组件也出现变更的可能性。

第二, 所谓变更影响概率, 指的就是当某一个组件所发生的变更直接通过某些途径传播到另一个组件时, 受到影响的组件必须重新进行设计的可能性。

第三, 所谓的变更传播风险, 指的就是变更传播概率及其影响概率二者的乘积。

在定义的第一条与第二条中, 都特别指出了“直接”影响, 而通过它们决定出来的变更传播风险, 即第三条定义中谈到的, 是直接变更传播风险。如果组件A的变更会对组件B造成影响, 但是却不会对组件C产生直接影响, 而组件B出现的变更却会对组件C造成影响。同时, 组件C和组件A间的那种间接性的变更储备风险则不再第三条定义中。

变更传播风险模型的应用

将DSM的变更需求传播风险分析模型当做基础, 向开发与管理软件项目提供一个评估风险的思路:

第一, 对于在开发软件初期无法得到的代码行与功能点等各种信息, 将软件体系结构当做载体, 将需求变更影响传播当做衡量标准来评估软件项目的风险, 这一点是与软件项目管理中越早进行风险评估越好的原则相符的。

第二, 从变更传播概率及其影响概率这两点上, 对变更传播的分析进行定义, 并研究那些被影响的实体。对每个组件中潜藏的风险值的大小进行评估, 并确定出该组件在传播的过程中所扮演的角色, 找到关键的风险源。

第三, 将设计迭代当做主要对象, 利用DSM的结构特征, 对变更源及其参与实体做进一步的研究。找出不同组件在传播变更的过程中所具备的特点, 并研究变更传播所造成的影响。

事实上, 软件变更需求的形式有三种, 分别为增加、删除以及修改。而本文提出的DSM模型, 只在分析特定软件体系的静态变更传播风险时能够适用, 一旦需求的变更改变了软件体系中的各种关系时, 就只能重新建立DSM模型再评估传播风险了。而这也正是此种方法的限制所在。

第一, 增加、整合、拆分组件。若需求的变更让原软件的体系中出现了由组件增加、整合、拆分而形成的新软件结构, 就需要建立新的评估风险的DSM模型。

第二, 删除组件。若原有组件因为需求的变更而被删除, 而在DSM模型中, 被删除的部分恰好是没有输出信息的组件, 那么就需要对其他有关组件做出相应的调整。反之, 则接受其输出信息的那些组件将会因此受到影响, 此时则需要就要重新对变更传播风险进行分析了。

第三, 修改组件。如组件的修改只是针对自身的某些结构或功能进行调整, 并且不影响其它组件与其的接口, 那么软件的体系结构就不会在组成上出现变化。

总结:

项目管理中的需求变更管理 篇6

关键词：项目管理,需求变更,变更七步法

一项调查表明, 大约70%的信息系统集成项目的软件开发项目超出了估算的时间, 大型项目平均超出计划交付时间20%至50%, 90%以上的软件项目开发费用超出预算, 并且项目越大, 超出项目计划的程度越高。软件开发不同于其他产品的制造, 软件的整个过程都是设计过程 (没有制造过程) ;另外, 软件开发不需要使用大量的物质资源, 而主要是人力资源;并且, 软件开发的产品只是程序代码和技术文件, 并没有其他的物质结果。基于上述特点, 软件项目管理与其他项目管理相比, 有很大的独特性。因此, 只有对信息系统集成项目实施科学规范项目管理, 才能规范项目需求、降低项目成本、缩短项目工期、保证信息工程质量。

1 对项目管理的认识和体会

经过这几年来参与及管理项目的工作, 认为要有效的实施项目管理, 可以从以下几个方面进行考虑。

首先要界定项目规模的大小, 大项目和小项目的管理方式不完全一样。但从另一个角度来看, 项目的大与小并没有本质的区别, 很多方法是共通的。总体而言, 大中型项目, 软件开发主要分为六个阶段:立项阶段、启动阶段、计划阶段、执行阶段、控制阶段及收尾阶段。小项目也同样分为六个阶段, 但比较模糊, 侧重点也不一样。

1.1 项目立项阶段

一般来说, 大中型的项目必须进行项目的可行性研究分析, 小项目根据实际情况进行可行性研究分析后, 才会对项目进行立项。很多项目在进行可行性研究时会出现很多问题, 如:研究深度不够, 质量不高, 不能满足决策的需要;不重视多方案论证和比较, 无法进行优选;调查研究得不够, 导致项目投资收益计算失真;可行性研究报告的编制缺乏独立性、公正性和客观性;等等。对此, 首先要正确认识可行性研究的阶段划分与功能定位。其次, 按要求进行可行性研究, 正确确定其依据。第三, 采用科学的方法与先进的技术。第四, 建立科学的决策体系和管理机制。

1.2 项目启动阶段

项目启动阶段需要界定工作目标及工作任务;获得老板或高层的支持;组建优秀的项目团队;准备充足的资源;建立良好的沟通。

项目管理中最重要、最难做的工作就是界定工作目标及工作任务, 也就是确定项目的范围。缺少正确的项目范围定义和核实, 是项目失败的主要原因。

对于组件优化的项目团队, 要根据公司管理的实际情况结合项目规模来进行组织, 如果是大中型项目, 存在许多跨职能部门的活动, 以矩阵型组织结构进行最有效。如果是小项目则以垂直方案成立一个专门的项目组。

建立一套良好的沟通渠道。每一个项目都有一系列的干系人, 对项目的成功都有影响, 项目经理必须通过沟通来控制这些影响。项目经理要对三个方面的人负责任, 一是客户, 让客户满意, 达成客户的目标;二是公司领导, 达成公司的目标;三是项目组成员。客户和管理层往往不能站在项目的总体目标上看问题, 项目经理则要使决定符合项目的总体目标, 因此要花时间沟通, 以项目的总体目标协调各方的关系并获得支持。

项目启动要召开项目启动会议, 项目启动会议主要是建立正式的团队, 提供团队成员的角色和职责, 提供绩效管理方法, 向成员提供项目范围和目标。项目启动还要召开针对客户的项目启动会议, 在这个会议上项目经理会与客户确立正式的交流渠道, 项目综合描述, 让项目参与人员相互了解, 建立以项目经理为核心的管理制度。

1.3 项目计划阶段

创建和维护定义了项目活动的计划, 核心是人力、时间、进度。

将项目分解为可管理的活动, 也就是我们通常所说的WBS。通过对项目的目的的理解, 确定工作主要分为哪几个部分, 自上而下将大的部分分解为下一个层次, 将每个构成要素再分解为子构成要素, 逐级完成, 直到能够分派作业并监测。通过WBS的使用, 使项目成本可以估算, 是项目各项计划和控制措施编制的基础和主要依据, 保证了项目结构的系统性和完整性, 可以建立完整的项目保证体系, 便于执行和实现目标要求, 为建立项目信息沟通系统提供依据, 便于把握信息重点, 是项目范围变更控制的依据以及项目风险管理计划编制的依据。

项目进度计划是确定每项活动的开始和完成时间。如果开始和完成时间不现实, 项目就不可能按进度计划完成。制定项目进度计划首先要对WBS中确定的可交付成果的产生所必须完成的具体活动进行定义, 得到活动列表;然后通过前导图法、箭头图法或关键路径法工具和技术将活动顺序进行安排, 决定活动之间的逻辑关系;接着利用类比法、专家估计法、基于WBS的子活动估计方法或量化估计方法对活动工期进行估算;最后依据上面提到的活动定义、活动排序和活动历时估算等数据的获得, 反复进行改进, 获得适合本项目的进度计划。

1.4 项目执行和控制阶段

一般来说项目的执行和项目控制和计划是紧密结合在一起, 特别是执行和控制。在执行过程中会有很多不可预见的因素在影响着计划的按期执行。如不可抗拒力、需求变更、人员变更、成本超支、项目延期、性能下降等等各种问题。这些在项目执行阶段出现的问题都必须通过控制阶段进行有效的控制和规避。

项目执行、控制阶段主要进行进度控制、成本控制和质量控制。

进度控制:

项目进度控制是依据项目进度计划对项目的实际进展情况进行控制, 使项目能够按时完成。有效的项目进度控制关键是监控项目的实际进度, 及时、定期的将它与计划进度进行比较, 并立即采取必要的纠正措施。其内容包括:对造成进度变化的因素施加影响, 确保得到各方认可;查明进度是否已经发生变化;在实际变更发生时进行管理;进度控制应和其他控制进程紧密结合, 并且贯穿于项目的始终。

成本控制:

项目成本控制是指项目组织为保证在变化的条件下实现其预算成本, 按照事先拟订的计划和标准, 通过采用各种方法, 对项目实施过程中发生的各种实际成本与计划成本进行比较、检查、监督、引导和纠正, 尽量使项目的实际成本控制在计划和预算范围内的管理过程。项目成本控制是以项目各项工作的成本预算、成本基准计划、成本绩效报告、变更申请和项目成本管理计划为依据;以成本变更控制系统、绩效测量、补充计划编制和计算机工具等方法进行的。

质量控制:

全面质量管理强调追求顾客满意、注重预防而不是检查, 强调管理层对质量的责任以及全员参与, 持续改进。质量控制是以工作结果、质量管理计划和工作定义及检测列表为依据;以检验、统计抽样、核对表、排列图、直方图、散点图、控制图、流程图、趋势分析和6δ管理法为工具进行的。

1.5 项目收尾阶段

项目结束时, 项目经理要将最终系统方案提交给用户, 完成项目所有的交付物, 收集项目全部信息并结束项目, 完成或终止合约, 签署项目结束的相关文件。

项目结束时, 依然要开会, 主要有七大主题:技术绩效、成本绩效、进度计划绩效、项目计划与控制、项目沟通、识别问题与解决问题、意见和建议。同时也要总结经验教训。

项目团队得到客户满意评价的最好方式, 是向客户提交一份项目满意程度调查报告, 从客户那里得到好的反馈, 作为公司项目成功完成的案例证明。

2 实际项目中遇见的问题和解决办法

在实际工作中经常遇见有关需求管控方面的问题, 特别是电信门户网站的项目中和综合业务支撑系统的项目尤为突出, 这两个项目分别体现了需求管控的不同方面。

在电信门户网站项目的建设之初, 电信公司提出了一个整体的网站建设构想, 涉及的面很广并且关键功能是需要和电信的BSS域和OSS域的相关生产系统有交互, 功能比较复杂。同时要求的工程时限又非常的紧。鉴于这种情况, 组织项目组的相关成员进行了需求讨论, 并结合电信公司对时限的要求。决定将这个整体的网站建设构想分为一期和二期, 将电信公司比较紧迫的需求列入一期, 其他部分的需求列入二期。同时, 在需求分析中发现, 其提出的部分需求与电信集团公司下发的CTG-MBOSS的规范以及省级规划有冲突。如积分计算、管理、发布要求在网站实现, 但实际积分管理在省级的规划是在BSS域中的计费系统实现。在与电信公司再次沟通中, 为了保证工程进度, 他们同意了我们提出的分二期建设的建议;但是对于我们提出的部分需求和上级规范冲突的问题, 他们尽管确认了该需求确实有冲突, 但还是要求我们必须按照要求实现。为了规避这部分的需求风险, 我们在进行概要设计的阶段, 特别考虑了这个问题, 一方面按照电信公司的要求设计了积分管理的整个功能架构, 同时开发了与计费的接口模块。随后, 项目正常进行, 直至一期上线。在上线后三个月, 省级的计费系统中的积分管理功能启用, 上级电信公司发文要求所有的积分计算要以计费为准, 鉴于在作系统架构设计的时候考虑到了这个风险, 预留了接口, 所以只进行了很小的接口调测工作就顺利的完成了此次变更。一个月后, 电信公司决定在五·一期间开展“短信文学”和“七彩铃音”原创大赛、“电信·宽带专家”杯原创FLASH设计大赛活动, 需在电信门户网站设置活动专栏。并明确提出了具体的活动内容和功能需求。其中在“七彩铃音”部分有个关键需求是“作品定制功能”, 要求能够通过网站或短信可将作品定制为铃音。由于原来的网站系统架构中并没有与之对应的功能。经过对对端系统的业务了解, 发现所有的铃声都必须上传至特定的彩铃网站的服务器上, 在统一由该网站更新至彩铃平台。并且由不能确保所有的用户都申请了彩铃业务, 还需要和业务支撑系统进行交互, 并替没有彩铃业务的用户申请彩铃业务后, 才能实现作品定制功能。如果要做成这样一方面业务流程极其复杂, 开发工作量极大, 必然无法在要求的时限内完成;另一方面这些彩铃作品对彩铃平台造成了非常大的压力, 可能会影响彩铃平台的正常运行。在与电信公司的沟通中我们明确提出了该需求存在的这些问题, 同时也提出了一个变通的建议:将“作品定制功能”改为大赛结束后, 将上榜作品批量更新到彩铃平台, 再由用户通过彩铃网站, 按照自己的喜好进行定制。这样就可以规避这些问题, 同时也保证了比赛的正常进行。电信公司最终采纳了这个方案。

综合业务支撑系统对于电信公司来说是一个非常重要的生产系统。在做二期工程的时候, 尽管说做了五个月的需求调查工作, 形成了3000多页的需求文档。但是在二期工程分阶段分模块逐步上线, 原有的一期系统还在继续使用的同时, 出现了非常多的需求和故障, 内容几乎涉及到一期及二期的所有方面。重要的需求和故障无法跟踪, 大量的需求被延误。需求几乎到了无法控制的边缘。为了改变这种被动局面, 加强对需求管控, 我们上了一套问题跟踪系统, 将所有的需求、故障都放到这个平台上进行流转。并规范了故障处理流程、需求处理流程、测试流程、发布流程等等一系列的业务流程。通过这个平台和这些流程, 将一期的正常运维需求和二期的开发需求进行了分离, 保证了一期的正常运行。由于在流程中增加了审批环节, 避免了一些无效的需求;同时对合理的需求进行了统一的规划和安排, 降低了大量需求对正常开发进度的影响;对于重要的需求可以进行跟踪;很容易的了解每个成员的工作负荷, 进行有效的调整和均衡。通过这套系统也提高了客户的满意度, 使得二期项目得以有序进行。

总的来说在电信门户网站项目中比较成功的对需求进行了一定的掌控, 避免了需求的冲突和需求变更引发的项目风险。主要归功于了解了电信的CTG-MBOSS的规范和省级电信公司的IT建设的规划, 才能在跟客户进行有效沟通的前提下做好需求管控。在综合业务支撑系统中由于没有预计到需求变更的频繁, 导致需求几乎失控, 但通过问题跟踪系统和各种业务流程保证了需求变更的可控, 也提高了客户的满意度。

3 如何进行需求变更管理

通过此次过程对需求变更管理有了更深刻认识, 尽管说很多需求变更管理的方法在实际工作中都得到了的应用和体现。但是整体的思路还是得到了进一步的梳理, 特别是教授的“变更七步法”及其相配套的表格, 更是体现了变更控制的思想, 可以在日后指导项目管理中的工作。

第一步:先把理由说清楚

(1) 客户提交的变更必须基于书面形式。

(2) 客户提交的变更必须有充分理由。如果变更被拒绝, 对业务的负面影响;如果变更被接受, 对业务的正面影响。

第二步:能否实现做评估

(1) 从实现的方式上考虑新的变更是否可以实现。

(2) 在这里不需要考虑代价。

第三步:可以实现看进度

(1) 进度几乎是绝大多数项目的第一要素。

(2) 要考虑对活动级别的影响。

第四步:变更成本要算足

(1) 人员相关的变更成本。

(2) 是否需要额外的成员。

(3) 项目组需要增加的工时。

(4) 要考虑非人力成本的投入。如软、硬件、资料等。

第五步:资料不得有马虎

(1) 变更对质量的多方面影响。

(2) 分阶段影响 (需求、设计、编码、测试、维护) 。

(3) 对项目的可靠性、安全性、可维护性、可用性的影响。

第六步:评完TQC (时间、质量、成本) , 风险再细分

(1) 可能对团队士气的负面影响。

(2) 可能引发的间接任务对工期的负面冲击。

(3) 开发方的成本负担可能超出力所能及的范围。

(4) 客户避免成为强力“IT杀手”。

第七步:主意请大家拿

(1) 前面六个步骤分别由不同的角色做出, 而是否接受变更要请大家评判。

(2) 要考虑变更粒度、组织规模、业务模式、项目特点等。

结合目前我公司所承接电信行业软件项目的特点。认为除课堂上教授的“变更七步法”外, 还要考虑电信行业的特点, 不管是做BSS还是OSS项目的, 都必须首先遵循《中国电信CTG-MBOSS规范》, 再考虑省级电信公司的IT建设的滚动规划, 再结合电信公司的实际需求。在项目签订合同之初就要将项目管理中的各种流程, 特别是需求变更流程以合同附件的形式纳入到合同中, 这样就可以在发生变更的时候就可以有一个明确的流程来进行管控。才能应对电信行业频繁变化的需求, 保证项目的正常进行。

参考文献

论软件项目需求管理 篇7

关键词：软件项目,需求工程,需求开发,需求管理

1. 软件项目需求管理的概念

软件项目需求管理是指软件项目的开发团队了解、挖掘用户的“需要”, 对这些“需要”进行系统有效的跟踪、管理, 最终通过软件将这些“需要”实现, 满足用户期望的过程。软件需求来源于用户的需要和期望, 这些“需要”被清洗、梳理、分析、抽象、整理后形成文档, 详细地说明了软件产品“必须做什么”或“应当做什么”, 是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。

2. 软件项目需求工程与管理

2.1 软件需求的层次与组成

软件项目需求工程是一个系统工程, 在实际开发过程中, 需求可分为4个层次:

原始问题:用户口头、书面提出的要解决的问题, 它是软件需求的基础;

用户需求:开发团队用自然语言、图表给出的, 软件系统将要提供的服务及操作的约束;

系统需求:是用户需求的映射, 可通过软件原型给用户一个直观印象, 并在此基础上开展下一步的工作;一般算法较简单的软件采用水平原型, 需要体现复杂算法的则用垂直原型;

软件设计描述:以上三个层次说明了“做什么”, 这个层次则说明“如何做”, 是软件详细设计和实现的基础。

在了解以上4个层次的基础上, 我们就可以进一步理解软件需求工程的组成:需求开发和需求管理。

2.2 需求开发

(1) 需求捕获

需求捕获是需求工程的主体, 它描述了用户通过软件系统需要完成的任务。改过程归纳、整理了用户提出的各种问题和要求, 厘清用户希望通过软件达到的目的, 并使用工具和方法描述用户提出的实际需求, 以界定软件的作用范围, 最终弄明白要“做什么”。

实施需求捕获首先要确定用户类型, 寻找每一类型用户的涉众代表及需求的决策者。需求捕获的方法有:理解用户单位的组织架构;调查各部门的业务活动;与用户交谈;向用户群体发放调查问卷;分析用户工作流转的表单、文件;参观用户的工作流程, 观察用户的操作;召集用户代表会议;场景实例分析;跟班作业等。建议在捕获前需求管理人员应事先建立一份基本词汇表, 其中主要描述用户行业的专业术语, 包含了一些用户日常工作的基本流程及其解释。这样做的好处, 一是给用户一个良好的第一印象, 让用户认为你很专业, 对你很放心, 双方有更多的共同语言;二是能帮助项目开发团队正确领会用户相关干系人的意图。

(2) 需求分析

需求分析是指在需求开发过程中, 对所获取的需求信息进行分析, 及时排除错误和弥补不足, 弄清楚问题的要求。确保需求文档正确地反映用户的真实意图。需求分析方法大体有两类:一类是常识性的方法, 简单易用, 另一类技术性很强, 在此不做讲解。

(3) 需求规格说明书

需求规格说明书 (SRS) 用以描述用户需求和系统需求。SRS不仅要正确地反映用户的真实意图, 而且用词应该简单明了, 清楚易懂, 尽量使用前文提及的基本词汇表中的语言, 另外还应该力求全面具体, 具有可操作性与可验证性, 只有这样的需求规格说明书才能最终帮助我们进行科学的需求管理。

(4) 需求验证

需求验证目的是为了确保SRS准确、完整地表达了必要的质量特点。此时, 应会同用户方的决策、业务、技术人员一起验证, 其目的有二:一是让用户了解、明白SRS是否正确地描述了他们的需求;二是通过此文档, 确保需求提出者与需求分析人员、开发人员、测试人员及其也干系人对需求达成共识, 并把需求固化, 作为基线, 控制用户在需求方面的变更。验证的内容有:审查SRS、测试用例、测试覆盖、产品验收标准等是否与用户需求一致、完备。

2.3 需求管理

(1) 变更管理

用户需求变更在项目实施过程中是永远存在的, 但客户并不永远是对的, 也就是说需求变更要加以正确的管理和控制。如何对需求变更进行管理呢?

首先, 要对需求变更进行分类, 区别对待。一类是关键性变更, 它影响到项目的正常交付使用, 这种需求是必须满足的;二是改良型变更, 它不影响系统的交付, 但如果不被满足会令整体项目工作的价值下降。

其次, 所有的变更必须通过变更控制流程实现, 绝对不能因为变更范围小、容易实现, 或碍于面子, 就随口答应, 或不通过配置管理就进行随意改动, 有时一个小小的变更就会导致项目的失败。

(2) 版本控制

版本控制用于跟踪记录整个软件的开发过程, 包括软件本身和相关文档。通过版本控制在空间上可以保证配置项的集中管理, 解决一致性和冗余问题, 让版本具有可回溯性, 它不仅是开发团队并行开发、提高开发效率的基础, 也是管理需求变更的手段。

(3) 需求跟踪

需求跟踪建立和维护了从用户需求 (包括变更的需求) 到测试的一致性与完整性, 即建立“需求-设计-编码-测试”之间的一致性, 确保所有的工作成果符合用户需求。

3. 几种需求管理工具

一个好的工具可以让需求管理工作事半功倍。这里我推荐几种管理系统:Rational Requisite Pro:集成易用的需求管理工具;IBM Rational DOORS:老牌的需求管理套件;Cloudtopo Topo:国产需求管理平台;Visual Source Safe:一个常用的、易上手的配置管理 (版本控制) 软件;

需求管理是软件项目开发工作的一个重要领域, 关系到整个项目的成败与质量, 尽可能准确的获取客户需求, 尽量一次做对, 编写出高质量的SRS, 加强需求管理, 有效防范和减少不必要的需求变更, 跟踪、控制需求在整个软件开发生命周期中的作用, 努力降低因需求变更对项目的范围、成本、质量和进度造成的影响。

参考文献

[1]万文杰, 李振中, 任伟, 高瑞年, 卢旭.探析软件开发中的项目需求管理[J].电脑编程技巧与维护, 2010, 10.