公文素材库 首页

如何编写一个好的需求

时间:2019-05-22 06:55:06 网站:公文素材库

如何编写高质量需求

Karl E www.bsmz.netL标记。由于没有定义触发条件,需求对设计没有约束力。只有设计人员选定了触发条件后,你才能编写测试验证触发的正确操作。

例3 “HTML分析器可以产生HTML标记错误报告,帮助HTML入门者快速解决错误”。

单词“快速”使其模糊,没有加进错误报告的定义也是其部完整。我不知道,你怎么验证这个需求。找一个自称为HTML的入门者,看看能不能根据错误报告快速解决错误?

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

例4 “如果可能,主管号码应通过联机校验,而不是通过主全体主管号码列表校验”。

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

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

编写质量需求的方针

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

? 句子和段落要短。采用主动语气。使用正确的语法,拼写,标点。使用术语,要保

持一致性,并在术语表或数据字典中定义它们

? 要看需求是否被有效的定义,可以以开发人员的观点看看。在内心将“当你们做完

了找我”这句加到文档尾部,看看能不能是你紧张起来。换句话说,你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求,以便于设计和实现?如

果是的话,在继续工作前,需求还需要细化。

? 需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。

有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确,那么它已经正确的细化了。如果你预想到多种不同类的测试,几个需求可能已挤到了一起,需要拆分开。

? 密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个

需求合并。不要在一个需求中使用“和”/“或”。

? 通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如:“对于

红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开,而“产品应能对来自语音编辑指示做出反应”应作为一个子系统,不应作为单个的功能性需求。

? 避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读,

但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新,避免不一致性。

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

  来源:网络整理 免责声明:本文仅限学习分享,如产生版权问题,请联系我们及时删除。


如何编写一个好的需求
由互联网用户整理提供,转载分享请保留原作者信息,谢谢!
http://m.bsmz.net/gongwen/365212.html
相关阅读
最近更新
推荐专题