需求风险控制
一般来说，软件工程项目的需求就是指用户使用此软件可能实现某个目标的能力。需求分析的任务就是解决“做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求。从历史经验来看，在软件工程项目中，需求分析工程师在与用户交谈中，发现用户对新系统的需求。
在一些情况下，大开发商拥有自己的分析团队，这些分析团队一般都对软件非常了解，但对专门商业软件或某行业的业务知识知之甚少。一位软件需求管理专家说，分析团队需要能问恰当问题的人，而商业领域的知识对提问题非常有用。
在凯泽永久，许多项目遭受最新的变革、成本超限或错过完成日期，这一切都不是新鲜事情。而且，凯泽永久的项目规模通常都很大，如果在项目快完成的时候发现问题，就会对项目完成时间和成本产生巨大的影响。与此同时，一些启动迟缓的项目，在后来整个过程中都运行得很好。
Schleifer说，凯泽永久已经意识到，需要提高软件项目开发程序的质量，并按时完成，减少成本支出。他认为，急着去做编码的工作，还不如先仔细调查需求。同时，新启用的需求管理软件，可以对需求获取、需求数据库、软件变更和配置管理系统做一个全面的管理，控制需求方面各种潜在风险。使用需求管理软件中的需求定义工具，还可以让需求分析师和业务部门共同来创造和改变需求。
Schleifer和他的同事分析了需求分析上的一些潜在问题。他发现，没有足够业务部门人员参与是最大的问题。经常，业务部门不明白为什么收集需求和确保需求质量需花费那么多功夫，而开发人员可能也不重视用户的参与。Schleifer还发现，需求本应该送到管理者那儿签字，但管理者并没有看到具体细节。
究其原因，是因为一些开发人员认为，与业务部门合作不如编写代码有意思，还有开发人员了解了表面的需求时，就觉得已经明白用户的需求了。对此，Schleifer认为，既使客户也不太明白自己的真正需求，还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。Schleifer还决定，要使用新的需求管理软件，确保开发人员、测试人员能够明白需求的细节。
凯泽永久的开发团队碰到的第二个大问题是，用户需求的不断增加，不断变化。在开发过程中，经常有部门不断地补充需求，使项目就越变越庞大以致超过其计划及预算范围。实际上，这个问题根源在于用户需求的改变和开发者对新需求所作的修改。甚至还有业务部门认为，不再加点什么功能就对不起自己。有的项目在设计阶段没有很好地定义范围，当开发人员向项目管理者提出这个问题时，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，业务部门提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断接到投诉说项目失败。
为把需求变更范围控制到最小，凯泽永久使用需求管理软件对项目视图、范围、目标、约束限制和成功标准给予规范，同时使用软件对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。
再一个困扰凯泽永久的问题是模棱两可的需求。模棱两可是需求规格说明中最为可怕的问题之一，它的一层含义是指诸多开发人员对需求说明产生了不同的理解，另一层含义是指单个开发能用不止一个方式来解释某个需求说明。模棱两可的需求会使不同的项目风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。凯泽永久的一位系统测试人员说，由于测试组成员对需求理解有误，以致不得不重写许多测试用例并重做许多测试。这需要不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，那时再发现的话会使得更正代价很大。
<<上一页
1
2
3
下一页>>
