需求管理流程

需 求 分 析 过 程
（1）对系统的综合要求：
功能要求:包括系统应该实现的功能； 性能要求:包括系统响应时间、资源限制、 数据精确性、系统适应性等； 运行要求:包括系统硬件环境、网络环境、
系统软件、接口等的具体要求；
其他要求包括：安全保密、可靠性、可维护 性、可移植性、可扩展性等等。
需 求 分 析 过 程
分析（需求分析和谈判）
规定（规约） 系统建模 验证（需求确认） 需求管理（控制与变更管理）
需 求 管 理 存 在 的 问 题
1. 2. 3. 4. 5. 6. 7. 8. 9.
需求不总是显而易见的，它可来自各个方面。 需求并不总是容易用文字明白无误地表达。 存在不同种类的需求，其详细程度各不相同。 如果不加以控制，需求是无止境的，需求数量 将难以管理。 需求相互之间以及与流程的其他可交付工件之 间以多种方式相关联。 需求既非同等重要，处理的难度也不同。 需求涉及众多相关利益责任方，这意味着需求 要由跨职能的各组人员来管理。 需求会发生变更。 需求可能对时间敏感。
需求管理流程
人人都是产品经理
项目需求管理
什么是需求：
Rational 把需求定义为“（正在构建的）系统必 须符合的条件或具备的功能”。
著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义， 它特指软件方面 - 但不仅仅限于软件：
系，记录并维护这些关系
• 自动化工具：即选择使用何种CASE工具
客户或开发人员 提出变更请求
变 更 控 制 流 程
项目经理
分流处理 不是问题 应重视的问题 不接受 变更控制委员会 需求管理委员会
小问题 自行解决
变更影响分析报告 不接受 接受
修改SRS
修改开发计划
修改其它相关文档
需 求 管 理 委 员 会
•
评审注意事项：
– 严格控制每次评审的文档规模和持续时间：避免 参加者厌倦，提高评审效率和保证评审质量 – 评审工作要分段进行：需求开发与需求评审依次 进行 – 要控制讨论的问题：避免跑题 – 避免无谓的争吵
需 求 评 审
小 结
应用软件项目开发过程中，最为关键的环节是对 需求的控制。 需求管理处于软件项目管理开发周期的最上游； 软件需求主要来源于业务分析的结果，在充分考虑用 户的自身特性与要求的前提下，项目经理在用户与项 目组之间达成共识，建立了需求基线；在项目开发过 程中，通过需求范围认定、需求形式化记录、需求数 据库建立、需求状态跟踪、需求变更分析和波动评估、 需求评审控制等程序，通过使用需求管理工具等手段， 实现对项目需求按基线的控制和管理。 需求管理的好坏，对产品项目的成败起决定性作 用，项目经理的资质、技能要求非同一般，责任心更 是保证。
简单地说，系统开发团队之所以管理需求是为了 获得项目成功。 好的需求管理是项目成功的第一要素。
为 什 么 要 管 理 需 求？
需求分析在启动和计划阶段，占有相当大的比例。
什 么 是 需 求 管 理？
需求管理是一种获取、组织并记录系统需求的系 统化方案，以及一个使客户与项目团队对不断变更的 系统需求达成并保持一致的过程。 提供一种机制，以分析需求、评估可行性、协商 合理的解决方案、无歧义地规约解决方案、确认规约 以及在开发过程中管理这些被确认的需求规约。包括6 个步骤： 获取（需求诱导）
都必须有需求管理员或组
•
需求管理必须与需求工程的其他活动机密结合：需求管理是
形式，需求获取、需求分析、需求验证等是内容
需 求 管 理 的 规 划
进行需求管理的第一步是建立需求管理规划： • 需求识别：给需求以惟一的标识
•
变更过程管理：确定一个选择、分析和决策需求变更的
过程
ห้องสมุดไป่ตู้
•
需求跟踪：定义需求之间的关系及需求和设计之间的关
• 项目计划过程：需求是项目计划的基础
需 求 的 作 用
• 跟踪控制过程：监控每项需求的状态，以发现设计是否达到了 预期的要求 • 变更控制过程：需求文档确定并制定基线后的变更都要通过确 定的变更控制过程来实现
• 系统测试过程：需求是测试的重要参考文档编制过程：需求是
编写文档的重要参考 • 系统构建过程：需求决定模块设计，模块设计是代码实现的依 据
（2）分析系统的数据要求 数据定义、数据逻辑关系、输入/出数据定义、
数据采集方式等
（3）抽象出并确立目标系统的逻辑模型 如用例图、设计模型、实施模型和实现模型等 （4）编写需求规格说明书 如数据流图、面向对象的分析等。
跟踪控制过程
需 求 的 作 用
项目计划过程
变更控制过程
软件需求过程
系统构建过程 文档编制过程 系统测试过程
–
–
需求可追溯性信息：连接需求文档中彼此依赖的信息
设计可追溯性信息：连接需求到其实现的设计模块
需 求 跟 踪 的 作 用
• • • • • •
在需求验证中，便于确保所有需求被应用 有助于变更影响分析 便于需求的维护 便于测试时找出问题所在 便于项目跟踪和减少项目风险 简化了系统再设计，易于软件重用
需求开发与管理的界限
客户 市场 管理 项目环境
需求获取及分析
需求记录
需求验证
基准需求规格
需求变更
版本控制
需求状态及跟踪
需求开发
需求管理
需 求 管 理 的 目 标
需求管理是一种获取、组织并记录软件需求的系统 化方案，也是使客户与项目团队对不断变更的软件需
求保持一致的过程
需求管理的目的：在客户和处理客户需求的软件项 目组之间建立对客户需求的共同理解
用户需求
原始
系统需求
解决
软件设计描述
提 交 需 求 的 基 本 原 则
• 语句和段落尽量简短
• 语句要完整，语法、标点等要正确
• 使用的术语与词汇表中的定义保持一致 • 避免使用模糊、主观的术语，如性能“优越” • 避免使用比较性词汇，尽量给出定量的说明， • 含糊的表达将引起需求的不可验证 • „
需• 求• 验• 证• • 的• 内• 容•
• •
有效性检查： 每项需求都是正确有效的，能解决用户面对的问题 一致性检查：需求不应该冲突 完备性检查：应包含所有用户想要的功能和约束 现实性检查：保证能利用现有技术实现 可检验性检查：描述的需求能够实际测试 可跟踪性检查：需求的出处被清晰记录 可调节性检查： 需求变更不会对其它部分造成大规模影响 可读性检查：能够被读懂
需 求 质 量 保 证
• •
• •
需求验证过程 审查需求文档：由分析人员、客户、设计人员和测 试人员等组成的审查小组 编写测试用例：根据用户要求的产品功能写出测试 用例。如果测试的设计很可能或不可能，说明需求 的实现很困难 编写用户手册：用户手册初稿 确定合格的标准：合格的测试是建立在使用情景描 述或使用实例基础上的
需 求 的 类 别
原始问题描述：对要解决问题的叙述， 它是软件需求的基础 用户需求：用自然语言和图表给出的关 于系统需要提供的服务及操作的约束 系统需求：用详细的术语给出系统要提 供的服务及受到的约束 软件设计描述：在系统需求的基础上加 入更详细的内容，它是软件详细设计和 实现的基础
原始问题描述
“软件需求可定义为： 用户解决某一问题或达到某 一目标所需的软件功能。系统或系统构件为了满足合同、 规约、标准或其他正式实行的文档而必须满足或具备的 软件功能。”
为 什 么 要 进 行 需 求 管 理?
评测和验证有效的软件开发流程标准得到了推广 和普及 为什么现在仍然频繁发生的软件项目失败的事件？ 为什么仍有那么多的项目受到延期、预算超支和 质量问题的困扰？ 如何才能提高系统的质量？
•
目的：建立和维护从用户需求到测试的一致性与完整性，确
保实现都以客户需求为基础，实现的需求覆盖了预期的需求，
需 求• 跟 踪
并确保输出与用户需求的符合性 需求跟踪就要追溯需求间以及需求与系统设计间的联系，可
追溯性是需求描述的一个总体特性，反映了发现相关需求的
能力。三类可追溯性信息：
– 源可追溯性信息：连接需求与提出需求的人员及产生需求的原因
• • • •
一、职能： 评审——需求分析及讨论 跟踪——需求修改进度 监督——需求整改质量保证
• 二、会议制度： • 每周定期召开需求管理会议
职 能 和 规 定
• 产品研发步骤： • 一、产品需求文档： • 二、讨论（发散思维），排列出优先等级 测试人员参与，按照实现效果、目的测试— —测试用例 • 三、功能设计→详细设计→测试→日常维护 • 四、根据客户反馈，搜集新一轮需求； • 会议决议： • 1、在不影响重大需求的前提下，新的紧急需求会 尽快上线。 • 2、如果计划做新版本，需要重新做出新规划
1. 使软件受控，并建立供软件工程和管理使用的需求基线 2. 使软件计划、产品和活动与软件需求保持一致
需 求 管 理 的 原 则
•
• • • •
一定要分类管理：
目标性需求、具体业务流程需求和操作性的需求等 必须分优先级 必须文档化： 文档必须是正确的、最新的、可管理的、可理解和经过验证的
•
需求一旦变化，就必须对需求变更的影响进行评估，每个项目