cmmi 需求管理.pptVIP

Requirement Management 软件项目管理中的共同问题 目标被误解 定义很差的需求 不切实际的目标 没有很好的任务计划 没有充分的技能或资源 通信效率低下 缺少变更控制 组间冲突 缺少足够的文档 需求需求需求。。。。 需求需求需求。。。 软件需求的问题 Boehm发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个错误要多付出6 8倍的成本。 近来很多研究表明这种错误导致成本放大因子可以高达2 0 0倍。 软件需求的定义 IEEE软件工程标准词汇表(1997) (1) 用户解决问题或达到目标所需要的条件或能力(capability)。 (2) 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。 (3) 一种反映以上(1)或(2)所描述的条件或能力的文档说明。 角色 客户 出资支付项目或者项目最终产品的人。通常意义下，客户是指直接或间接从产品中获得利益的个人或组织。软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者或是获得产品所产生的结果的人。 用户 以某种方式使用系统，因此必须从实际使用的观点理解系统的任何项目有关人员。 客户不一定是用户。 需求的层次 需求的层次概念 业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求(user requirement)文档描述了用户使用产品必须要完成的任务，这在用例(use case)文档或方案脚本说明中予以说明。 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。 一个字处理程序的例子 业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。 而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。 同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。 不合格的需求 没有足够用户参与 用户需求的不断增加 模棱两可的需求 不必要的特性 过于简单的规格说明 忽略了用户分类 不准确的计划 优秀需求具有的特性－需求陈述的特征 1. 完整性 2. 正确性 3. 可行性 4. 必要性 5. 划分优先级 6. 无二义性 7. 可验证性 优秀需求具有的特性－SRS的特征 1. 完整性 2. 一致性 3. 可修改性 4. 可跟踪性 需求工程域的层次分解 需求管理 软件客户需求权力书 1. 要求分析人员使用符合客户语言习惯的表达。 2. 要求分析人员了解客户系统的业务及目标。 3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。 4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。 5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。 6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。 7. 描述产品使其具有易用、好用的特性。 8. 可以调整需求，允许重用已有的软件组件。 9. 当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估。 10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。 软件客户需求义务书 1. 给分析人员讲解业务及说明业务方面的术语等专业问题。 2. 抽出时间清楚地说明需求并不断完善。 3. 当说明系统需求时，力求准确详细。 4. 需要时要及时对需求做出决策。 5. 要尊重开发人员的成本估算和对需求的可行性分析。 6. 对单项需求、系统特性或用例划分优先级。 7. 评审需求文档和原型。 8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。 9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。 10. 尊重需求工程中开发人员采用的流程（过程）。 需求管理 需求管理的原则和实现 建立需求基线 控制对需求基线的变更 保持项目计划与需求一致 控制单个需求和需求文档的版本情况 管理需求和联系链之间的联系或管理单个需求和其他项目可交付产品之间的依赖关系 跟踪基线中需求的状态(已实现、已验证、已删除等) 管理需求变更请求 应该仔细评估已建议的变更 挑选合适的人选对变更做出决定（CCB） 变更应及时通知相关小组和个人 项目要按照一定的程序来采纳需求变更 需求的跟踪 IEEE为可跟踪性提供的定义： “在开发过程的两个或多个产品之间能够建立关系的程度，尤其是某产品与其他产品之间前任及后续