如何编写高质量“软件需求说明书”[3]

　　如何编写高质量“软件需求说明书”[3]  软件测试　

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

　　需求质量的评审

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

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

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

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

　　1、状态信息

　　2.后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息

　　3.如果后台进程处理正常，那么应该显示任务已完成的百分数/比

　　4.任务完成时，应显示相关的信息

　　后台任务出错应该显示错误信息

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

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

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

原文转自：http://www.ltesting.net