代码评审记录_需求评审，需求说明书的正确性

在软件项目中,需求分析是最开始的工作,同时也是最重要的工作。需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话,往往会给项目带来灭绝性的灾难,不重视需求过程的项目团队将自食其果。因此,如何保证需求分析的正确、准确性,成了决定软件项目成败的关键因素。

需求偏差原因：

• 在实际的项目过程中,需求阶段往往是由一两位需求分析人员与用户沟通用户需求,然后根据自己的理解输出软件需求说明书及软件原型。

• 经验再丰富的需求分析人员也可能犯错,所谓智者千虑,必有一失,这是永远不变的客观规律。

• 受需求分析人员的理解及用户的表达等因素的影响,需求在传递过程中往往存在很大偏差。

• 需求分析人员输出的需求分析说明书,到设计人员、编码人员、测试人员那里往往又会有不同的理解。

软件需求分析说明书的正确性必须得到彻底的验证,利益相关方必须彻底理解需求,并达成一致。要达成这一目标、降低需求风险,需求评审是一个行之有效的方法。

软件需求说明书不应该只是用户意愿的表达,而应该是从软件层面上对用户需求的总结。

评审不是走过场，

• 目前,很多小型软件企业在需求阶段,往往是需求人员写完需求后再跟用户沟通一下,就直接进入设计开发阶段了,设计、编码、测试人员前期没有参与进来,根本没有进行需求评审。

• 也有不少企业的需求评审存在“走过场”的情况,其他人员根本不关心软件需求,认为软件需求就是需求分析人员的事情,他们怎么写大家怎么做就可以了,在提需求异常时简单找几个错别字提一下应付了事,没有提出有效的需求异常。

• 也有的时候,在需求评审会议中,大家的关注点常常会不知不觉的转向设计,结果需求评审会议成了设计讨论会议,大家想得最多的是需求如何实现,而不是需求文档本身有无问题。

评审开始

评审人员选择

    需求评审涉及到各层次人员,在进行评审员选择时,一定要将各层次人员都囊括进来,他们可能有用户、需求分析人员、产品经理、项目经理、架构师、概要设计人员、详细设计人员、编码人员、测试人员、质量保证人员等等

• 用户在进行需求评审时,关注点更多在于他们所要求的功能是否在软件需求说明书中都囊括进来了;

• 架构师及概要设计人员更多关注的是在现有的技术条件下,是否能够实现需求中的要求,如果无法实现需求或者代价太大,可能就要需求人员与用户沟通更改需求;

• 编码人员可能更多关注于某些细节,例如界面元素等;

• 测试人员主要关注是否所有的需求都是可测试的;

• 质量保证人员关注点在于输出物是否符合规范。

各层次人员充分参与,便于他们理解需求,通过需求评审,达成一致意见,不至于需求在不同环节因理解不同而出现偏差。

因为各层次人员的立场不同,对同一个问题的看法是不相同的,有些观点是和系统的目标有关系的,有些是关系不大的,不同的观点可能形成互补的关系。如果漏掉某一层次的人员,可能会漏掉很重要的需求。

正式评审与非正式评审结合

　　正式评审时指通过开评审会的方式,将需求涉及到的人员集合在一起,并定义好参与评审人员的角色和职责,对需求进行正规的会议评审。很多时候,因为需求内容太多,正式的评审会议中不可能将每一个细节都涉及到,评审员也有一个理解需求的过程,在短短的会议中不可能发现太多问题。

因此,需要与非正式评审相结合,在评审会之前可以先开会对大家进行需求讲解,然后把需求通过邮件等方式发送给相关人员,留几天时间,以便相关人员仔细研究,记录异常,在正式的评审会上讨论。

把握需求评审的关键点

　　(1)注意对软件需求说明书的正确性进行评审。需求规格说明的正确性通常可以从如下方面得以体现:

