7-软件需求管理【荐】.ppt

软件需求管理 需求工程 需求开发活动 确定产品所期望的用户类别。 获取每个用户类别的需求。 了解实际用户的任务和目标以及这些任务所支持的业务需求。 分析源于用户的信息,以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。 需求开发活动（续） 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 了解相关质量属性的重要性。 商讨实施优先级的划分。 将所收集的用户需求编写成规格说明和模型。 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。 1. 需求管理活动 CMMI中需求管理的流程图 1.1 版本控制 需求文档的每一个版本必须被统一确定。 组内每个成员必须能够得到需求的当前版本。 必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。 为了尽量减少困惑、冲突、误传，应仅允许指定的人来更新需求。 需求的属性 创建需求的时间 需求的版本号 创建需求的作者 负责认可该需求的人员 需求状态 需求的原因或根据（或信息的出处） 需求涉及的子系统 需求的属性（续） 需求涉及的产品版本号 使用的验证方法或接受的测试标准 产品的优先级或重要程度（例如高、中、低或） 需求的稳定性（在将来需求可能变更的指示器，不稳定的需求意味你应给予较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程。） 建议的需求状态表 状态跟踪示例 1.2 需求变更管理 应仔细评估已建议的变更?。 挑选合适的人选对变更做出决定。 变更应及时通知所有涉及的人员。 项目要按一定的程序来采纳需求变更。 控制项目范围的扩展 扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。 问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较大的影响。 要是每个建议的需求都被采纳，对于项目出资者（sponsor）、参与者与客户来说项目将永远也不会完成—事实上，这是不可能的。 控制项目范围的扩展 对许多项目来说，一些需求的改进是合理的且不可避免。 业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更的，管理部门也会决定对项目做出一些调整。 在你的项目进度表中应该对必要的需求改动留有余地。 若不控制范围的扩展将使我们持续不断地采纳新的功能，而且要不断地调整资源、进度、或质量目标，这样做极其有害。 管理范围扩展 管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部分。 评估每一项建议的需求和特性，将它与项目的视图和范围相比较决定是否应该采纳它。 强调客户参与的有效的需求获取方法,能够减少遗漏需求的数量，只在做出提交承诺和分配资源后才采纳该需求。 控制需求扩展的另一个有效的技术是原型法，这个方法能够给用户提供预览所有可能的实现，以帮助用户与开发者沟通从而准确把握用户的真实需求。 要敢于说“不”。 变更控制策略 所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。 对于未获批准的变更，除可行性论证之外，不应再做其它设计和实现工作。 请求一个变更不能保证能实现变更，要由项目变更控制委员会（ C C B）决定实现哪些变更。 项目风险承担者应该能够了解变更数据库的内容。 绝不能从数据库中删除或修改变更请求的原始文档。 每一个集成的需求变更必须能跟踪到一个经核准的变更请求。 简单变更控制步骤模板 绪论 目的 范围 定义 角色和责任 变更请求状态 开始条件 变更管理活动中可能的项目角色 变更控制委员会的组成 产品或计划管理部门。 项目管理部门。 开发部门。 测试或质量保证部门。 市场部或客户代表。 制作用户文档的部门。 技术支持部门。 帮助桌面或用户支持热线部门。 配置管理部门。 常见变更请求数据项 变更需求状态转换图 测量变更活动 接收、未作决定、结束处理的变更请求的数量。 已实现需求变更（包括增、删、改）的合计数量（也可以用在基线上占需求总数的百分比来表示）。 每个方面发出的变更请求的数量。 每一个已应用的需求（是指已划过基线）建议变更和实现变更的数量。 投入处理变更的人力、物力。 影响分析报告模板 1.3 需求跟踪 一些可能的需求跟踪能力联系链 RequisitePro Project Organization Working in a View Existing Artifacts for RU e-st Project Create a Requirement in the Explorer or in a View Requirements and Associated Documents