需求评审流程规范.docVIP

需求评审步骤

目录

TOC\o1-3\h\z\u1.?目的 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。?

??文档语法:文档结果正确使用通用方法与术语并符合软件工程相关技术标准,这里所说语法包含自然语言语法和建模语言语法。?

适合评审人员要求:精通软件工程、分析与设计方法、建模工具和相关标准。???

文档语义:文档结果表示清楚、无歧义,能够反应系统目标。全部质量合格文档（包含模型）都代表它期望代表语义,而且应该在代表这些语义时含有一致性。

文字与图表应该相互补充说明,以愈加清楚。让他人看得懂,看完后知道下一步该怎么做。?

适合评审人员:行业业务教授、高级程序员和测试工程师。?

??

文档逻辑:关键表现需求与设计正确性、一致性,无遗漏、多出或错误。前后左右考虑周全,不一样文档之间、文档与行业标准之间、同一文档各成份之间不相互矛盾,清楚说明相关部分之间关系,尤其是要符合相关行业业务标准规范。?适合评审人员:行业业务教授、产品经理和测试工程师。?

???文档美学:文档结