此活动的用途是:
需求变更必然会影响下游工件(例如,分析和设计工作产品、测试工作产品、部署工件等)。在 管理依赖关系期间确定并记录的 可跟踪性关系明确地定义了需求和其他工作产品之间的关系。这些关系是理解需求变更影响的关键。
涉及到扩展团队(项目干系人:客户代表、领域专家和其他人员)。 将软件项目团队中工作受到变更影响的任何人员加入作为技术复审员。请谨慎而有效地管理您的复审资源。不要包括整个扩展团队,除非您能确保它对项目增值。
扩展团队应当相当了解问题域、项目的技术难题,并具有需求管理和用例建模方面的技能。
只要优化需求,就应执行该活动。
定期复审以及需求属性和相关性的更新,应在需求更新时进行。
建议您为先启和精化阶段中的每次迭代安排一次用例模型的复审,以复审正在进行的工作,这是在详细地开发任何用例之前就已完成并由用户签署确认的,而且这是非常重要的里程碑,这样就不会在开发不正确的用例上浪费资源。然后,在“精化”阶段结束时,您应该安排对用例模型的详细复审。请记住,在精化阶段结束时,您应该具有一个用例模型,可能还具有完成了 80% 的、代表词汇表的领域模型。您还应该在优化用例模型时在构造和移交阶段为每次迭代安排一次用例模型复审。复审应该集中在正在为迭代开发的那部分用例模型。
核心开发团队应开展几轮内部复审:先通过粗查来清除不必要的不一致情况,然后由扩展团队更正式地检查和复审该团队的工作。
应将材料划分开来,这样团队就不会一次性复审所有材料了。复审会议不应超过一天。例如,可以单独复审用户界面和行为场景,也可以复审与给定子系统相关的所有需求工件。
另一个重要注意事项是跟踪需求历史记录。通过捕获需求变更的本质和理由,复审人员接收到正确应对变更所需的信息。
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.