例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没　　有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？

　　试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。

　　例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。

　　在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，

　　编写质量需求的方针

　　编写的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

　　句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们

　　要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。

　　需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。

　　密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。

　　通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。

　　避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

　　如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件象一盒巧克力，你永远不知道你会得到什么。