如何编写一个 好的需求

-精选财经经济类资料- -最新财经经济资料-感谢阅读- 1 如何编写一个好的需求 如何编写高质量需求 Karl E Wieger Process Impact 许多软件需求说明书写得非常糟 糕。任何产品的质量需要其原始材料的 质量保证，糟糕的软件需求说明书不可 能产出优秀的软件。不幸的是，几乎没 有开发人员受过与需求的抽象、分析、 文档、质检有关的教育。而且，没有非 常多的好需求可以借鉴学习，部分原因 是很少有工程可以找到一个好的借鉴， 其他原因是公司不愿意将其产品说明书 放在公共区域。 这篇文章描述了高质量需求叙述 和说明的几个特性。我们将用这些观点 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 2 检查一些有缺陷的需求，带着痛楚重新 编写。而且我会谈一些如何编写好的需 求的提示。你也许想通过这些质量标准 评估你的工程需求。对于修订，也许迟 了，但你会学到一些有用的东西，并帮 助你的小组在下次编写出更好的需求。 不要期望能够编写出一份能体现 需求应具备的所有特性的 SRS。无论你 怎么细化、分析、评论和优化需求，都 不可能达到完美。但是，如果你牢记这 些特性，你就会编写出更好的需求，生 产出更好的产品。 一、高质量需求说明书的特性 我们如何从一些有问题的需求中 分辨出好的软件需求？判断每个需求是 否具备应有的特性的一种方式是由持有 不同观点的工程资金管理人所作的正规 检查。另一种有力的方法是在编写代码 前依据需求编写测试例子。测试例子能 够明确显现在需求中描述的产品行为， 能够显现缺陷、冗余和含糊之处。 ? 正确： -精选财经经济类资料- -最新财经经济资料-感谢阅读- 3 每个需求必须精确描述要交付的 功能。正确性依据于需求的来源，如真 实的客户或高级别的系统需求说明书。 一个软件需求与其对应的系统需求说明 书相抵触是不正确的。 只有用户的代表能够决定用户需 求的正确性，这就是为什么在检查需求 时，要包括他们或他们的代理的关键所 在。不包括用户的需求检查就会导致开 发人员的：“ 这是没意义的 ”， “这可能是他们的意思” 等众所周 知的猜测。 ? 可行性： 在已知的能力、有限的系统及其 环境中每个需求必须是可实现的。为了 避免需求的不可行性，在需求分析阶段 应该有一个开发人员参与，在抽象阶段 应该有市场人员参与。这个开发人员应 能检查在技术上什么能做什么不能做， 哪些需要需要额外的付出或者和其他的 权衡。 ? 必要性： -精选财经经济类资料- -最新财经经济资料-感谢阅读- 4 每个需求应载明什么是客户确实 需要的，什么要顺应于外部的需求，接 口或标准。每个需求源于你认可、具有 权说明需求的原始资料，这是考虑必需 的另外情形。跟踪每个需求回溯到出处， 如用例，系统需求，规章，或来自其他 用户的意见。如果你不能标识出处，可 能需求只是个镀金的例子，没有真正的 必须。 ? 优先权： 为了表明在一个详细的产品版本 中应包含哪些要点，需要为每个需求， 特征，或用例分配实现的优先权。客户 或其代理都应有强烈的责任建立优先权。 如果所有的需求都被视为同等重要，那 么由于在开发中，预算削减，计划超时 或组员的离开导致新的需求时， 项目 经理将不能起到作用。优先权的作用是 提供给客户的价值，实现的相关费用， 实现相关联的有关技术风险。 我是用 3 种级别的优先权：高优 先权表明需求必须体现在下一个产品版 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 5 本中，中优先权表明需求是必须的，但 是如果需要可以推迟到晚一些的产品版 本中，低优先权表明有它很好，但我们 必须认识到如果没有充足的时间或资源， 它可以被放弃掉。 ? 明确： 需求叙述的读者应只能从其得到 唯一的解释说明，同样，一个需求的多 个读者也应达成共识。自然语言极易导 致含糊。要避免使用一些对于 SRS 作者 很清楚但对于读者不清楚的主观词汇， 如：用户友好性，容易，简单，快速， 有效，几个，艺术级，改善的，最大， 最小等等。每写一个需要都应简洁，简 单，直观的采用用户熟知的语言，不要 采用计算机术语。检查需求模糊的有效 方式包括需求说明书的正规检查，根据 需求写测试，建立用户的假想来说明产 品某个特定部分预期的特性。 ? 可证实： 看你是否能够做出测试计划或其 他验证方式，如检查和实证，来决定在 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 6 产品中每个需求是否正确的实现。如果 需求是不可验证的，决定需求是不是正 确的实现就成了判断的事。需求之间不 一致，不可行，不明确也能导致不可证 实。任何需求如果说产品将要支持什么 也是不可证实的。 ? 完整： 不应该遗漏要求和必需的信息。 完整性也是一个需求应具备的。发现缺 少的信息很难，因为根本不存在。在 SRS 中将需求以分层目录方式组织，将 帮助评审人员理解功能性描述的结构， 使他们很容易指出遗失的东西。 在需求抽象时，相对于系统功能， 你过多的注意用户的业务，将导致在需 求的全局观和引进不是真正必需的需求 上显得不足。在需求抽象上，应用用例 方法会发挥很好的作用。能够从不同角 度察看需求的图形分析模型也可以检查 出不完整性。 如果你知道已缺少一些信息，使 用 TBD 标准标志可以突出这些缺陷， -精选财经经济类资料- -最新财经经济资料-感谢阅读- 7 当你在构建产品的相关部分时，就可以 从一个给定的需求集中解决所有的缺陷。 ? 一致性： 一致性需求就是不要于其他的软 件需求或高级别的系统需求发生冲突。 需求中的不一致必须在开发开始前得到 解决。只有经过调研才能确定哪些是正 确的。修改需求时一定要谨慎，如果只 审定修改的部分，没有审定于修改相关 的部分，就可能导致不一致性。 ? 可修改性： 当每个需求的要求修改了或维护 其历史更改时，你必须能够审定 SRS。 也就是说每个需求必须相对于其他需求 有其单独的标示和分开的说明，便于清 晰的查阅。通过良好的组织可以使需求 易于修改，如：将相关的需求分组，建 立目录表，索引，以及前后参考。 ? 可追踪： 你应能将一个软件与其原始材料 相对应，如高级系统需求，用例，用户 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 8 的提议等。也能够将软件需求与设计元 素，源代码，用于构造实现和验证需求 的测试相对应。可追踪的需求应该具有 独立标示，细密和结构化的编写，不应 过大，不应是叙述性的文字和公告式的 列表。 二、需求质量的评审 这些有关需求质量的特性的描述 在理论上都是非常好的，但一个好的需 求到底是个什么样子的呢？为了体现得 更切合实际，我们做个小练习。下面有 几个从实际的工程选出的需求，依据上 面的质量标准，评估每个需求，看看有 什么问题，然后用更好的方式重写。我 将对每个例子都提出自己的分析和改进 的建议。也欢迎你提出不同的见解。我 所占优的只是我知道每个需求的出处。 因为你我都不是真正的客户，我们只能 猜测每个需求的意图。 例 1 “产品应在不少于每 60 秒的 正常周期内提供状态信息” 这个需求是不完整的：状态信息 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 9 是什么，如何显示给用户。这个需求有 几处含糊。我们在谈论产品的哪部分？ 状态信息间隔真的假定为不少于 60 秒？ ，甚者每 10 年显示一条新的状态信息 也可以？也许它的意图是消息间隔不应 超过 60 秒，那么 1 毫秒是不是太短？ “每”这个词导致了不确定性。问题的后 果，就是需求的不可证实。 弥补缺陷，重写需求的一种方法： “1、状态信息 1.1 后台任务管理器因该以误差 上下不超过 10 秒的 60 秒间隔，在用户 界面的指定位置显示状态信息 1.2 如果后台进程处理正常，那 么应该显示任务已完成的百分数/比 1.3 任务完成时，应显示相关的 信息 1.4 后台任务出错应该显示错误 信息 为了分别测试和追踪，我将其分 成了多个需求。如果将几个需求串接在 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 10 一节中，在构造和测试时就很容易漏掉 一个。 例 2. “产品应瞬间在显示和隐藏 不可打印字符间切换” 计算机在瞬间不能做任何事，所 以这个需求不切实可行。它的不完整性 表现在没有声明触发状态切换的条件。 软件要在某些条件下更改自己？或者用 户为了模仿更改要做一些动作？而且， 在文档中改变显示的范围是多大：选中 的文本，整个的文档，或其他的？这也 是个模糊的问题。不可打印字符合隐藏 字符一样吗？或者是一些属性标志或一 些控制字符？问题的后果，就是需求的 不可证实。 象这样编写需求也许更好一些： “用户能够在一个由特定触发条件激活 处于编辑的文档中在显示和隐藏所有 HTML 标记间切换” 。现在就很清楚， 不可打印字符是 HTML 标记。由于没 有定义触发条件，需求对设计没有约束 力。只有设计人员选定了触发条件后， -精选财经经济类资料- -最新财经经济资料-感谢阅读- 11 你才能编写测试验证触发的正确操作。 例 3 “HTML 分析器可以产生 HTML 标记错误报告，帮助 HTML 入 门者快速解决错误” 。 单词“ 快速” 使其模糊，没有加进 错误报告的定义也是其部完整。我不知 道，你怎么验证这个需求。找一个自称 为 HTML 的入门者，看看能不能根据 错误报告快速解决错误？ 试试这个：“HTML 分析器可以 产生一个错误报告，错误报告包含有在 被分析文件中出错的 HTML 文本和行 号以及错误的描述。如果没有错误，就 不会产生错误报告” 。现在我们知道了， 什么会被加到出错报告中，但是出错报 告是个什么样子，则留由设计人员决定。 我们还指定了一个例外：如果没有发现 错误，不产生错误报告。 例 4 “如果可能，主管号码应通 过联机校验，而不是通过主全体主管号 码列表校验” 。 真到绝望，什么是“如果可能” ： -精选财经经济类资料- -最新财经经济资料-感谢阅读- 12 如果技术上可行？如果主全体主管号码 列表可以联机获得？要避免象“应该” 的 这类不确切的词。客户是需要这个功能 性还是不需要。我曾看过一些需求说明 书，采用诸如：应，将，应该/将要等一 些词描述优先级的细微差别。但我更喜 欢用“应”清楚的说明需求的意图，指明 优先级。这是修改后的：系统应校验输 入的主管号码而不通过联机的主全体主 官号码列表。如果在列表中没有发现主 管号码，将会显示一条错误信息，也不 接受指令。 在理解各个已完成的糟糕需求上， 开发人员将会遇到的难题是：开发人员 与客户将会在审核需求，未达成共识前 发生激烈的争论。详细检查大的需求文 档不是一件轻松的事情。我清楚有人做 过，而且他们花在检查上的每一分钟都 是值得的。相对于开发阶段和用户的抱 怨电话，在这个阶段修补缺陷是便宜的， 编写质量需求的方针 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 13 编写优秀的需求是没有公式化的 方法的。这需要大量的经验，要从你在 过去的文档中发现的问题学习。请在组 织软件需求文档时，严格遵从这些方针。 ? 句子和段落要短。采用主动语 气。使用正确的语法，拼写，标点。使 用术语，要保 持一致性，并在术语表或数据字 典中定义它们 ? 要看需求是否被有效的定义， 可以以开发人员的观点看看。在内心将 “当你们做完 了找我” 这句加到文档尾部，看 看能不能是你紧张起来。换句话说，你 是否需要 SRS 的编写者的额外解释帮助 开发人员很好的理解需求，以便于设计 和实现？如 果是的话，在继续工作前，需求 还需要细化。 ? 需求编写者还要努力正确地把 握细化程度。要避免包含多个需求的长 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 14 的叙述段落。 有帮助的提示是编写独立的可测 试的需求。如果你认为一小部分测试可 以验证一个需求的正确，那么它已经正 确的细化了。如果你预想到多种不同类 的测试，几个需求可能已挤到了一起， 需要拆分开。 ? 密切关注多个需求合成了单个 需求。一个需求中的连接词“和”/“或”建 议几个 需求合并。不要在一个需求中使 用“和”/“或”。 ? 通篇文档细节上要保持一致。 我曾看见过多个需求说明书前后不一致。 如：“对于 红色合法的颜色代码应是 R”及 “对于绿色合法的颜色代码应是 G”就有 可以以分散的需求分离开，而“产品应 能