高质量需求说明的特征

　　一个完整的SRS不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。

　　完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难，因为根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。

　　在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。

　　如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，可以从一个给定的需求集中解决所有的缺陷。

　　一致性：一致性需求是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定于修改相关的部分，可能导致不一致性。

　　可修改性：当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。

　　可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。

　　需求质量的评审

　　这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能猜测每个需求的意图。

　　例1．“产品应在不少于每60秒的正常周期内提供状态信息”

　　这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，是需求的不可证实。

　　弥补缺陷，重写需求的一种方法：


　　1、状态信息
　　1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息
　　1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比
　　1．3任务完成时，应显示相关的信息
　　1．4后台任务出错应该显示错误信息

　　为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时很容易漏掉一个。

　　例2．“产品应瞬间在显示和隐藏不可打印字符间切换”

　　计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，是需求的不可证实。

　　象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。