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