伤城文章网 > 管理学 > 7-软件需求管理G-北京大学软件与微电子学院

7-软件需求管理G-北京大学软件与微电子学院


软件需求管理
周 立 新 博士 北京大学软件与微电子学院

业务需求

用户能有效的纠正文档中的拼写错误 找出文档中的拼写错误并通过一个提供 的替换项列表来供选择替换拼错的词。
质量属性

项目视图与范围文档

用户需求

使用实例文档

其他非功能需求

系统需求

功能需求

约束条件

?找到并高亮度提示错词; ?显示提供替换词的对话框以及 实现整个文档范围的替换。

软件需求规格说明

需求工程
包括软件类产品 中需求收集、评 价、编写文档等 所有活动 需求开发

需求工程

建立并维护在软 件工程中同客户 达成的契约 需求管理

问题获取

分析

编写规格说明

验证

需求开发活动
?确定产品所期望的用户类。 ?获取每个用户类的需求。 ?了解实际用户任务和目标以及这些任 务所支持的业务需求。 ?分析源于用户的信息以区别用户任务 需求、功能需求、业务规则、质量属 性、建议解决方法和附加信息。

需求开发活动(续)
?将系统级的需求分为几个子系统,并将 需求中的一部份分配给软件组件。 ?了解相关质量属性的重要性。 ?商讨实施优先级的划分。 ?将所收集的用户需求编写成规格说明和 模型。 ?评审需求规格说明,确保对用户需求达 到共同的理解与认识,并在整个开发小 组接受说明之前将问题都弄清楚。

需求管理活动
? 定义需求基线(迅速制定需求文档 的主体)。 ? 评审提出的需求变更、评估每项变 更的可能影响从而决定是否实施它。 ? 以一种可控制的方式将需求变更融 入到项目中。 ? 使当前的项目计划与需求一致。

需求管理活动(续)
? 估计变更需求所产生影响并在此基 础上协商新的承诺(约定)。

? 让每项需求都能与其对应的设计、 源代码和测试用例联系起来以实现 跟踪。 ? 在整个项目过程中跟踪需求状态及 其变更情况。

需求开发与 管理之间的 界线

市场

客户 需求 分析 编写文档 评审、商议

管理

需求开发 基准需求说明 需求管理 当前基线 市场 客户 管理 需求变更过程 需求变更 项目变更 修正后基线

项目环境

需求开发与需求管理之间的界限

1. 需求管理活动

CMMI中需求管理的流程图
开始 组织的总体方针 需求管理模板

制定需求管理计划

求 得 对 需 求 的 理 解

求 得 对 需 求 的 承 诺

管理需求变更

维护对需求的双向追踪性

识别项目工作与需求之间的不一致性

结束

1.1 版本控制
?需求文档的每一个版本必须被统一确定。 ?组内每个成员必须能够得到需求的当前版 本。 ?必须清楚地将变更写成文档,并及时通知 到项目开发所涉及的人员。 ?为了尽量减少困惑、冲突、误传,应仅允 许指定的人来更新需求。

需求的属性
? ? ? ? ? ? ? ? ? ? ? 创建需求的时间 需求的版本号 创建需求的作者 负责认可该需求的人员 需求状态 需求的原因或根据(或信息的出处) 需求涉及的子系统 需求涉及的产品版本号 使用的验证方法或接受的测试标准 产品的优先级或重要程度(例如高、中、低或) 需求的稳定性(在将来需求可能变更的指示器,不稳定的 需求意味你应给予较多的关注,因为你将面临不定的、混 沌的、或不能重复的业务过程。)

建议的需求状态表
状态值 已建议 定 义
该需求已被有权提出需求的人建议

已批准

该需求已被分析,估计了其对项目余下部分的影响(包括成 本和对项目其余部分的干扰),已用一个确定的产品版本号 或创建编号分配到相关的基线中,软件开发团队已同意实现 该项需求 已实现需求代码的设计、编写和单元测试
使用所选择的方法已验证了实现的需求,例如测试和检测, 审查该需求跟踪与测试用例相符。该需求现在被认为完成

已实现
已验证

已删除
已拒绝

计划的需求已从基线中删除,但包括一个原因说明和做出删 除决定的人员

状态跟踪示例

1.2 需求变更管理
?应仔细评估已建议的变更 。 ?挑选合适的人选对变更做出决定。 ?变更应及时通知所有涉及的人员。 ?项目要按一定的程序来采纳需求变更。

控制项目范围的扩展
?扩展需求是指在软件需求基线已经确定后 又要增添新的功能或进行较大改动。 ?问题不仅仅是需求变更本身,而是迟到的 需求变更会对已进行的工作有较大的影响。 ?要是每个建议的需求都被采纳,对于项目 出资者(sponsor)、参与者与客户来说 项目将永远也不会完成—事实上,这是不 可能的。

控制项目范围的扩展
? 对许多项目来说,一些需求的改进是合理的且不 可避免。 ? 业务过程、市场机会、竞争性的产品和软件技术 在开发系统期间是可以变更的,管理部门也会决 定对项目做出一些调整。 ? 在你的项目进度表中应该对必要的需求改动留有 余地。 ? 若不控制范围的扩展将使我们持续不断地采纳新 的功能,而且要不断地调整资源、进度、或质量 目标,这样做极其有害。

