参加一个项目需求评审发现的问题

beck3000

由于我们公司进行CMMI3的评估，对每个项目都要进行相关制品的评审。我作为测试人员，参加了一个项目的5人需求评审小组。

需求评审的对象包括两个：《用户需求说明书》和《需求规格说明书》。有个著名的需求模型FURPS＋，即功能性（Functionality）、可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Suppotability），＋（设计约束、实施需求、接口需求、物理需求），虽然没有做到考虑周全，但我们还是尽最大可能挑出了七八十条关于需求的缺陷，归纳起来，主要是这些方面：

1.笔误。如：登录系统都写成登陆系统
2.前后不一致。如：《用户需求说明书》与《需求规格说明书》对同一功能的范围描述不一致；
再如：一个用例在各处的名称描述都不一样。
3.无法验证。如：“项目二期系统将比一期满足更多性能和安全需求”。
4.用例写作不合规范。如：一些事件流的步骤缺少主语；命名风格不统一；用例命名要采用动宾结构。
5.重要术语未作解释。
6.备选事件流考虑不充分，有遗漏。如：某个分支流程只考虑了Yes的情况，No则未予描述。
7.含义模糊，解释不清。如：“该模块定时运行”，定时运行的频率是多少？
8.用例的前置条件、后置条件考虑不充分。
9.备选事件流的入口，出口未明确指出。
10.模棱两可。如：“用户可以保存”，这种带有不确定性的东西在需求中不能出现。
11.Actor选取错误。如：一个用例居然选择系统本身作为actor，actor其实必须是系统之外的。
12.不完整。如：整个需求规格说明书中没有身份验证、权限的相关描述。

goal0813

谢谢beck3000的经验分享，这些问题是经常会碰到的。能否细说一下，评审后，发现这些问题，大家对这些问题的解决方案是怎样的呢？

beck3000

我们的需求评审是这样进行的：我们这些评审小组的成员事先阅读这两个需求文档，各自提交关于需求的缺陷到TD中，然后选择某一个下午，大家在一起召开需求评审会议，就是要求大家对这些缺陷形成共识，需求分析师可以对某些缺陷提出异议，然后大家讨论，如果确实是需求写作中存在的问题，需求分析师必须对这些缺陷限期整改，形成新的版本。

至于如何来更正这些缺陷，因为缺陷种类繁多，不能一一列举。

象某些明显错误的地方，如文字、版本说明、前后名称不一致这些，当时就可以修改;

我们还会深入具体的需求，看他写作的用例是否全面，如果遗漏则要求他增加到新的需求版本中；

会上讨论最多的还是用例的写作方法，因为需求分析师以前没有采用过现在这种模板，某些地方他可能不够明确，造成误解什么的。而且他以前写需求也未必是使用用例分析的方法，写法难免也不够规范，比如备选流和基本事件流怎么区分他就经常搞不明白，我们这么多人在会上正好帮他一起分析。

总之，需求评审会议不仅仅是个给需求分析师挑刺的过程，而且是一个集思广益的过程。

goal0813

beck3000兄凌晨2点还来回帖，感激ing。。。看来你们公司对测试流程还是很规范的。
有些问题：
"而且他以前写需求也未必是使用用例分析的方法，写法难免也不够规范"
这句话什么意思？
需求文档生成后才能写用例的，对么？
用例分析的方法是怎样的方法呢？

beck3000

凌晨2点是因为"长夜漫漫、无心睡眠"：）其实是习惯了晚睡，一直想改改不过来，千万别学我，不是好习惯。

我所说的用例指的是Use Case，可能你理解为测试用例Test Case了吧，测试用例是一定要在需求文档之后生成的。

早先需求文档的写作有很多种方式，随着现在越来越多采用面向对象分析与设计（OOAD），用例分析的方法成为现在需求写作的主流，所谓用例，就是指一个系统所执行的动作序列，它描述了一个或若干个用户和系统的交互场景。需求文档中包含全部的用例，单独拿一个用例来说，包含这些必要的元素：描述、前置条件、后置条件、基本事件流、备选流、异常流、输入输出、参与的actor（角色）等等。

如果你想对这个有更多了解，看看譬如《有效用例写作》之类的书，市面上非常多。如果你想了解所有需求写作的方式，推荐一本砖头一样厚的书《系统分析与设计》，中英文版的都有，那里的相关章节有介绍，无论是面向过程的还是面向对象的。

goal0813

呵呵。
的确我把use case误解为test case了。

这样我就明白了，现在我参与的项目也是有use case的，不过只是由项目经理（同时也是需求分析人员）编写后给大家看的，没有做过评审。现在那些use case好像都闲置在一边，没人看了。

想起在看过一篇文章，《使用用例场景设计测试用例》，其实这种方式是个不错的方法，前段时间在设计用例时，我尝试了采用这种利用use case－－》test case的办法，后来做用例评审时，项目组成员反映都还不错。

末了，问一下，你们的项目组人员分配是怎么样的呢？人数比例多少？评审use case时，那些角色人员参与呢？

beck3000

我们项目组人算不上多，肯定会有人身兼数职，但测试人员不会兼别的，占到1/4吧。
需求评审就不仅仅是我们项目组的人了，还有公司SEPG组织的人，QA部门的人，需求部门的人，其他项目组的人，我这个测试呢算是QC的人，我们项目组的PM和需求分析师在会议上属于被告一方，但是有申述权。

goal0813

呵呵，明了。

swallow0918

学了很多关于评审的内容，谢谢。。。

beck3000

现在搞CMMI，什么都要评审了，天天看文档，前几天是概要设计评审、测试用例评审，现在又详细设计评审，很费时费工阿

gs6431

那你觉得这些工作起到他应有的作用了吗？是不是达到了磨刀不误砍柴工的目的？

wangyanyan

Originally posted by beck3000 at 2005-9-13 10:57 AM:
现在搞CMMI，什么都要评审了，天天看文档，前几天是概要设计评审、测试用例评审，现在又详细设计评审，很费时费工阿

开始实行的时候都是感觉费时费工的，但是实行长了就可以见到成果了，只有前面的底子打牢，才能保证后面工作的正常进行，要不很可能测试的时候还在改需求，该代码。

beck3000

其实如果把项目产品放在一个整体角度来考虑，包括质量、成本、进度这些指标，各个阶段的详细评审还是非常有必要的，否则盲目赶工的恶果就是将来ｂｕｇ成堆，修改它们所耗费的人力、时间等各项成本也很惨痛，越到后期越是这样，我对这个就深有体会。
但是客户或者公司一方往往会对进度有比较严格要求，那这些评审有可能会流于形式，我是主张一丝不苟做这些事情的

_pwbnu

我们公司还没有这个过程

tyrande

需求评审推行还需要一个适应的过程，不过在前期开发和测试都介入对原型有所了解，也能集思广益的发现问题。

但是我所经历的需求评审，由于多种原因，有的时候还会流于表面，导致开发过程或是测试过程中发现问题，需求走变更，这样其实还是前期的评审工作没有做到位。

tyrande

在补充一下，也有部分原因是需求的不规范，导致源头存在的问题太多。。。。
现在只能是下游弥补。。。不是长久之计

zhyly101

每个公司关注的点不一样，不同的客户关注点也不一样，尽量做好吧