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

《如何编写高质量“软件需求说明书”.docx》由会员分享，可在线阅读，更多相关《如何编写高质量“软件需求说明书”.docx（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、如何编写高质量“软件需求说明 书”现在你正在设计其中的一个特性，已经发现了需求的一 些问题。你可以用多种不同的方式解释需求15；需求9的说 明正好与需求21相反，你因该相信哪一个？需求24非常含 糊，你根本不明白它的意思；你不得不花上一个小时与2位 开发人员讨论需求30,只因为你们对其各有各的理解；并 且，唯一能够澄清这些问题的客户没有给你们答复。你被迫 破解众多需求的含义，并且你能预料到，如果你错了，你要 做大量的重复工作。许多软件需求说明书（SRS）写得非常糟糕。任何产品的 质量需要其原始材料的质量保证，糟糕的软件需求说明书不 可能产出优秀的软件。不幸的是，几乎没有开发人员受过与 需求的抽

2、象、分析、文档、质检有关的教育。而且，没有非 常多的好需求可以借鉴学习，局部原因是很少有工程可以找 到一个好的借鉴，其他原因是公司不愿意将其产品说明书放 在公共区域。本文描述了高质量需求表达和解释的几个特征。我们会用 这些观点去检查一些有缺陷的需求，痛改前非。我将谈谈如 何写好需求的一些技巧。您可能希望通过这些质量标准来评 估您的工程需求。对于修改，可能会晚一些，但你会学到有 用的东西，帮助你的小组下次写出更好的要求。不要期望能够编写出一份能表达需求应具备的所有特性 的SRS。无论你怎么细化、分析、评论和优化需求，都不可能到达完美。但是，如果你牢记这些特性，你就会编写出更好 的需求，生产出更好

3、的产品。高质量需求表达的特性 我们如何从一些有问题的需求中分辨出好的软件需求?这一节将分别介绍需求表达应表达的6个特性，下一节将从 整体上介绍SRS文档应具备的特性。判断每个需求是否具备 应有的特性的一种方式是由持有不同观点的工程资金管理人 所作的正规检查。另一种有力的方法是在编写代码前依据需 求编写测试例子。测试例子能够明确显现在需求中描述的产 品行为（特性），能够显现缺陷、冗余和含糊之处。正确：每个需求必须准确描述要交付的功能。正确性依赖 于需求的来源，比方真实的客户或者高层次的系统需求规 范。一个软件需求与其对应的系统需求规格说明书冲突是不 正确的（当然系统需求规格说明书本身也不一定正确

4、）。只有用户的代表能够决定用户需求的正确性，这就是为 什么在检查需求时，要包括他们或他们的代理的关键所在。 不包括用户的需求检查就会导致开发人员的：“这是没意义 的“，“这可能是他们的意思”等众所周知的猜想。可行性：在的能力、有限的系统及其环境中每个需 求必须是可实现的。为了防止需求的不可行性，在需求分析 阶段应该有一个开发人员参与，在抽象阶段应该有市场人员 参与。这个开发人员应能检查在技术上什么能做什么不能 做，哪些需要需要额外的付出或者和其他的权衡。必要性：每个需求应载明什么是客户确实需要的，什么 要顺应于外部的需求，接口或标准。每个需求源于你认可、 具有权说明需求的原始资料，这是考虑必需

5、的另外情形（译 注，此句翻译不顺，请参照原文：Another way to think of“necessary“ is that each requirement originated from a source you recognize as having the authority to specify requirements) o跟踪每个需求回溯到出处，如 用例，系统需求，规章，或来自其他用户的意见。如果你不 能标识出处，可能需求只是个镀金的例子，没有真正的必 须。优先权：为了说明在一个详细的产品版本中应包含哪些 要点，需要为每个需求，特征，或用例分配实现的优先权。 客户或其代理都

6、应有强烈的责任建立优先权。如果所有的需 求都被视为同等重要，那么由于在开发中，预算削减，计划 超时或组员的离开导致新的需求时，工程经理将不能起到作 用。优先权的作用是提供给客户的价值，实现的相关费用， 实现相关联的有关技术风险。我是用3种级别的优先权：高优先权说明需求必须表达 在下一个产品版本中，中优先权说明需求是必须的，但是如 果需要可以推迟到晚一些的产品版本中，低优先权说明有它 很好，但我们必须认识到如果没有充足的时间或资源，它可 以被放弃掉。明确：需求表达的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极 易导致含糊。要防止使用一些对于SRS作者很清楚但

