仅代表个人观点作者: 小月三木 时间: 2005-12-28 09:41
好，东东，昨天才需求评审完，本身做测试的，也没有评审过，今天好好学习下，下次可以用大家这些理论东西对照来做，应该会做的更好！作者: fanna007 时间: 2006-1-23 22:46
需求说明的特征:
1. 完整性
每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能
所需的所有必要信息。
2. 正确性
每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如
用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有
用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参
与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完
全是评审者凭空猜测。
3. 可行性
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行
的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与
需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。
4. 必要性
每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也
可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户
的输入，如使用实例或别的来源。
5. 划分优先级
给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。
如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制
自由度。
6. 无二义性
对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，
所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需
求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。
7. 可验证性
检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确
定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，
而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。
[ 本帖最后由 fanna007 于 2006-1-23 22:49 编辑 ]作者: fanna007 时间: 2006-1-23 22:47
需求规格说明的特点
1. 完整性
不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功
能将有助于你避免不完整性。如果知道缺少某项信息，用 T B D (“待确定”)作为标准标识来标
明这项缺漏。在开始开发之前，必须解决需求中所有的 T B D项。
2. 一致性
一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所
有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。
3. 可修改性
在必要时或为维护每一需求变更历史记录时，应该修订 S R S。这就要求每项需求要独立标
出，并与别的需求区别开来，从而无二义性。每项需求只应在 S R S中出现一次。这样更改时
易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容
易修改。
4. 可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这
种可跟踪性要求每项需求以一种结构化的，粒度好（ f i n e - g r a i n e d）的方式编写并单独标明，
而不是大段大段的叙述。