需求评审流程规范.doc

需求评审步骤
目录
1. 目的 1
2. 职责 1
3. 评审角色构成因素 1
4. 文档评审的层次 2
5. 文档评审流程 3
5.1评审流程概览 3
5.2确定评审组长 3
5.3评审计划 3
5.4评审准备 4
5.5评审会议 4
5.6评审记录 4
5.7评审结论 4
5.8跟踪与总结 4
5.9材料归档 5

1. 目 
在团体开发中, 充足沟通是非常有必需, 沟通方法之一就是经过文档。不管评审效果怎样, 发觉多少问题都能够让相关人员了解需求与设计。而经过相互之间讨论, 澄清部分模糊认识, 深入了解文档含义。评审不不过软件开发活动中一个关键质量控制机制, 而且也是一个关键而有效沟通方法。经过评审能够利用企业内部多种优异组员智慧, 为软件开发寻求最好处理方案。 
   评审作用和目关键是尽早发觉潜在问题, 尽早纠正缺点, 控制纠正成本滚雪球效应。本阶段造成错误假如能够立刻地发觉, 或者在后面越早阶段发觉, 就能够及早发觉潜在风险, 立刻做好防范对策, 做到未雨绸缪。 
   评审过程不仅是为了发觉问题, 而且为了便于跟踪及更正, 还应该对问题进行统计。尤其是需要对问题真实性进行确定, 剔除可能是误解、 似是而非或无须采纳提议性问题。  
2. 职责 
Ø Ø 评审组长: 制订评审计划、 确定或制订各项评审准则、 必需时组织评审人员进行培训、 组织必需资源、 进行评审分工、 确保正式评审准备充足、 分发待评审文档、 必需时召开并主持评审会议、 向相关领导汇报评审结果, 而且跟踪评审错误更正。 Ø 
Ø 评审人员: 必需时参与与评审相关培训、 按评审计划阅读待评审材料、 确保对待评审材料了解、 与待评审材料作者讨论, 而且指出和统计问题。
Ø 文档作者: 按评审计划准备并按时提交待评审材料、 必需时对材料进行解释、 必需时参与评审会议, 而且在确定需要改善时按时完成修改。 
Ø Ø 统计人员: 评审会议中统计评审人员提出问题及相关讨论。 
Ø Ø 项目经理: 制订确保评审和更正项目进度计划, 还要确保评审准备时间、 评审会议时间及错误更正时间。而且评审安排及结果与全部项目组员沟通, 必需时参与评审会议、 阅读评审汇报、 分析缺点原因, 而且改善项目质量。 

3. 评审角色组成原因 
评审人员选择是评审效果关键, 需要考虑以下原因:  
Ø Ø 项目关键性: 项目关键性是决定角色组成最关键原因, 评审角色组成原因首先要依据项目关键性而定。这与需要投入成本相关, 对于关键项目通常会更多地投入资源, 提升评审等级。 
Ø Ø 项目复杂度: 项目复杂度也是决定角色组成原因之一, 依据温伯格公式, 项目管理复杂度相当于功效规模平方数。笔者认为还应该考虑技术复杂度、 技术新鲜度和文档复杂度等原因。 
Ø Ø 项目组组员能力成份和水平: 评审角色组成还应该依据项目团体组员本身各项技术水平, 尤其是分析和设计技术水平怎样, 行业领域知识是否丰富来进行搭配。 
除了团体内部自己进行评审之外, 评审团体最好是部分独立于项目团体之外组员组成。  应该注意标准是人数要少而精, 一个人能够兼多个角色, 但要覆盖各项人员需求。需要说明是, 不含有评审能力不应参与, 能够经过旁听来提升水平。  

4. 文档评审层次 
Ø Ø 过程规范: 是否符合过程规范、 是否根据计划提交、 是否按时经过评审、 是否按时公布（注意提交时间与公布时间区分）, 以及评审步骤是否规范。 适合评审人员: QA。 
Ø 文档规范: 文档结果符合企业或业界已经制订文档模板规范。企业, 甚至行业应该制订统一文档规范, 形成一个文档约定和规则, 以统一文档内容与风格。 
适合评审人员: QA。 
Ø Ø 文档语法: 文档结果正确使用通用方法与术语并符合软件工程相关技术标准, 这里所说语法包含自然语言语法和建模语言语法。 
适合评审人员要求: 精通软件工程、 分析与设计方法、 建模工具和相关标准。 Ø 
Ø 文档语义: 文档结果表示清楚、 无歧义, 能够反应系统目标。全部质量合格文档（包含模型）都代表它期望代表语义, 而且应该在代表这些语义时含有一致性。
文字与图表应该相互补充说明, 以愈加清楚。让他人看得懂, 看完后知道下一步该怎么做。 
适合评审人员: 行业业务教授、 高级程序员和测试工程师。 
Ø 
Ø 文档逻辑: 关键表现需求与设计正确性、 一致性, 无遗漏、 多出或错误。前后左右考虑周全, 不一样文档之间、 文档与行业标准之间、 同一文档各成份之间不相互矛盾, 清楚说明相关部分之间关系, 尤其是要符合相关行业业务标准规范。 适合评审人员: 行业业务教授、 产品经理和测试工程师。 
Ø Ø  文档美学: 文档结果能否表述得愈加好部分, 文字、 图表是否能愈加均衡和完整。
需要追求平衡美, 每个组成部分应该大小适中, 可解读并可变更。平衡有多个方面, 如排版次序愈加合理、 文字、 图形愈加精炼并更易了解等。 
适合评审人员: 系统分析与设计教授, 以及建模工具教授。 
Ø Ø 结果优化: 经过检验判定文档结果（如项目计划、 需求规格及设计方案）是否还有
改善空间, 方便愈加方便地进行项目管理、 降低成本、 加紧进度、 提升质量并降低风险, 尽可能达成最好方案。任何一项设计都能够有很多不一样方案, 经过“方案优化”选定一个最好方案。 
适合评审人员: 系统分析与设计教授、 项目经理和产品经理。

