ch补充需求补充.ppt

需求验证 需求管理 访谈技巧 访谈焦点 确定风险 需求验证 审查需求文档 在需求开发期间进行非正式评审。 对需求文档进行正式审查是保证软件质量的很有效的方法。 组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。 需求验证（续） 依据需求编写测试用例 根据用户需求所要求的产品特性写出黑盒功能测试用例。 客户通过使用测试用例以确认是否达到了期望的要求。 从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。 要使用测试用例来验证需求模型的正确性，如对话框图和原型等。 需求验证（续） 确定合格的标准 确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。 将合格的测试建立在使用情景描述或使用实例的基础之上。 需求验证（续） 需求确认签字 在主要的业务清楚以后即可以进行需求确认 目的是确定需求基线 不要期望所有的需求在签字后不变 需求管理 大师说：没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。“ 所以需求管理过程做的事情就是保证需求变更的可管理性。 需求管理（续） 需求基线 软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线； 建立需求基准版本和需求控制版本文档确定一个需求基准，这是一致性需求在特定时刻的快照； 之后的需求变更就遵循变更控制过程； 每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。 需求管理（续） 需求变更控制 确定需求变更控制过程，确定一个选择、分析和决策需求变更的过程。 需求变更控制流程 需求管理（续） 建立变更控制委员会 组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本； 变更控制委员会成员可以是甲方与乙方的人员共同组成； 定期进行需求变更评审会议； 每次评审要有评审报告。 需求管理（续） 需求变更影响评估 进行需求变更影响分析，应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。 明确与变更相关的任务并评估完成这些任务需要的工作量。 需求管理（续） 需求变更时，修改需求跟踪能力矩阵 跟踪所有受需求变更影响的工作产品当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。 需求管理（续） 维护需求变更的历史记录 记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。 在需求基线的基础上记录变更历史记录； 针对每一个需求形成一个单独记录； 需求类型 功能性需求(FRs) 功能性需求描述了一种系统特性，它支持某种角色使用系统完成某种商业操作。 例：系统必须收集如下顾客信息—姓名及地址。 非功能性需求(NFRs) 非功能性需求描述了一种系统特性，它支持怎样执行某种操作。 例：在网络应用中系统必须能够同时支持10位用户使用。 访谈技巧 访谈并不是一项容易学习的技巧，这里有如下技巧： 与业务所属者建立友善的关系，参与轻松的交谈，但避免讲笑话。 仔细倾听。 温和的掌握访谈方向，如果业务所属者离题太远则小心的打断他的谈话。 仔细倾听。 重复不清楚的陈述并请求确认。 仔细倾听。 获得详细记录。 仔细倾听。 愿景访谈焦点 愿景访谈需要注意以下方面： 用于项目的商业案例。 用于项目的功能需求。 风险。 约束。 项目干系人。 业务案例问题 为业务所属者解释为什么需要软件。 你当前的业务运转情况是怎样的？ 你的公司是干什么、做什么或是销售什么的？ 公司的结构是怎样的？ 我可以拥有一份公司的组织结构图吗（或是相关的业务单元）？ 新的软件系统打算怎样支持业务？ 你的业务怎样变革？ 你是否计划扩展你的业务？ 公司是否可能会重组？ 用于发现功能需求的问题 与业务所属者解释针对你的业务软件必须做什么？ 让业务所属者列出（或描述）系统最重要的10项用例。 与业务所属者重申每一项用例。 核实你对于每一项用例的理解。 让业务所属者把用例按优先级区分为以下等级：基本的(essential)、重要的(high-level)、后继的(follow-on)。 重复列出这些用例，并且询问是否遗失了任何重要的用例。 用于发现风险的问题 有五个主要的风险区域。有一些问题可以帮助确定项目风险： 在你的业务中是否有其他小组做相似的功能？ 你计划在项目中使用新技术吗？（例如：J2EE? 平台或简单对象访问协议） 你是否有开发的资源或是计划把项目外包？ 你的团队成员是否有必要