为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。
例2．“产品应瞬间在显示和隐藏不可打印字符间切换”
计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。
象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。
例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没 有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？
试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。
例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。
在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的。
编写质量需求的方针
编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。
句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们
要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。
需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。
密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。
通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。
避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。
如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。
文章来源于领测软件测试网 https://www.ltesting.net/
