目的
  • 正式验证需求的结果符合客户对系统的看法。
角色: 技术复审员 
频率:按照要求,通常是对于开始自先启的每个迭代发生多次。
步骤
更多信息: 
输入工件:   结果工件:  
工具向导:  

工作流程明细:  

一般建议 回到页首

目的 每次复审的一般建议。

以下指南在复审需求的结果时很有用:

  • 总是以会议的形式开展复审,虽然参加会议的人可能会自行准备复审。
  • 不断地检查产出,以确保产品质量尽可能高。出于这个目的提供了检查点;请参阅每个分析活动的检查点。您可以将这些检查点用于非正式的复审会议或日常工作中。

下列角色将参加复审会议 - 充当需求复审员的人对业务或技术领域有一些基本了解,对应用的辅助和建模技术有详细的了解:

您还应该考虑以下角色参加复审会议,可能是在里程碑处(例如某一阶段的开始或结束):

能够在以下两者间找到适当平衡很重要:包含期望的复审参与者,保持复审可以管理并有成果。应该注意仅包括那些会对实现复审目标有贡献的参与者。通常,召开数次只有少数人参加的集中的复审会议比起召开一次有很多人参加的复审会议,效率会高得多。

建议的复审会议 回到页首

目的 定义复审的范围和目标。
定义用于每个具体的范围/目标组合的方法。 

一般情况下,您应将复审分为以下会议:

  • 变更请求的复审,它影响现有的需求集。
  • 整个用例模型的复审。
  • 用例(每个用例)以及它们的图的复审。如果系统很大,请将该复审分为数个会议,比如每个用例包一次会议。

即使您可以在同一次会议中复审所有内容,您也很可能无法使大家第一次就同意您的结论。请准备好对用例模型的每个新版本开展新的复审。

建议您在先启精化阶段为每个迭代安排一次用例模型的复审,在复审中,您复审进行中的工作;这是在详细开发任何用例前最初完成并由用户签署确认的,并且是非常重要的里程碑,这样资源就不会浪费在开发不正确的用例上了。然后,在“精化”阶段结束时,您应该安排对用例模型的详细复审。请记住,在“精化”阶段结束时,您应该有一个用例模型,可能还有完成了 80% 的代表术语表的领域模型。您还应该在优化用例模型时在构造移交阶段为每个迭代安排一次用例模型复审。复审应该集中在正在为迭代开发的那部分用例模型。

准备复审记录和记载缺陷 回到页首

目的 记载复审结果。
确保记载了识别的缺陷。 

在每次复审会议后,会议的结果记载在复审记录中。此外,任何缺陷都按照项目的变更管理流程进行记载。

进一步的阅读 回到页首

请参阅:[BIT03] 第 11 章。



Rational Unified Process   2003.06.15