管理范围扩展
? 管理范围扩展的第一步就是把新系统的视图、范 围、限制文档化并作为业务需求的一部分。 ? 评估每一项建议的需求和特性,将它与项目的视 图和范围相比较决定是否应该采纳它。 ? 强调客户参与的有效的需求获取方法能够减少遗 漏需求的数量,只在做出提交承诺和分配资源后 才采纳该需求。 ? 控制需求扩展的另一个有效的技术是原型法,这 个方法能够给用户提供预览所有可能的实现,以 帮助用户与开发者沟通从而准确把握用户的真实 需求。 ? 要敢于说“不”。

变更控制策略
? 所有需求变更必须遵循的过程,按照此过程,如果一 个变更需求未被采纳,则其后过程不再予以考虑。 ? 对于未获批准的变更,除可行性论证之外,不应再做 其它设计和实现工作。 ? 简单请求一个变更不能保证能实现变更,要由项目变 更控制委员会( C C B)决定实现哪些变更。 ? 项目风险承担者应该能够了解变更数据库的内容。 ? 绝不能从数据库中删除或修改变更请求的原始文档。 ? 每一个集成的需求变更必须能跟踪到一个经核准的变 更请求。

简单变更控制步骤模板
1. 绪论
①目的 ②范围 ③定义

5. 任务
① ② ③ ④ 产生变更请求 评估变更请求 作出决策 通知变更人员

2. 角色和责任 3. 变更请求状态 4. 开始条件

6. 验证 7. 结束条件

变更管理活动中可能的项目角色
角色 描述及责任
变更控制委员会 变更控制委员会的主席,在C C B意见不一致情况下可 主席 以独自做出决定 CCB 决定采纳或拒绝针对某项目所建议的变更请求的团体 评估者 应项目管理者要求分析所建议的变更带来影响的人员

修改者
建议者 项目管理者 请求接受者

负责实现已经被认可的请求变更,按时更新变更状态 的人员
提交新变更请求的人 负责指定评估者和修改者的人员 接受提交变更请求的人

验证者

负责决定变更是否正确执行的人

变更控制委员会的组成
? 产品或计划管理部门。 ? 项目管理部门。 ? 开发部门。 ? 测试或质量保证部门。 ? 市场部或客户代表。 ? 制作用户文档的部门。 ? 技术支持部门。 ? 帮助桌面或用户支持热线部门。 ? 配置管理部门。

常见变更请求数据项

变 更 需 求 状 态 转 换 图

测量变更活动
?接收、未作决定、结束处理的变更请求的 数量。 ?已实现需求变更(包括增、删、改)的合 计数量(也可以用在基线上占需求总数的 百分比来表示)。 ?每个方面发出的变更请求的数量。 ?每一个已应用的需求(是指已划过基线) 建议变更和实现变更的数量。 ?投入处理变更的人力、物力。

工作量 (劳动时数) ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________

任务 更新软件需求规格说明书或需求数据库 开发并评估原型 创建新的设计部件 修改已有的设计部件 开发新的用户界面部件 修改已有的用户界面部件 开发新的用户文档和帮助文件 修改已有的用户文档和帮助文件 开发新的源代码 修改已有的源代码 购买和集成第三方软件 修改构造文件 开发新单元测试和综合测试 进行单元测试和综合测试 写新的系统测试实例 修改已有的系统测试实例 修改自动测试驱动程序 进行回归测试 开发新报告 修改已有的报告 开发新的数据库元素 修改已有的数据库元素 开发新的数据文件 修改已有的数据文件 修改各种项目计划 更新别的文档 更新需求跟踪能力矩阵 检查工作产品 根据测试和检查情况返工 总计劳动时数

影响分析报告模板
变更请求I D_______________ 标题__________________ 描述__________________ 分析者__________________ 日期_______________ 优先权评估: 相关收益_______________(1 - 9) 相关代价_______________(1 - 9) 相关成本_______________(1 - 9) 相关风险_______________(1 - 9) 最终优先级_______________ 预计总耗时_______________劳动时数 预计损时_______________劳动时数 预计对进度的影响_______________天数 额外的成本影响_______________金额 质量影响_________________________________________ 被影响的其他需求_________________________________ 被影响的其他任务_________________________________ 要更新的计划_____________________________________ 综合的事项_______________________________________ 生存期成本事项___________________________________ 可能的变更所需检查的其他部件_____________________

1.3 需求跟踪
客户需要

追溯到 需求
需求

从需求 回溯

从需求 追溯

回溯到 需求

下游工作产品

一 些 可 能 的 需 求 跟 踪 能 力 联 系 链

业务需求 规格说明 影响 变更请求 影响 影响 影响 被陈述 软件功能需求 被验证 连接到 依 赖 另 一个

系统需求,用例,业务规 则及外部接口需求

体系结构,用户接口 或功能设计
被验证 集成测试

系统测试

项目计划 任务

被实现
代码 被验证 单元测试

RequisitePro Project Organization
Toolbar Project icon Package Document

Views

Requirements

Working in a View

Existing Artifacts for RU e-st Project
RM Plan
Create in the project
Stakeholder Requests

Glossary

RU e-st Project

Supl. Spec

?
csv file Vision

Exist in the project UC Spec

? Included
on Exercise CD

?

?

?

Import into the project

Create a Requirement in the Explorer or in a View

Requirements and Associated Documents
Needs
Features
Vision Document

Stakeholder Requests

Software Requirements
Use-Case Model

Supplementary Specifications

Design, Test, Documentation Requirements

Design Specifications

User Documentation Specifications

Delete a Requirement in a Document


搜索更多“7-软件需求管理G-北京大学软件与微电子学院”

网站地图

All rights reserved Powered by 伤城文章网 5xts.com

copyright ©right 2010-2021。
伤城文章网内容来自网络,如有侵犯请联系客服。zhit325@126.com