软件测试的需求评审

1．需求阶段评审的角色和职责

一句话，根据具体情况选择相关人员，充当相关角色，履行相关职责，大家也别吐槽我，现实就是这样，别去记忆这些死规则了

 

2．好的需求应具备的特点

完整性：每一项需求都必须将所有要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确的陈述其要开发的功能。

一致性：指与其它软件需求或高层需求不相矛盾

可行性：每一项需求都必须是已系统和环境的权能和限制范围可以实施的。

无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求简明的用户性的语言表达出来。

健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：可理解为每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回溯至某项客户的输入。

可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：每项需求只应在SRS中出现一次。这样更改时容易保持一致性。另外，使用目录列表、索引和相互参照列表方法使软件需求规格说明书更容易修改。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好(f i n e - g r a i n e d )的方式编写并单独标明，而不是大段大段的叙述。

分配优先级：应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度

以上特点也是需求评审的要点，评审前可以根据实际情况指定需求评审检查表来帮助评审。

可以根据以上特点对需求进行评审

 

3．软件需求评审输出

还是一句话，根据具体情况适当的做好评审记录，形式不限，输出文档名称也不限，随便你取，^^内容才是重点

 

4．组织需求评审原则

还是一句话，组织自己定吧，适合就好，效率优先 ^^，别吐槽，没骗你的，不信你百度去，可以百度出不同答案

 

5.需求评审形式

总 体来说可以分为正式评审与非正式评审。正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职 责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天 等多种形式对需求进行评审。2种形式各有利弊，在评审时，灵活地利用这2种方式。