7、对于读 者不清楚的主观词汇，如：用户友好性，容易，简单，快 速，有效，几个，艺术级，改善的，最大，最小等等。每写 一个需要都应简洁，简单，直观的采用用户熟知的语言，不 要采用计算机术语。检查需求模糊的有效方式包括需求说明 书的正规检查，根据需求写测试，建立用户的假想来说明产 品某个特定局部预期的特性。验证:看能不能制定一个测试计划或者其他的验证方法， 比方检查和演示，来确定产品中的每一个需求是否正确实 现。如果需求是不可验证的，那么决定需求是否被正确实现 就是一个判断的问题。不一致、不可行和不清晰的需求也会 导致不可验证。任何需求，如果产品将支持任何东西，也是 无法验证的。高质量需求说明的特征

8、一个完整的SRS不仅是包括长长的功能性需求列表，还 包括外部接口描述和一些诸如质量属性，期望性能的非功能 性需求。下面描述了高质量的SRS的一些特性。完整：不应该遗漏要求和必需的信息。完整性也是一个 需求应具备的。发现缺少的信息很难，因为根本不存在。在 SRS中将需求以分层目录方式组织，将帮助评审人员理解功能 性描述的结构，使他们很容易指出遗失的东西。在需求抽象时，相对于系统功能，你过多的注意用户的 业务，将导致在需求的全局观和引进不是真正必需的需求上 显得缺乏。在需求抽象上，应用用例方法会发挥很好的作 用。能够从不同角度观察需求的图形分析模型也可以检查出 不完整性。如果你知道已缺少一些信息，

9、使用TBD (to be determined)标准标志可以突出这些缺陷，当你在构建产品 的相关局部时，就可以从一个给定的需求集中解决所有的缺 陷。一致性：一致性需求就是不要于其他的软件需求或高级 别的系统(商业)需求发生冲突。需求中的不一致必须在开 发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的局部，没有审定 于修改相关的局部，就可能导致不一致性。可修改性：当每个需求的要求修改了或维护其历史更改 时，你必须能够审定SRS。也就是说每个需求必须相对于其他 需求有其单独的标示和分开的说明，便于清晰的查阅。通过 良好的组织可以使需求易于修改，如：将相关的

10、需求分组， 建立目录表，索引，以及前后参考（照）。可追溯性:你应该能够将一个软件与其原始材料相匹配， 比方高层系统需求、用例、用户建议等。它还可以将软件需 求与用于构建和验证需求的设计元素、源代码和测试相对 应。可追溯的需求应独立标注，详细且有结构，不能过大， 不能是表达性文本和公告清单。需求质量的评审 这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了表达得更 切合实际，我们做个小练习。下面有几个从实际的工程选出 的需求，依据上面的质量标准，评估每个需求，看看有什么 问题，然后用更好的方式重写。我将对每个例子都提出自己 的分析和改进的建议。也欢迎你提出

11、不同的见解。我所占优 的只是我知道每个需求的出处。因为你我都不是真正的客 户，我们只能猜想每个需求的意图。例1.“产品应在不少于每60秒的正常周期内提供状态 信息”这个需求是不完整的：状态信息是什么，如何显示给用 户。这个需求有几处含糊。我们在谈论产品的哪局部？状态 信息间隔真的假定为不少于60秒？，甚者每10年显示一条 新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？ “每”这个词导致了不确定 性。问题的后果，就是需求的不可证实。弥补缺陷，重写需求的一种方法:1、状态信息2 .后台任务管理器因该以误差上下不超过10秒的60秒 间隔，在用户界面的指定位置显示状态

