浅谈软件项目需求评审流程

1、浅谈软件项目需求评审流程在实际的软件项 L1 过程中，需求阶段往往是山一两位需求分析人员与用户沟通用户需 求 ,然后根据自己的理解输出软件需求说明书及软件原型。需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话，往往会给项 LI 带来灭绝性的灾难，不重视需求过程的 项 U 团队将自食其果。因此, 如何保证需求分析的正确、准确性，成了决定软件项 U 成败的 关键因素。U 前 , 很多小型软件企业在需求阶段，往往是需求人员写完需求后再跟用户沟通一下，就直接进入设计开发阶段了，设计、编码、测试人员前期没有参与进来，根本没有进行需求评审。也有不少企业的需求评审存在“走过场”的情况，其他人员根

2、本不关心软件需求，认为 软件需求就是需求分析人员的事情，他们怎么写大家怎么做就可以了，在提需求异常时简单 找儿个错别字提一下应付了事，没有提出有效的需求异常。也有的时候，在需求评审会议中 , 大家的关注点常常会不知不觉的转向设计，结果需求评审会议成了设计讨论会议，大家想得 最多的是需求如何实现，而不是需求文档本身有无问题。或者是因为没有做好前期准备工 作，导致评审时间长、效率低，结果很多问题不了了之。这样的评审, 最终效果可想而知。下 文根据笔者多年参与软件项 U 管理的切身体会及经验, 从不同角度对需求评审方法进行论述。1 、充分准备评审。好的软件需求说明书，是进行有效需求评审的前提。首先，

3、需求人员在与用户确认需求的过程中，一定不要放过任何一个细节 , 仔细体会用户的每一个要求。对于用户的要求，需求人员需要对其加以梳理: 哪些是合理的需求，哪些是不 合理的需求 , 还有一些可能是必要的但是用户没想到的需求。软件需求说明书不应该只是用户意愿的表达，而应该是从软件层面上对用户需求的总 结。软件需求说明书对需求用例的描述一般分为基本流和扩展流，基本流是大家很容易想到 的主要业务流程，而实际设计开发及测试过程中，最耗费时间的是实现扩展流的过程。因此不能只注重基本流，好的软件需求说明书 , 扩展流一定远远多于基本流，扩展流写得越完善， 说明需求人员考虑得越周全。而实质上，如果扩展流写得不完

4、善 , 后期的设计、开发及测试人员往往在相应的细节处理上无所适从。2 、 分层次评审项 LI 管理者联盟。用户的需求是可以分层次的，一般而言分成以下层次: U 标性需求，定义整个系统需要达到的 U 标； 功能性需求，定义了整个系统必须完成的任务； 操作性需求，定义了完成每个任务的具体的人机交互； U 标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审LI 标性需求 , 可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让 高层的管理人

5、员也去评审那些操作性需求，无疑是一种资源的浪费。分层次评审，可以让不同类型的参与人分别评审他们关注的内容, 从不同的角度找到需 求的异常，提高评审效率。3 、 正 式评审与非正式评审结合正式评审时指通过开评审会的方式，将需求涉及到的人员集合在一起，并定义好参与评 审人员的角色和职责，对需求进行正规的会议评审。很多时候，因为需求内容太多，正式的评 审会议中不可能将每一个细节都涉及到，评审员也有一个理解需求的过程，在短短的会议中 不可能发现太多问题。因此，需要与非正式评审相结合，在评审会之前可以先开会对大家进行需求讲解，然后把需求通过邮件等方式发送给相关人员，留儿天时间，以便相关人员仔细研究，记录

6、异常，在正 式的评审会上讨论。4 、 分 阶段评审需求评审应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。可以根据需求人员进行需求分析的进度，将一个整体的软件需求分为不同的阶段，组织小规模的评审。在形成U 标性需求后进行一次评审，在形成系统的初次概要需求后进行一 次评审，对概要需求细分成儿个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。这样降低了需求返工的风险，提高了评审的质量。5 、 评 审人员选择需求评审涉及到各层次人员，在进行评审员选择时，一定要将各层次人员都囊括进来，他们可能有用户、需求分析人员、产品经理、项目经理、架构师、概要设计人员、详细设计人

7、员、编码人员、测试人员、质量保证人员等等。用户在进行需求评审时, 关注点更多在于他们所要求的功能是否在软件需求说明书中都囊括进来了； 架构师及概要设计人员更多关注的是在现有的技术条件下， 是否能够实现需求 中的要求，如果无法实现需求或者代价太大，可能就要需求人员与用户沟通更改需求; 编码人 员可能更多关注于某些细节，例如界面元素等; 测试人员主要关注是否所有的需求都是可测 试的 ; 质量保证人员关注点在于输出物是否符合规范。各层次人员充分参与, 便于他们理解 需求 , 通过需求评审，达成一致意见 , 不至于需求在不同环节因理解不同而出现偏差。因为各层次人员的立场不同， 对同一个问题的看法是不相

