编写良好需求的8个技巧

—

如果你是一名正在学习如何编写需求的软件开发人员，那么了解具体性至关重要。想象一下，你收到一个需求：“系统应该用户友好。”这是模糊且开放的，你可能认为这要求一个简单的界面，而你的同事则理解为系统应该高度可配置。

不明确的需求会导致混淆和相互矛盾的解释，进而引发返工、成本增加和进度延误。尽可能有效地编写和管理需求是产品取得成功的关键。工程师必须能够尽可能轻松地记录、分析和优先排序需求。此外，随着产品变得越来越复杂，可追溯性至关重要，因为它鼓励所有团队成员和利益相关者之间的透明度。当所有参与者都能实时跟踪变化时，组织通常会在产品质量、交付时间和效率方面看到改进。

需求是高质量软件的基础，随着软件变得越来越复杂，其需求也需要更加透明。没有良好的需求，开发人员、设计人员、测试人员和利益相关者可能会对最终产品应实现的目标有不同的理解。有了清晰、简洁的路线图，团队可以限制范围蔓延，并降低发生昂贵错误或沟通不畅的风险。

此外，编写良好的需求在整个开发生命周期中都是参考点，有助于团队专注于最初的目标，并允许进行更准确的进度跟踪和决策。了解良好需求的关键组成部分是确保新开发流程从一开始就走上正轨，并在整个开发过程中保持正轨的可靠方法。

—

在健全的需求管理流程中，创建需求待办事项清单是第一步。通过写下所有必要的需求，可以更容易地向开发人员传达或翻译用户需求。这些需求的集合还将支持所有参与团队成员、开发人员和利益相关者之间的沟通，使它们成为降低成本和提高整个过程透明度的有力工具。然而，这些需求的影响取决于它们被制定得有多好——清晰、简洁和直接的需求对于确保它们的成功至关重要。

编写需求时的常见错误包括：

• 使用错误或不一致的术语。

• 犯语法错误。

• 过于模糊或含混不清。

• 过于具体和冗长。

• 做出错误的假设。

• 描述如何实现某件事，而不是描述需要什么。

—

需求工程师需要非常注重细节，并确保以尽可能清晰的方式构建、表述和呈现需求。理想情况下，每个需求陈述（从用户的角度编写）应该：

• 包含用户角色：这确定了谁将与功能或特性进行交互。明确定义用户有助于确保需求是为正确的受众设计的。

• 解释用户如何从需求中受益：产品的价值必须清晰。这有助于保持对提供与更大目标和用户需求相一致的功能的关注。

• 概述需求将帮助实现的期望状态：每个需求都应该包括一个成功的基准，指示最终产品应该是什么样子。

• 如果相关，包括允许测试需求的指标：在可能的情况下，包括可量化的指标，如响应时间或性能基准，以便进行清晰的测试和验证。这使得更容易验证系统是否符合预期。

一个大致的经验法则是，需求应遵循一个简单的结构，如：

“‘某物’应‘提供具体动作’以实现‘期望结果’。”

这些构建块作为工程师在学习如何在开发周期开始时编写需求的检查清单，但它们并不是这个过程中唯一需要考虑的因素。重要的是要深入关注需求（确保它们易于理解且技术上正确），同时也要跳出细节（确认它们是可测试的，并且与更大的目标相一致）。对需求需要实现的目标采取整体视图，可以更容易地编写出长期有效的需求。

—

凭一时冲动，仅利用手头现有的信息来编写需求是很容易的。但多花几分钟时间却会带来截然不同的效果。建设性的需求应该始终是：

1. 必要的

问自己“三个W”：

• 我们将做什么？

• 我们为什么要做？

• 谁将从中受益？

如果你不能轻易地回答上述问题，那么很可能你并没有完全理解用户的需求。因此，你可能会包含实际上并不需要的需求，从而导致开发时间延长、成本增加以及焦点迷失。

2. 清晰的

一旦你确认了一个需求确实是必要的，那么就该开始编写了。在记录需求时，尽可能清晰、直接、无歧义是极其重要的。简单的句子能确保每个阅读它们的人都能以相同的方式理解其含义。为了确保最高清晰度，最好避免：

• 使用被动语态。

• 行业术语、行话、缩写、首字母缩写或任何不被广泛理解的术语（如果由于某种原因无法避免，别忘了将它们列入词汇表）。