　　①是否有需求与其他需求相互冲突或者重复? 　　②是否清晰、简洁、无二义地表达了每个需求(“清晰”是让人能够读懂;“简洁”是让人愿意去读;“无二义”决定“读”的效果,是让大家对需求描述的理解能够达成一致)? 　　③是否每个需求都通过了演示、测试、评审,分析是否得到了验证? 　　④是否每个需求都在项目的范围内? 　　⑤是否每个需求都没有内容和语法上的错误? 　　⑥在现有的资源内,是否能实现所有的需求? 　　⑦每一条特定的错误信息,是否都是唯一的和具有含义的?

　　(2)注意对软件需求说明书的实践性进行评审。所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。

　　(3)注意对需求规格说明书的完整性进行评审。可由下面的问题清单来评审需求说明书是否“完整”:

　　①编写的所有需求,其详细程度是否一致和合适? 　　②需求是否能为设计提供足够的基础? 　　③所有对其他需求的内部引用是否正确? 　　④是否包含了每个需求的实现优先级? 　　⑤是否定义了功能说明的内在算法?        ⑥是否包含了所有已知的客户需求或系统需求?        ⑦是否遗漏了必要的信息?        ⑧是否对所有预期的错误条件所产生的系统行为都编制了文档?

需求说明的完整性主要体现在需求说明的详细程度上,怎样判断该需求的描述是否详细呢?笔者认为需求需要精化,而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应等。

　　(4)注意对需求方案的可行性和成本预算进行评审。

　　(5)注意对需求的质量属性进行评审。评审需求规格需要说明是否合理地确定了所有的性能目标,是否合理地确定了安全性方面要考虑到的问题。

　　(6)注意对需求的可实施性进行评审:

　　①是否对每个需求都设置了唯一性并且可以正确地识别它? 　　②是否每个功能需求都可以跟踪到高层需求?

需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果,同时,需求应当层次分明,需要把单个需求下面的相关需求综合在一起形成一组需求功能。需求的可实施性除了可跟踪性还包括可测试性,事实上,分析人员和测试人员在编写代码以前把需求模型,分析模型和测试用例综合起来通盘考虑,检查出遗漏的、错误的和不必要的需求,软件需求在概念上的测试是一种很必要的技术,它可以在项目早期阶段发现需求的歧义和错误。

　　(7)注意对需求包含的用例文档进行评审。用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方法是也是当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审主体之所在。

　　需求评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的评审,首先要通过测试用例的主干过程。而是否撰写有效的用例则要从以下方面着手评审:用例的目标或价值度量是否明确?用例是否是独立的分散任务?

　　是否明确说明可用用例会给哪些参与者带来用处?编写用例的详细程度是否恰当?是否有不必要的设计和实现细节?所有预期的分支过程是否都编写了文档说明?所有预估的异常过程是否都编写了文档说明?是否存在一些普通的动作序列可以分解成独立的用例?

　　每个路径的步骤是否都清晰明了,无歧义而且完整?用例中的每个参与者和步骤是否都与所执行的任务有关?用例中定义的每个可选路径是否都可行和可验证?用例的前置条件和后置条件是否合理?分析师必须确认用例的前置条件和后置条件准确界定了用例的边界范围,区分了用例和用例之间的界限。

需求审查结束的标准为: 

• 已经明确阐述了审查员提出的所有问题、

• 已经正确修改了文档、

• 修订过的文档已经进行了语法检查、

• 所有TBD问题都已经解决、

• 文档归档

　在需求评审后,需要根据评审人员提出的问题进行评价,以确定哪些问题是必须纠正的,哪些可以不纠正,并给出充分的客观的理由与证据。

　　当确定需要纠正的问题后,要形成书面的需求变更的申请,进入需求变更的管理流程,并确保变更的执行,在变更完成后,要进行复审。切忌评审完毕后,没有对问题进行跟踪,而无法保证评审结果的落实,使前期的评审努力付之东流。