8、同的， 有些观点是和系统的 U 标有 关系的，有些是关系不大的，不同的观点可能形成互补的关系。如果漏掉某一层次的人 员，可能 会漏掉很重要的需求。6 、 对评审人员进行培训 常常见到有的项 U 的需求评审会议在主持人进行需求讲解时，与会人员似懂非懂，没有 提出有价值的问题，致使会议没有取得预期的效果，不得不改日重新进行。有的项 U 的需求 评审会议针对某一个细节问题与会人纷纷提出自己的意见 , 大家争执不下，结果，会议出现了 混乱状况 , 主持人无法控制局面， 致使会议大大超出了计划评审时间。 因为各层次评审人员 关注点不同，评审也需要技巧、把握关键点，因此，应该对各层次评审人员进行有针对性的

9、培 训。以便于参与评审的人员能够紧紧圉绕评审的 U 标来进行，能够控制评审活动的节奏，提 高评审效率。7 、 把握需求评审的关键点(1) 注意对软件需求说明书的正确性进行评审。需求规格说明的正确性通常可以从如下 方面得以体现： 是否有需求与其他需求相互冲突或者重复？ 是否清晰、简洁、无二义地表达了每个需求 ( “清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定“读”的效果，是让大家对需求描述的理解能够达成一致 ) ？ 是否每个需求都通过了演示、测试、评审，分析是否得到了验证？ 是否每个需求都在项 U 的范围内？ 是否每个需求都没有内容和语法上的错误？ 在现有的资源内，是否能实现所有

10、的需求？ 每一条特定的错误信息，是否都是唯一的和具有含义的？U 前企(2) 注意对软件需求说明书的实践性进行评审。所谓实践性是指需求本身是否来源于业的相关业务规则和文件制度， 而非源于分析师们经验主义的臆测。 实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。(3) 注意对需求规格说明书的完整性进行评审。可山下面的问题清单来评审需求说明书 是 否“完整”： 编写的所有需求，其详细程度是否一致和合适？ 需求是否能为设计提供足够的基础？ 所有对其他需求的内部引用是否正确？ 是否包含了每个需求的实现优先级？ 是否定义了功能说明的内在算法？ 是否包含了所有已知的客户需求或系统

11、需求？ 是否遗漏了必要的信息？是否对所有预期的错误条件所产生的系统行为都编制了文档?需求说明的完整性主要体现在需求说明的详细程度上，怎样判断该需求的描述是否详细 呢?笔者认为需求需要精化 , 而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什 么、需要什 么数据信息、受什么业务规则和条件限制、系统会有什么响应等。(4) 注意对需求方案的可行性和成本预算进行评审。(5) 注意对需求的质量属性进行评审。评审需求规格需要说明是否合理地确定了所有的 性 能 U 标 , 是否合理地确定了安全性方面要考虑到的问题。(6) 注意对需求的可实施性进行评审： 是否对每个需求都设置了唯一性并且可以正确地识别它？

12、 是否每个功能需求都可以跟踪到高层需求？需求必须可以测试， 每个需求在特定的输入条件下应当能给出已知的输出结果， 同时， 需 求应当层次分明， 需要把单个需求下面的相关需求综合在一起形成一组需求功能。 需求的可 实施性除了可跟踪性还包括可测试性 , 事实上，分析人员和测试人员在编写代码以前把需求模型，分析模型和测试用例综合起来通盘考虑，检查出遗漏的、错误的和不必要的需求，软件 需求在概念上的测试是一种很必要的技术，它可以在项 LI 早期阶段发现需求的歧义和错误。8 、 给予评审员充足的评审时间实践证明，需求的异常往往存在于细节方面，评审员理解软件需求乂需要一个过程，要想找到这些异常，必须有充足

13、的时间，以便充分理解需求、找出其中的缺陷，提出可行性建议。因此，从需求讲解到非正式评审再到正式评审，需要预留足够的时间。如果评审员是项LI中的成员，项口负责人需要给项口成员专门下达需求评审的时间，如 果评审员只能额外抽时间来研究需求，恐怕只能简单提儿条质量不高的异常了事。评审自然也就达不到预期的 LI 的。实践证明，在需求评审上多花一些实践是值得的，所谓“磨刀不误砍柴工”。9 、 建立评审流程对正规的需求评审会需要建立正规的需求评审流程 , 按照流程中定义的活动进行规范的 评审过程。比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审

