《软件过称管理》课程设计报告
是“批准的”。 在当前打算的实施中加入需求，并且更新建议，反映这一变更。该需求状需求已经在需求说明书中被批准 态变成“提交的”。变更在项目计划和产品中交付
可以看出，采用需求状态数据库能够很方便的管理需求变更所引起的某一需求所处的阶段及最后是否实施的情况。
4.6 需求管理复杂性分析
软件需求是整个软件开发项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：
1、需求的描述问题。缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。
2、需求的完备程度问题。需求如何做到没有遗漏？如何准确划定系统的范围？这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。
3、需求开发的工期问题。在需求上花费了大量的时间，客户、软件公司是否能够忍受？为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已！他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。
4、需求的细致程度问题。需求到底描述到多细，才算可以结束了？仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的
- 9 -
《软件过称管理》课程设计报告
共性提取要求越高，所以只要大家（客户、用户、需求分析人员、设计人员、测试人员）认为描述清楚了，就可以进入设计阶段了。
5、需求的变化问题。在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。
需求变化的原因很多，如：
·一开始没有识别全，需要增加需求； ·业务发生了变化，需求必须变化； ·需求错误； ·需求不清楚。
需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办？管理它！使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变（Project Scope Creep）问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。
4.7 需求管理策略
需求管理需要遵守以下策略： 1、需求一定要与投入有必然的联系。
需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。但是，接受需求变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。
2、需求的变更要经过出资者的认可。
需求的变更引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更
- 10 -
《软件过称管理》课程设计报告
修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。
3、小的需求变更也要经过正规的需求管理流程。
小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。
4、精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义的越细，越能避免需求的渐变，这是2个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更精致，于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。
基于上述的问题，必须对需求进行管理，使需求能够真正成为软件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持一致，使需求可以复用。
- 11 -
《软件过称管理》课程设计报告
5 目前需求管理的现状及存在问题
一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢?当它真正在实际项目实施时，困难就暴露出来了。对开发人员、 经理和质量保证人员所做的一次调查结果。显示了经历过最常提到的需求相关难题的受访者比例。常见的需求问题：无法跟踪变更7 1 7 6 ，难以编写7 0 ％，特性偏移6 7 ％，组织欠佳 5 4 ％ 。
下面列出了更多与需求有关的问题 需求不总是显而易见的，而且它可来自各个方面；需求并不总是容易用文字明白无误地表达；存在不同种类的需求，其详细程度各不相同；如果不加以控制，需求的数量将难以管理；需求相互之间以及与流程的其他可交付工件之间以多种方式相关联；需求既非同等重要， 处理的难度也不同；需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理；需求发生变更；需求可能对时间敏感。当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时，许多团队都对管理好需求不抱希望了。
- 12 -
《软件过称管理》课程设计报告
6 结束语
软件工程管理的核心思想是：有效地对软件开发整个过程进行合理地规划和控制，到在用户可接受的软件功能、可靠性、 性能等前提下尽可能的低成本、 低风险和较高的效率完成软件开发。
从多年开发软件的实践来看，凡是重视软件管理并按规范进行的开发，软件开发周期短，软件可用性强，软件可靠性高，用户界面好。反之，不是拖延进度，不了了之，就是可用性和可靠性差，不受用户欢迎。实践表明，提高软件可靠性和可维护性，促进软件工程化管理，需要广大软件开发人员和管理人员转变观念，以现有的起点为基础，脚踏实地、真抓实干。
- 13 -
《软件过称管理》课程设计报告
参考文献
[1] B o b H u g h e s ,M i k e C o t t e r e l 1 ．S o f t w a r e P r o J e c t M a n a g e m e n t [ M ] .北京：机械工业出版社 ,2004 ．
[2] 赵晓亮.浅议软件工程管理[ J ].科技情报开发与经济，2002第12卷 第5 期 ． [3] 黄卓. 软件工程管理方法的探讨[ J ].辽宁师专学报，2003年第 5卷第3 期 ． [4] 软件工程管理——s E M 推进中国信息化发展[ J ] .软件世界，2004年第2期． [5] 郝滨滨.软件工程管理方法与实践[ J ].舰船电子工程,2004年第4期．
- 14 -