高质量需求分析

1、如何编写高质量 “软件需求说明书 ”你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写 软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种 不同的方式解释需求 15；需求 9 的说明正好与需求 21 相反，你因该相信哪一个？ 需求 24 非常含糊，你根本不明白它的意思； 你不得不花上一个小时与 2位开发人员 讨论需求 30，只因为你们对其各有各的理解；并且，唯一能够澄清这些问题的客户 没有给你们答复。你被迫破解众多需求的含义，并且你能预料到，如果你错了，你 要做大量的重复工作。许多软件需

2、求说明书（SRS）写得非常糟糕。任何产品的质量需要其原始材料 的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有 开发人员受过与需求的抽象、分析、文档、质检有关的 教育。而且，没有非常多的 好需求可以借鉴学习，部分原因是很少有工程可以找到一个好的借鉴，其他原因是 公司不愿意将其产品说明书放在公共区域。这篇文章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观 点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好的需求 的提示。你也许想通过这些质量 标准评估你的工程需求。对于修订，也许迟了，但 你会学到一些有用的东西， 并帮助你的小组在下次编写出更好

3、的需求。不要期望能够编写出一份能体现需求应具备的所有特性的SRSo无论你怎么细 化、分析、评论和优化需求，都不可能达到完美。但是，如果你牢记这些特性，你 就会编写出更好的需求，生产出更好的产品。高质量需求叙述的特性我们如何从一些有问题的需求中分辨出好的软件需求？这一节将分别介绍需求 叙述应体现的6个特性，下一节将从整体上介绍 SRS文档应具备的特性。判断每个 需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正 规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够 明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和含糊之处。正确：每个需求必须精

4、确描述要交付的功能。正确性依据于需求的来源，如真 实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相 抵触是不正确的（当然，系统需求说明书本身可能不正确）。只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要 包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：这是没意义的 ”， “这可能是他们的意思 ”等众所周知的猜测。可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为 了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应 该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需

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

6、识出处，可能需求只是个镀金的例子，没有真正 的必须。优先权：为了表明在一个详细的产品版本中应包含哪些要点， 需要为每个需求， 特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员 的离开导致新的需求时， 项目经理 将不能起到作用。 优先权的作用是提供给客户的 价值，实现的相关费用，实现相关联的有关技术 风险。我是用 3 种级别的优先权：高优先权表明需求必须体现在下一个产品版本中， 中优先权表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中，低优 先权表明有它很好，但我们必须认识到如果没有充足的时

7、间或 资源 ，它可以被放弃 掉。明确：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS 作者很清 楚但对于读者不清楚的主观词汇，如：用户友好性，容易，简单，快速，有效，几 个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁，简单，直观的采 用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明 书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的 特性。可证实：看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定 在产品中每个需求是否正确的实现。如果需求是不可验证

8、的，决定需求是不是正确 的实现就成了判断的事。需求之间不一致，不可行，不明确也能导致不可证实。任 何需求如果说产品将要支持什么也是不可证实的。高质量需求说明的特征一个完整的 SRS 不仅是包括长长的功能性需求列表， 还包括外部接口描述和一 些诸如质量属性， 期望性能的非功能性需求。 下面描述了高质量的 SRS 的一些特性。完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺 少的信息很难，因为根本不存在。在 SRS 中将需求以分层目录方式组织，将帮助评 审人员理解功能性描述的结构， 使他们很容易指出遗失的东西。在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的

9、 全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发 挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。如果你知道已缺少一些信息，使用TBD （to be determined）标准标志可以突出 这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有 的缺陷。一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发 生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些 是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定于修改相关 的部分，就可能导致不一致性。可修改性：当每个需求的要求修改

10、了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于 清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立 目录表，索引，以及前后参考（照）。可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用 户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的 测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大， 不应是叙述性的文字和公告式的列表。需求质量的评审这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底 是个什么样子的呢？为了体现得更切合实际，我们

11、做个小练习。下面有几个从实际 的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后 用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提 出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客 户，我们只能猜测每个需求的意图。例 1“产品应在不少于每 60 秒的正常周期内提供状态信息 ”这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60 秒？，甚者每10 年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那 么 1 毫秒是不是太短？ “每”这

12、个词导致了不确定性。问题的后果，就是需求的不可 证实。弥补缺陷，重写需求的一种方法：1、状态信息11后台任务管理器因该以误差上下不超过10秒的 60秒间隔，在用户界面的 指定位置显示状态信息12 如果后台进程处理正常，那么应该显示任务已完成的百分数/比13 任务完成时，应显示相关的信息14 后台任务出错应该显示错误信息为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中， 在构造和测试时就很容易漏掉一个。例 2“产品应瞬间在显示和隐藏不可打印字符间切换”计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在 没有声明触发状态切换的条件。软件要在某些条件下更改自己？

13、或者用户为了模仿 更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的 文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是 一些属性标志或一些控制字符？问题的后果， 就是需求的不可证实。象这样编写需求也许更好一些： “用户能够在一个由特定触发条件激活处于编辑 的文档中在显示和隐藏所有 HTML 标记间切换 ”。现在就很清楚，不可打印字符是HTML 标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定 了触发条件后，你才能编写测试验证触发的正确操作。例3. “HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速 解决错误 ”。

14、单词“快速”使其模糊，没 有加进错误报告的定义也是其部完整。我 不知道，你怎么验证这个需求。找一个自称为 HTML 的入门者，看看能不能根据错 误报告快速解决错误？试试这个：“ HTML分析器可以产生一个错误报告， 错误报告包含有在被分析文 件中出错的 HTML 文本和行号以及错误的描述。如果没有错误，就不会产生错误报 告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则 留由设计人员决定。 我们还指定了一个例外： 如果没有发现错误， 不产生错误报告。例 4. “如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表 校验”。真感到绝望，什么是 “如果可能 ”：如

15、果技术上可行？如果主全体主管号码列 表可以联机获得？要避免象 “应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优 先级的细微差别。但我更喜欢用 “应”清楚的说明需求的意图，指明优先级。这是修 改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在 列表中没有发现主管号码， 将会显示一条错误信息， 也不接受指令。在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客 户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一

16、分钟都是值得的。相 对于开发阶段和用户的抱怨电话， 在这个阶段修补缺陷是便宜的，编写质量需求的方针编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的 文档中发现的问题学习。 请在组织软件需求文档时， 严格遵从这些方针。句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语， 要保持一致性，并在术语表或数据字典中定义它们要看需求是否被有效的定义， 可以以开发人员的观点看看。 在内心将 “当你们做 完了找我 ”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果 是的话，在继续工作前，需求还需要细化。需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段 落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证 一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几 个需求可能已挤到了一起，需要拆分开。密切关注多个需求合成了单个需求。一个需求中的连接词“和”/或”建议几个需 求合并。不要在一个需求中使用 “和”/或”。通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如： 于红色合法的颜色代码