如何编写高质量“软件需求说明书 ”

如何编写高质量“软件需求说明书 ” 日期：2006年2月20日 做者： 人气：2194 查看:[大字体 中字体 小字体] 你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段并且你要写软件需求说明书。这份说明有些大，但客户会很重视，因此说明必须获得赞同。 　　如今你正在设计其中的一个特性，已经发现了需求的一些问题。你能够用多种不一样的方式解释需求15；需求9 的说明正好与需求21相反，你因该相信哪个？需求24很是含糊，你根本不明白它的意思；你不得不花上一个小时与2位开发人员讨论需求30，只由于大家对其各有各的理解；而且，惟一可以澄清这些问题的客户没有给大家答复。你被迫破解众多需求的含义，而且你能预料到，若是你错了，你要作大量的重复工做。

　　许多软件需求说明书（SRS）写得很是糟糕。任何产品的质量须要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。并且，没有很是多的好需求能够借鉴学习，部分缘由是不多有工程能够找到一个好的借鉴，其余缘由是公司不肯意将其产品说明书放在公共区域。

　　这篇文章描述了高质量需求叙述和说明的几个特性（特色）。咱们将用这些观点检查一些有缺陷的需求，带着痛楚从新编写。并且我会谈一些如何编写好的需求的提示。你也许想经过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。

　　不要指望可以编写出一份能体现需求应具有的全部特性的SRS。不管你怎么细化、分析、评论和优化需求，都不可能达到完美。可是，若是你牢记这些特性，你就会编写出更好的需求，生产出更好的产品。

　　高质量需求叙述的特性

　　咱们如何从一些有问题的需求中分辨出好的软件需求？这一节将分别介绍需求叙述应体现的6个特性，下一节将从总体上介绍SRS文档应具有的特性。判断每一个需求是否具有应有的特性的一种方式是由持有不一样观点的工程资金管理人所做的正规检查。另外一种有力的方法是在编写代码前依据需求编写测试例子。测试例子可以明确显如今需求中描述的产品行为（特性），可以显现缺陷、冗余和含糊之处。

　　正确：每一个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（固然，系统需求说明书自己可能不正确）。

　　只有用户的表明可以决定用户需求的正确性，这就是为何在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会致使开发人员的：“这是没意义的”，“这多是他们的意思”等众所周知的猜想。

　　可行性：在已知的能力、有限的系统及其环境中每一个需求必须是可实现的。为了不需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能作什么不能作，哪些须要须要额外的付出或者和其余的权衡。

　　必要性：每一个需求应载明什么是客户确实须要的，什么要顺应于外部的需求，接口或标准。每一个需求源于你承认、具备权说明需求的原始资料，这是考虑必需的另外情形（译注，此句翻译不顺，请参照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟踪每一个需求回溯到出处，如用例，系统需求，规章，或来自其余用户的意见。若是你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。

　　优先权：为了代表在一个详细的产品版本中应包含哪些要点，须要为每一个需求，特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任创建优先权。若是全部的需求都被视为同等重要，那么因为在开发中，预算削减，计划超时或组员的离开致使新的需求时， 项目经理将不能起到做用。优先权的做用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。

　　我是用3种级别的优先权：高优先权代表需求必须体如今下一个产品版本中，中优先权代表需求是必须的，可是若是须要能够推迟到晚一些的产品版本中，低优先权代表有它很好，但咱们必须认识到若是没有充足的时间或资源，它能够被放弃掉。

　　明确：需求叙述的读者应只能从其获得惟一的解释说明，一样，一个需求的多个读者也应达成共识。天然语言极易致使含糊。要避免使用一些对于SRS做者很清楚但对于读者不清楚的主观词汇，如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个须要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，创建用户的假想来讲明产品某个特定部分预期的特性。

　　可证明：看你是否可以作出测试计划或其余验证方式，如检查和实证，来决定在产品中每一个需求是否正确的实现。若是需求是不可验证的，决定需求是否是正确的实现就成了判断的事。需求之间不一致，不可行，不明确也能致使不可证明。任何需求若是说产品将要支持什么也是不可证明的。

高质量需求说明的特征

　　一个完整的SRS不只是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，指望性能的非功能性需求。下面描述了高质量的SRS的一些特性。

　　完整：不该该遗漏要求和必需的信息。完整性也是一个需求应具有的。发现缺乏的信息很难，由于根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。

　　在需求抽象时，相对于系统功能，你过多的注意用户的业务，将致使在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的做用。可以从不一样角度察看需求的图形分析模型也能够检查出不完整性。

　　若是你知道已缺乏一些信息，使用TBD（to be determined）标准标志能够突出这些缺陷，当你在构建产品的相关部分时，就能够从一个给定的需求集中解决全部的缺陷。

　　一致性：一致性需求就是不要于其余的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前获得解决。只有通过调研才能肯定哪些是正确的。修改需求时必定要谨慎，若是只审定修改的部分，没有审定于修改相关的部分，就可能致使不一致性。

　　可修改性：当每一个需求的要求修改了或维护其历史更改时，你必须可以审定SRS。也就是说每一个需求必须相对于其余需求有其单独的标示和分开的说明，便于清晰的查阅。经过良好的组织可使需求易于修改，如：将相关的需求分组，创建目录表，索引，以及先后参考（照）。

　　可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也可以将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具备独立标示，细密和结构化的编写，不该过大，不该是叙述性的文字和公告式的列表。

　　需求质量的评审

　　这些有关需求质量的特性的描述在理论上都是很是好的，但一个好的需求究竟是个什么样子的呢？为了体现得更切合实际，咱们作个小练习。下面有几个从实际的工程选出的需求，依据上面的质量标准，评估每一个需求，看看有什么问题，而后用更好的方式重写。我将对每一个例子都提出本身的分析和改进的建议。也欢迎你提出不一样的看法。我所占优的只是我知道每一个需求的出处。由于你我都不是真正的客户，咱们只能猜想每一个需求的意图。

　　例1．“产品应在很多于每60秒的正常周期内提供状态信息”

　　这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。咱们在谈论产品的哪部分？状态信息间隔真的假定为很多于60秒？，甚者每10年显示一条新的状态信息也能够？也许它的意图是消息间隔不该超过60秒，那么1毫秒是否是过短？“每”这个词致使了不肯定性。问题的后果，就是需求的不可证明。

　　弥补缺陷，重写需求的一种方法：

　　一、状态信息 　　1．1后台任务管理器因该以偏差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息 　　1．2若是后台进程处理正常，那么应该显示任务已完成的百分数/比 　　1．3任务完成时，应显示相关的信息 　　1．4后台任务出错应该显示错误信息

　　为了分别测试和追踪，我将其分红了多个需求。若是将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。

　　例2．“产品应瞬间在显示和隐藏不可打印字符间切换”

　　计算机在瞬间不能作任何事，因此这个需求不切实可行。它的不完整性表如今没有声明触发状态切换的条件。软件要在某些条件下更改本身？或者用户为了模仿更改要作一些动做？并且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其余的？这也是个模糊的问题。不可打印字符合隐藏字符同样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证明。

　　象这样编写需求也许更好一些：“用户可以在一个由特定触发条件激活处于编辑的文档中在显示和隐藏全部HTML标记间切换”。如今就很清楚，不可打印字符是HTML标记。因为没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操做。

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

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

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

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

　　编写质量需求的方针

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

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

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

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

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

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

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

　　若是你听从了这些方针，你可以尽早地常常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠定石。而且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会获得什么

（出处：DelphiFans.com）