项目计划之范围计划(需求管理）.pptVIP

RoadMap

软件项目管理本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法四、案例分析什么是软件需求？IEEE软件工程标准词汇表（1997年）中定义需求为：（1）用户解决问题或达到目标所需的条件或权能（Capability）。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档条件或权能。（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。宽泛地讲，需求来源于用户的一些“需要”（欲望），这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。什么是软件需求？在RUP中定义了需求工作流程的工作目的：客户和其他涉众在系统的工作内容方面达成并保持一致。使系统开发人员能够更清楚地了解系统需求，定义系统边界（限定）。为计划迭代的技术内容提供基础。为估算开发系统所需成本和时间提供基础。定义系统的用户界面，重点是用户的需要和目标。什么是软件需求？需求的重要性FrederickBrooks在他1987年经典文章“NoSilverBullet”中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。不当的需求过程引来的风险：用户不多导致产品无法接受－－－应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。用户需求的增加带来过度的耗费和降低产品的质量。－－要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。不当的需求过程引来的风险：模棱两可的需求说明可能导致时间的浪费和返工。－－处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，那时再发现的话会使得更正代价很大。不当的需求过程引来的风险：用户增加一些不必要的特性和开发人员画蛇添足(gold-plating)。－－应确信：你明白为什么要包括这些功能，以及这些功能的“来龙去脉”，这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能。过分简略的需求说明以致遗漏某些关键需求。－－这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况（McConnell1996）。但在大多数情况下，这会给开发人员带来挫折（使他们在不正确的假设前提和极其有限的指导下工作），也会给客户带来烦恼（他们无法得到他们所设想的产品）不当的需求过程引来的风险：忽略某类用户的需求将导致众多客户的不满。即：忽略了用户分类!－－大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难。不准确的计划－－对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。要作出估计时，最好还是给出一个范围（如最好的情况下，很可能的，最坏情况下）或一个可信赖的程度（我有90%的把握，我能在8周内完成）。未经准备的估计通常是作为一种猜测给出的，听者却认为是一种承诺。因此我们要尽力给出可达到的目标并坚持完成它。不当的需求过程引来的风险：不完善的需求说明使得项目计划和跟踪无法准确进行。需求规格说明的特点：1.完整性－－不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用TBD(“待确定”