作者：吴艳艳 周长伦 姜家轩 王春梅 许自国

企业的发展，工作过程重组，需求变更已愈来愈成为必然。软件危机持续了30年之久，至今仍无法得以很好地解决。究其原因，软件本身具有的特点固然有关，但长期以来，缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制乃是最为关键的原因。其中软件开发和维护方法的不正确性主要体现在:忽视软件开发前期的需求分析;开发过程缺乏统一的、规范化的方法论的指导;文档资料不齐全或不准确;忽视与用户之间、开发组员之间的交流;忽视测试的重要性;不重视维护或由于上述原因造成维护工作的困难。
这样，就经常出现用户对“已完成”系统不满意，软件产品的质量经常出现漏洞，补丁一大堆。因此人们意识到以工程化的原则和方法组织软件开发工作是解决软件危机的一个主要出路。
需求分析作为软件生命周期的第一个阶段，并贯穿于整个软件生命周期，其重要性越来越突出，到20世纪80年代中期，逐步形成了软件工程的子领域—需求工程。进人20世纪90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会(isre) ,1994年起，每两年举办一次需求工程国际会议(icre)。一些关于需求工程的工作小组相继成立。
3存在的问题
3. 1需求描述的细致性问题
在文章的开头就说明了软件需求在整个软件系统开发中的重要性，正是由于它的重要性，一般来说，需求描述越详细越好。LocaLhoSt项目的开发方与用户在各种问题上的要求都是基本轮廓达到一致即可，具体的细节可以以后再填充，这是一种非常危险的思想。不管需求分析做的多么细致，以后对需求的变更都是必然的。另一方面，在需求分析阶段，开发人员希望再多投人一些时间，但是用户却不这么认为，因为需求阶段是软件系统开发首先要进人的阶段，离最终开发出可用的系统还有很长一段距离，这导致了双方的不一致。但如果在需求阶段投人很多时间，时间越长，可能的变化就越多，对设计的限制越严格，因此在需求描述的问题上，没有统一的界定，需要开发人员学会适当的把握。
3.2需求描述的正确性
软件开发是一种专业行为，一般的业主难以理解软件开发人员的开发理念。所以在和业主交流时，他们讲述的需求在实际中利用现有的技术是实现不了的，用户以为自己很清楚自己的需求了，但实际上他们只是依据当时的工作需求提出的。随着开发工作的不断进展，用户可能想到更多的功能和特色，进而对以前的需求进行改动，导致需求的不一致。
另外一种情况就是开发人员和业主交流时，由于业主本身对需求的描述不清晰，导致开发人员误解或曲解了业主最初的要求，最后开发出来的系统不是不能满足用户，就是一个发生需求错误的系统。事实上这种错误在需求阶段也会经常发生。更可怕的是，对于需求阶段出现的错误，如果在软件项目进行到后期的时候才发现，修复费用是非常可怕的，甚至会超出项目本身的费用。因此做好需求管理、减少需求错误的出现对于降低软件项目的成本是必要的，也是至关重要的。
3. 3需求描述的完备性
系统的需求是层出不穷的，我们不可能做到把所有的需求都一一列举出来，并且随着时间的推进，用户的需求也会越来越多，要穷举需求是不可能做到的。另外，并不是用户提出的所有需求都要满足，在项目的最后，改变一个需求对整个项目的影响或损失很可能会超过需求本身给用户带来的益处。
3. 4需求的变更
需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办?管理它!使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变(project scope creep)问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定程度时，双方才蓦然回首，发现已经物是人非，换了一番天地。

4解决问题的策略
4. 1对需求文档版本控制
客户签收的所有过程文档都要作为基线确定下来，做好相关文档的管理工作。需求的基线是指是否容许需求变更的分界线，需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档，这个需求文档在通过需求评审后即可以建立第一个需求基线。此后每次需求变更并经过需求评审后，都要重新确定新的需求基线，以免将来用户需求发生变更时，原来的需求无法查找。为有效进行需求变更控制，必然要做的工作就是保存好各个版本的需求基线，维护需求基线文档，以备不时之需。
4. 2正确认识需求变更
在软件开发过程中有这样一条真理:需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是一个变化的过程，需求的变更不一定是坏事，也有可能是好事。
变更的需求之所以变得难以管理，不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性，而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构，使它能适应变更，并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线，确定需要追踪的重要依赖关系，建立相关项之间的可追踪性，以及变更控制等活动。
需求变更贯穿了软件项目的整个生命周期，通过建立规范的变更控制流程，改进软件分析与设计，把变化纳人计划之中，在应对需求变更时可以更加的从容和有信心。
4. 3管理需求变更
变更控制不应该只是软件开发过程应该考虑的事情，随着软件产品的开发和

[1] [2] 下一页