• 可能以不同方式解释的副词（歧义）。

• 描述不应做什么的否定短语（相反，描述应该做什么）。

• 难以测试和验证的模糊表达。

3. 简洁且一致的

保持需求的简洁性至关重要——甚至有人说，如果内容不能写在一张便签上，那就太长了。通过保持信息简短且切中要点来优先考虑可读性。这使得利益相关者和开发人员更容易组织、吸收和分析项目的需求。然而，虽然简洁的需求是首选，但为了篇幅而省略关键信息是不可取的。需求应在充分传达所有相关信息的同时尽可能简洁。

在捕获需求时使用不一致的术语可能会导致混淆、错误和延误。在流程开始时创建一个项目词汇表将有助于确保所有人都在同一频道上。确保列出所有术语，它们之间不相互矛盾，并且用户和开发者的语言是一致的。在编写需求时参考这个词汇表，将确保你使用的术语对所有参与者来说都是一致且可理解的。

4. 准确的

即使你认为某个需求是必要的，再次检查也无伤大雅。确保需求中包含的所有信息都是正确的，并且你陈述的假设是有效的。验证每个需求的准确性和必要性可以避免在开发过程中可能出现的失误和昂贵的修订。

5. 可行的

在确认需求中的假设正确无误后，你需要确保你的陈述在技术上是可行的。首先，审视一下项目的预算和时间表，再看看你团队可用的资源。如果以当前的条件能够实际实施这个需求，那么它就可以被纳入项目计划中了。

6. 优先排序的

需求应该按类型分类，并据此进行优先排序。具体的类别因组织而异，但主要的需求类型包括：

• 功能需求

• 非功能需求

• 业务需求

• 系统需求

对需求进行分类使得利益相关者更容易阅读、管理和找出与他们角色最相关的需求。然后，按照重要性对它们进行优先排序，有助于准确界定项目的范围，并为每个需求的实施制定时间表。

7. 可验证的

在构建需求时，必须确保它们是可验证的，这意味着必须能够测试系统并证明它满足了需求。清晰、无歧义的语言是使验证可行的关键。像“最大化”或“最小化”、“容易”、“灵活”或“安全”这样的模糊术语很难衡量，并可能在测试过程中导致混淆。需求应该是具体和客观的，以便对系统性能进行具体评估，并允许需求的最后一个关键方面：可追溯性。

8. 可追溯的

可追溯性确保了需求与其他项目元素之间有清晰的联系。这使得项目经理、开发人员和利益相关者能够记录和跟踪每个需求的整个生命周期，无论是向前（到开发、测试和部署）还是向后（到业务和利益相关者目标）。当可追溯性得到妥善管理时，你可以最小化“游离”代码（即与需求无关的代码），并能够跟踪哪些需求被测试用例所覆盖。为了使需求可追溯，每个需求都应该被标记上一个唯一的标识符，并且其来源信息应该被清晰地记录下来。所有这些都需要在一个所有相关团队成员都可以访问的共享中央存储库中仔细跟踪。

可追溯性对于变更管理和合规性至关重要，它帮助团队理解变更的范围、复杂性和影响。通过保持需求与其他项目组件之间的清晰视线，团队可以评估单个需求的变更如何在开发周期中产生涟漪效应，影响时间线和其他资源。这种可见性对于监管合规性尤其重要，因为审计员可能需要验证特定的需求是否已根据行业标准得到满足和测试。此外，强大的可追溯性有助于识别需求实施过程中的任何不一致、缺口或错误，确保在开发过程中不会遗漏任何关键内容。

—

需求可以成就或破坏一个开发周期，而它们的撰写方式对其影响起着重要作用。当你掌握了编写清晰、简洁、直接的需求所需的所有信息时，你的团队就很容易取得成功。

良好的需求管理解决方案应提供以下功能：

• 集中化的文档管理

• 端到端的可追溯性

• 无缝集成

• 增强的协作和沟通

如果没有这些功能，团队可能会面临诸多障碍，导致沟通紧张，项目执行复杂。通过提供对项目数据的实时访问，解决方案为团队提供了编写更准确、更明智的需求所需的洞察力。通过了解依赖关系、资源限制和利益相关者反馈，可以确保需求不仅得到良好的记录，而且还基于项目的实际现实情况。