可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。
需求质量的评审
这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能猜测每个需求的意图。
例1．“产品应在不少于每60秒的正常周期内提供状态信息”
这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。
弥补缺陷，重写需求的一种方法：
1、状态信息
2．后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息
3．如果后台进程处理正常，那么应该显示任务已完成的百分数/比
4．任务完成时，应显示相关的信息
后台任务出错应该显示错误信息
为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。
例2．“产品应瞬间在显示和隐藏不可打印字符间切换”
计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。
文章来源于领测软件测试网 https://www.ltesting.net/
