ch4补充-需求补充.ppt

ch4补充-需求补充.ppt?需求验证?需求管理?访谈技巧?访谈焦点?确定风险需求验证?审查需求文档–在需求开发期间进行非正式评审。–对需求文档进行正式审查是保证软件质量的很有效的方法。–组织一个由不同代表(如分析人员,客户,设计人员, 测试人员)组成的小组,对需求规格说明书及相关模型进行仔细的检查。需求验证(续) ?依据需求编写测试用例–根据用户需求所要求的产品特性写出黑盒功能测试用例。–客户通过使用测试用例以确认是否达到了期望的要求。–从测试用例追溯回功能需求以确保没有需求被疏忽, 并且确保所有测试结果与测试用例相一致。–要使用测试用例来验证需求模型的正确性,如对话框图和原型等。需求验证(续) ?确定合格的标准–确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。–将合格的测试建立在使用情景描述或使用实例的基础之上。需求验证(续) ?需求确认签字–在主要的业务清楚以后即可以进行需求确认–目的是确定需求基线–不要期望所有的需求在签字后不变需求管理?大师说: "没有不变的需求,世上的软件都改动过 3次以上,唯一一个只改动过两次的软件的拥有者已经死了,死在去修改需求的路上。“?所以需求管理过程做的事情就是保证需求变更的可管理性。需求管理(续) ?需求基线–软件需求规格说明及相关分析模型。经评审批准,这些文档就定义了开发工作的需求基线; –建立需求基准版本和需求控制版本文档确定一个需求基准,这是一致性需求在特定时刻的快照; –之后的需求变更就遵循变更控制过程; –每个版本的需求规格说明都必须是独立说明,以避免将底稿和基准或新旧版本相混淆。需求管理(续) ?需求变更控制–确定需求变更控制过程,确定一个选择、分析和决策需求变更的过程。–需求变更控制流程需求管理(续) ?建立变更控制委员会–组织一个由项目风险承担者组成的小组作为变更控制委员会,由他们来确定进行哪些需求变更,此变更是否在项目范围内,估价它们,并对此评估作出决策以确定选择哪些,放弃哪些,并设置实现的优先顺序, 制定目标版本; –变更控制委员会成员可以是甲方与乙方的人员共同组成; –定期进行需求变更评审会议; –每次评审要有评审报告。需求管理(续) ?需求变更影响评估–进行需求变更影响分析,应评估每项选择的需求变更, 以确定它对项目计划安排和其它需求的影响。–明确与变更相关的任务并评估完成这些任务需要的工作量。