14、通过的条件等等。10 、 建立评审制度有效的需求评审，相关的评审制度必不可少，主要有以下方面： 限制项 U 内评审员提交有效异常的数量，并纳入考核，必须达到一定数量才算合格； 制定评审的准入准出条件，限制随意通过评审； 质量保证人员参与评审，监督评审进行; 质量保证人员对评审流程进行全程监控。11 、 跟踪工作切忌评审完毕后，没有对问题进行跟踪 , 而无法保证评审结果的落实，使前期的评审努力付之东流。在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正 , 并给出充分的客观的理山与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管

15、理流程，并确保变更的执行，在变更完成后，要进行复审。在实际的软件项 LI 过程中，需求阶段往往是山一两位需求分析人员与用户沟通用户需求 ,然后根据自己的理解输出软件需求说明书及软件原型。需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话，往往会给项 U 带来灭绝性的灾难，不重视需求过程的 项 U 团队U 成败的 关键因素。将自食其果。因此, 如何保证需求分析的正确、准确性，成了决定软件项U 前 , 很多小型软件企业在需求阶段，往往是需求人员写完需求后再跟用户沟通一下，就直接进入设计开发阶段了，设计、编码、测试人员前期没有参与进来，根本没有进行需求评审。也有不少企业的需求评审存在“走过

16、场”的情况，其他人员根本不关心软件需求，认为 软件需求就是需求分析人员的事情，他们怎么写大家怎么做就可以了，在提需求异常时简单 找儿个错别字提一下应付了事，没有提出有效的需求异常。也有的时候，在需求评审会议中 , 大家的关注点常常会不知不觉的转向设计，结果需求评审会议成了设计讨论会议，大家想得 最多的是需求如何实现，而不是需求文档本身有无问题。或者是因为没有做好前期准备工 作，导致评审时间长、效率低，结果很多问题不了了之。这样的评审, 最终效果可想而知。下 文根据笔者多年参与软件项 U 管理的切身体会及经验, 从不同角度对需求评审方法进行论述。1、充分准备评审。好的软件需求说明书，是进行有效需

17、求评审的前才是。首先，需求人员在与用户确认需求的过程中，一定不要放过任何一个细节 , 仔细体会用户的每一个要求。对于用户的要求，需求人员需要对其加以梳理: 哪些是合理的需求，哪些是不 合理的需求 , 还有一些可能是必要的但是用户没想到的需求。软件需求说明书不应该只是用户意愿的表达，而应该是从软件层面上对用户需求的总 结。软件需求说明书对需求用例的描述一般分为基本流和扩展流，基本流是大家很容易想到 的主要业务流程，而实际设计开发及测试过程中，最耗费时间的是实现扩展流的过程。因此不能只注重基本流 , 好的软件需求说明书，扩展流一定远远多于基本流, 扩展流写得越完善， 说明需求人员考虑得越周全。而实

18、质上，如果扩展流写得不完善 , 后期的设计、开发及测试人员往往在相应的细节处理上无所适从。2 、 分 层次评审项口管理者联盟。用户的需求是可以分层次的，一般而言分成以下层次: U 标性需求，定义整个系统需要达到的 U 标； 功能性需求，定义了整个系统必须完成的任务； 操作性需求，定义了完成每个任务的具体的人机交互； U 标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审口标性需求, 可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让

19、 高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费。分层次评审，可以让不同类型的参与人分别评审他们关注的内容, 从不同的角度找到需 求的异常，提高评审效率。3 、 正 式评审与非正式评审结合正式评审时指通过开评审会的方式，将需求涉及到的人员集合在一起，并定义好参与评 审人员的角色和职责，对需求进行正规的会议评审。很多时候，因为需求内容太多，正式的评 审会议中不可能将每一个细节都涉及到，评审员也有一个理解需求的过程，在短短的会议中 不可能发现太多问题。因此，需要与非正式评审相结合，在评审会之前可以先开会对大家进行需求讲解，然后把需求通过邮件等方式发送给相关人员，留儿天时间，以便相关人员

20、仔细研究，记录异常，在正 式的评审会上讨论。4 、 分 阶段评审需求评审应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。可以根据需求人员进行需求分析的进度，将一个整体的软件需求分为不同的阶段，组织小规模的评审。在形成U 标性需求后进行一次评审，在形成系统的初次概要需求后进行一 次评审，对概要需求细分成儿个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。这样降低了需求返工的风险，提高了评审的质量。5 、 评 审人员选择需求评审涉及到各层次人员，在进行评审员选择时，一定要将各层次人员都囊括进来，他们可能有用户、需求分析人员、产品经理、项目经理、架构师、概要设计人员、详细设计人员、编码人员、测试人员、质量保证人员等等。用户在进行需求评审时, 关注点更多在于他们所要求的功能是否在软件需求说明书中都囊括进来了；架构师及概要设计人员更多关注的是在现有的技术条件下，是否能够实现需求中的要求，如果无法实现需求或者代价太大，可能就要需求人员与用户