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