12、信息3 .如果后台进程处理正常，那么应该显示任务已完成的 百分数/比.任务完成时，应显示相关的信息后台任务出错应该显示错误信息为了分开测试和跟踪，我把它分成了多个需求。如果几个 需求连接在一个局部中，那么在构建和测试过程中很容易遗 漏一个。例2.“产品应瞬间在显示和隐藏不可打印字符间切换”计算机在瞬间不能做任何事，所以这个需求不切实可 行。它的不完整性表现在没有声明触发状态切换的条件。软 件要在某些条件下更改自己？或者用户为了模仿更改要做一 些动作？而且，在文档中改变显示的范围是多大：选中的文 本，整个的文档，或其他的？这也是个模糊的问题。不可打 印字符合隐藏字符一样吗？或者是一些属性标志或一

13、些控制 字符？问题的后果，就是需求的不可证实。象这样编写需求也许更好一些：“用户能够在一个由特 定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标 记间切换”。现在就很清楚，不可打印字符是HTML标记。由 于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操 作。例3.“HTML分析器可以产生HTML标记错误报告，帮助 HTML入门者快速解决错误”。单词“快速”使其模糊，没有 加进错误报告的定义也是其部完整。我不知道，你怎么验证 这个需求。找一个自称为HTML的入门者，看看能不能根据错 误报告快速解决错误？试试这个：“HTML分析器可以产

14、生一个错误报告，错误 报告包含有在被分析文件中出错的HTML文本和行号以及错误 的描述。如果没有错误，就不会产生错误报告“。现在我们 知道了，什么会被加到出错报告中，但是出错报告是个什么 样子，那么留由设计人员决定。我们还指定了一个例外：如果 没有发现错误，不产生错误报告。例4.“如果可能，主管号码应通过联机校验，而不是通 过主全体主管号码列表校验”。真感到绝望，什么是“如果 可能“：如果技术上可行？如果主全体主管号码列表可以联 机获得？要防止象“应该”的这类不确切的词。客户是需要 这个功能性还是不需要。我曾看过一些需求说明书，采用诸 如：应，将，应该/将要等一些词描述优先级的细微差异。但 我

15、更喜欢用“应”清楚的说明需求的意图，指明优先级。这 是修改后的：系统应校验输入的主管号码而不通过联机的主 全体主官号码列表。如果在列表中没有发现主管号码，将会 显示一条错误信息，也不接受指令。在理解每一个完成的坏需求时，开发人员会遇到一个难题: 在评审需求并达成共识之前，开发人员和客户会有一个激烈 的争论。详细检查大型需求文档不是一件容易的事情。我知 道有些人做到了，他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨，在这个阶段修复缺陷是廉价 的。编写质量需求的方针写出优秀的需求没有公式化的方法。这需要大量的经验, 你要从过去的文档中发现的问题中吸取教训。在组织软件需 求文档时，请

16、严格遵循这些指南。句子和段落要短。采用主动语气。使用正确的语法，拼 写，标点。使用术语，要保持一致性，并在术语表或数据字 典中定义它们要看需求是否被有效的定义，可以以开发人员的观点看 看。在内心将“当你们做完了找我”这句加到文档尾部，看 看能不能是你紧张起来。换句话说，你是否需要SRS的编写 者的额外解释帮助开发人员很好的理解需求，以便于设计和 实现？如果是的话，在继续工作前，需求还需要细化。需求编写人员还应该努力正确把握细化的程度。防止有多 个需求的长篇叙事段落。一个有用的提示是编写独立的可测 试需求。如果你认为少量的测试就可以验证一个需求的正确 性，那么它已经被正确的提炼了。如果您预计到各

17、种不同类 型的测试，那么几个需求可能被挤在一起，需要被拆分。密切关注多个需求合成了单个需求。一个需求中的连接 词“和” / “或”建议几个需求合并。不要在一个需求中使用 “和”/“或”。通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分 离开，而“产品应能对来自语音编辑指示做出反响”应作为 一个子系统，不应作为单个的功能性需求。防止在SRS中过多的申述需求。在多处包含相同的需求 可以使文档更易于阅读，但也会给文档的维护增加困难。文 档的多份文本要在同一时间内全部更新，防止不一致性。如果你遵从了这些方针，你能够尽早地经常正式或非正 式的审查需求，这些需求对于产品的构造，系统测试以及最 后的客户满意，都会成为好的奠基石。并且要记住，没有高 质量的需求，软件就象一盒巧克力，你永远不知道你会得到 什么。