《软件需求管理》PPT课件

管理课件
11
需求的属性
创建需求的时间 需求的版本号 创建需求的作者 负责认可该需求的人员 需求状态 需求的原因或根据（或信息的出处） 需求涉及的子系统 需求涉及的产品版本号 使用的验证方法或接受的测试标准 产品的优先级或重要程度（例如高、中、低或） 需求的稳定性（在将来需求可能变更的指示器，不稳定的
需求意味你应给予较多的关注，因为你将面临不定的、混 沌的、或不能重复的业务过程。）
管理课件
12
建议的需求状态表
状态值
定义
已建议 该需求已被有权提出需求的人建议
已批准 已实现
该需求已被分析，估计了其对项目余下部分的影响（包括成本 和对项目其余部分的干扰），已用一个确定的产品版本号或创 建编号分配到相关的基线中，软件开发团队已同意实现该项需 求
软件需求管理
周 立 新 博士
北京大学软件与微电子学院
管理课件
1
业务需求 项目视图与范围文档
用户能有效的纠正文档中的拼写错误
找出文档中的拼写错误并通过一个提供 的替换项列表来供选择替换拼错的词。
用户需求 使用实例文档
质量属性 其他非功能需求
系统需求
功能需求
约束条件
•找到并高亮度提示错词；
软件需求规格说明
已实现需求代码的设计、编写和单元测试
已验证 已删除 已拒绝
使用所选择的方法已验证了实现的需求，例如测试和检测，审 查该需求跟踪与测试用例相符。该需求现在被认为完成
计划的需求已从基线中删除，但包括一个原因说明和做出删除 决定的人员
管理课件
13
状态跟踪示例
管理课件
14
1.2 需求变更管理
应仔细评估已建议的变更 。 挑选合适的人选对变更做出决定。 变更应及时通知所有涉及的人员。 项目要按一定的程序来采纳需求变更。
•显示提供替换词的对话框以及实
现整个文档范围的替换。
管理课件
2
需求工程
包括软件类产品 中需求收集、评 价、编写文档等 所有活动
需求工程
需求开发
建立并维护在软 件工程中同客户 达成的契约
需求管理
问题获取
分析 编写规格说明 验证
管理课件
3
需求开发活动
确定产品所期望的用户类。
获取每个用户类的需求。
• 使当前的项目计划与需求一致。
管理课件
6
需求管理活动（续）
• 估计变更需求所产生影响并在此基 础上协商新的承诺（约定）。
• 让每项需求都能与其对应的设计、 源代码和测试用例联系起来以实现 跟踪。
• 在整个项目过程中跟踪需求状态及 其变更情况。
管理课件
7
需求开发与 市场 管理之间的
界线
客户 需求
管理课件
18
控制项目范围的扩展
对许多项目来说，一些需求的改进是合理的且不 可避免。
业务过程、市场机会、竞争性的产品和软件技术 在开发系统期间是可以变更的，管理部门也会决 定对项目做出一些调整。
在你的项目进度表中应该对必要的需求改动留有 余地。
若不控制范围的扩展将使我们持续不断地采纳新 的功能，而且要不断地调整资源、进度、或质量 目标，这样做极其有害。
管理课件
19
管理范围扩展
管理范围扩展的第一步就是把新系统的视图、范 围、限制文档化并作为业务需求的一部分。
评估每一项建议的需求和特性，将它与项目的视 图和范围相比较决定是否应该采纳它。
强调客户参与的有效的需求获取方法能够减少遗 漏需求的数量，只在做出提交承诺和分配资源后 才采纳该需求。
控制需求扩展的另一个有效的技术是原型法，这 个方法能够给用户提供预览所有可能的实现，以 帮助用户与开发者沟通从而准确把握用户的真实 需求。
➢ 要敢于说“不”。
管理课件
20
变更控制策略
所有需求变更必须遵循的过程，按照此过程，如果一 个变更需求未被采纳，则其后过程不再予以考虑。
对于未获批准的变更，除可行性论证之外，不应再做 其它设计和实现工作。
简单请求一个变更不能保证能实现变更，要由项目变 更控制委员会（ C C B）决定实现哪些变更。
将所收集的用户需求编写成规格说明和 模型。
评审需求规格说明，确保对用户需求达
到共同的理解与认识，并在整个开发小
组接受说明之前将问题都弄清楚。
管理课件
5
需求管理活动
• 定义需求基线（迅速制定需求文档 的主体）。
• 评审提出的需求变更、评估每项变 更的可能影响从而决定是否实施它。
• 以一种可控制的方式将需求变更融 入到项目中。
项目风险承担者应该能够了解变更数据库的内容。
绝不能从数据库中删除或修改变更请求的原始文档。
每一个集成的需求变更必须能跟踪到一个经核准的变 更请求。
管理课件
21
简单变更控制步骤模板
1. 绪论
① 目的 ② 范围 ③ 定义
2. 角色和责任 3. 变更请求状态 4. 开始条件
5. 任务
① 产生变更请求 ② 评估变更请求 ③ 作出决策 ④ 通知变更人员
了解实际用户任务和目标以及这些任 务所支持的业务需求。
分析源于用户的信息以区别用户任务 需求、功能需求、业务规则、质量属 性、建议解决方法和附加信息。
管理课件
4
需求开发活动（续）
将系统级的需求分为几个子系统，并将 需求中的一部份分配给软件组件。
Biblioteka Baidu
了解相关质量属性的重要性。
商讨实施优先级的划分。
解
诺
管理需求变更 维护对需求的双向追踪性 识别项目工作与需求之间的不一致性
结束 管理课件
10
1.1 版本控制
需求文档的每一个版本必须被统一确定。 组内每个成员必须能够得到需求的当前版
本。 必须清楚地将变更写成文档，并及时通知
到项目开发所涉及的人员。 为了尽量减少困惑、冲突、误传，应仅允
许指定的人来更新需求。
管理课件
15
管理课件
16
管理课件
17
控制项目范围的扩展
扩展需求是指在软件需求基线已经确定后 又要增添新的功能或进行较大改动。
问题不仅仅是需求变更本身，而是迟到的 需求变更会对已进行的工作有较大的影响。
要是每个建议的需求都被采纳，对于项目 出资者（sponsor）、参与者与客户来说项 目将永远也不会完成—事实上，这是不可 能的。
管理
需求开发
需求管理
市场 客户 管理
分析 编写文档 评审、商议
基准需求说明
当前基线
修正后基线
需求变更
需求变更过程
项目环境
项目变更
需求开发与需求管理之间的界限
管理课件
8
1. 需求管理活动
管理课件
9
CMMI中需求管理的流程图
开始
制定需求管理计划
组织的总体方针 需求管理模板
求
求
得
得
对
对
需
需
求
求
的
的
理
承