5. 文档评审步骤

5.1评审步骤概览 
① 确定评审组长。 
 ② 制订并公布评审计划。  ③ 准备评审。 
 ④ 举行评审会议。 
 ⑤ 更正、 跟踪和回归评审。  ⑥ 分析、 总结和汇报。  
⑦ 归档。 
5.2确定评审组长 
由品质确保人员与项目经理、 部门经理论协商, 确定项目评审等级及评审人员角色组成要求, 初步确定评审组长人选。品质确保人员与评审组长沟通, 最终确定评审组长。评审组长充足了解项目相关情况, 为制订评审计划做好准备。

5.3评审计划 
① 评审组长制订评审计划（依据项目计划和质量计划）。   ② 评审组长确定评审对象和评审时间。 
  ③ 评审组长确定评审等级和策略（形式组合）。   ④ 评审组长确定评审步骤淘汰和提交物。   ⑤ 评审组长确定入口条件并经过准则。   ⑥ 评审组长确定回归评审准则。 
  ⑦ 评审组长制订评审检验表（CheckList）。   ⑧ 评审组长确定评审角色组成。 
  ⑨ 评审组长依据评审角色组成确定评审人员并成立评审小组。   ⑩ 相关人员（评审人员和项目团体双方）确定评审计划。 
评审组长公布评审计划。 
5.4评审准备 
① 正式评审前准备: 文档作者向相关人员公布文档。   ② 评审人员阅读了解文档, 争取发觉大部分问题。   ③ 文档作者处理大部分发觉问题。 
  ④ 评审组长确定会议地点、 环境、 设备和全部材料。   ⑤ 评审组长确定人员职责和会议议程。   ⑥ 评审组长确定评审开始条件成熟。   ⑦ 评审组长通知相关人员到会。 
5.5评审会议 
① 主持人（评审组长）宣告会议议程、 人员职责和会场纪律。   ② 文档作者介绍工作结果, 对评审人员疑问进行必需解释。   ③ 评审人员对不解之处提出疑问, 指出问题或缺点并说明依据。 
  ④ 文档作者与评审人员讨论缺点真实性, 分清缺点性问题和提议性问题, 讨论确定是否需要根据评审人员要求进行改善。通常不包含为节省时间改善方案或错误纠正方案。 
5.6评审统计 
  ① 正式评审应该统计有共识问题或缺点, 也要统计有争议待处理问题。使评审工作文档化, 便于跟踪最终处理。 
  ② 总体统计: 包含项目名称、 系统名称版本号、 日期时间、 主文档名称、 附文档名称、 文档版本号、 作者、 评审类型（首次、 回归、 部分和阶段）、 评审人员和评审结论。 
  ③ 缺点统计: 包含缺点编号、 提出者、 章节／页码、 缺点描述、 缺点类型（严重、 通常和提议）和承诺更正时间。 
  ④ 验证统计: 全部打勾CheckList, 说明CheckList所列工作都已经做完, 所列内容都已经评审完, 确保工作完整性。 

5.7评审结论 
评审结论包含以下内容。 
①  是否需要修改？这是就结果整体而言, 结论能够是无需、 少许、 较大或是一个量化数字。   
②  项目组确定是否接收修改要求？这是针对具体一条意见或提议。有些问题可能是误会, 消除了就不是问题; 有些提议性问题, 项目组考虑进度可不接收修改要求。  
 — 如不接收修改要求, 项目组给出不修改理由。   
— 怎样处理？是否需要进行回归评审？  
 — 总体结论: 合格或不合格。 
 — 确定修改责任人和跟踪责任人。 
   — 确定回归评审时间。 
   — 是否都认同评审结论？假如需要做得更正式部分, 能够要求相关人员签字表示同意评审结论, 签字 
5.8跟踪与总结 
评审中发觉问题后续跟踪是更正错误并消除缺点有效方法, 应该有专门责任人进行后续跟踪确定错误都已更正, 依据结论必需时回归评审。  
 ① 评审组长分析评审数据并总结经验   
② 评审组长公布评审统计与数据分析汇报。  
 ③ 管理人员应该预防评审数据被不合适地使用, 假如使用评审数据来对个人进行绩效评价, 将会给以后评审工作造成障碍, 使评审各方不能放开进行评审。 
  ④ 评审组长进行工作总结, 工作总结很有必需, 有利于对项目或过程改善。  
 ⑤ 评审组长提交各类评审汇报, 相关领导同意公布经过文档。 
5.9材料归档 
评审材料归档是项目配置管理工作一部分。新建项目, 记载配置管理工具中为此项目建立一个目录, 并建立下列子目录。 
  ① 待评阅态: 文件放入此目录后会自动经过邮件通知需要评阅人员, 全体评阅人员评阅完成, 也会自动经过邮件把意见通知文档作者并实现到期自动提醒功效。 
  ② 待评审态: 文件放入此目录后会自动经过邮件通知需要评审人员, 全体评阅人员评审完成, 也会自动经过邮件把同意或拒绝意见通知文档作者并实现到期自动提醒功效。   
③ 受控态: 评审同意后自动转入受控态并公布自动邮件。  
 ④ 签出态: 为了修改而版本升级, 当文件签出时放入签出态。修改后文档可能签入到待评阅态、 待评审态或直接到受控态, 但文档版本已经升级。  
 ⑤ 产品态: 项目结束后受控态文档自动归到产品态。