如何写一个好的需求？

在项目管理中，每个人都在谈论需求和分类，如技术、软件、 功能、 业务 和 非功能。但是你有没有考虑过什么才是好的需求？

一个好的需求应该是清晰、完整和正确的。后者意味着最终交付解决了业务需求。用简单的语言编写的明确要求可以提高理解。一个完整的需求会考虑所有相关的利益相关者。

业务分析知识体系 (BABOK) 将需求定义为“需求的可用表示”。从本质上讲，这些条件会成为项目的指导思想并回答以下问题：

1. 工具或过程将做什么？ 
2. 它将如何实现？ 
3. 有什么限制？

在这篇文章中，我们将专注于“可用”这个词，这将帮助我们理解我们应该如何编写需求。因此，如果我们想要交付满足用户需求的项目并为他们提供他们想要的解决方案，我们需要确保我们的需求符合目的。

然而，许多其他属性是一个很好的要求，我建议您在帖子中查看所有这些属性，以便您可以编写出完美的要求。该帖子将包含完整列表，探讨需求各个方面的重要性，并提出提高质量的方法。 

什么时候应该考虑需求的质量？

您应该在项目的需求工程阶段审查并编写所有需求，从而避免在执行阶段出现陷阱。当然，您可以通过明智地考虑每个要求的明确性来解决很多问题。

但是，拥有一个完整的清单总是有帮助的，以确保您没有错过任何一件事，并且您的项目将顺利进行，每个人都知道需要做什么。 

良好需求的14个品质是什么？

要编写高质量的需求，我们应该考虑以下14 种质量。当您构建项目需求时，它们可以作为清单。

1. 清晰或可理解
2. 完全的
3. 正确的
4. 可测试
5. 优先
6. 可追溯
7. 可实现的
8. 分类
9. 相关的
10. 简洁的
11. 独特的
12. 合规
13. 拥有
14. 持续的

哇，这是一个很长的清单，但我向你保证，它会让你的要求在最后变得一清二楚。怎么可能不行？此外，它将为您省去很多麻烦。因此，让我们通过一些示例来探索每个属性。

1. 明确或可理解的要求

为什么明确或可理解的要求很重要？

如果您编写了需求，您将希望确保其他人理解它。然而，仅仅写一个没有拼写错误或语法错误的需求是不够的。您需要确保来自不同背景或不同经验水平的人都可以遵循它。 

有些人只会更多的技术和一些业务重点。然而，他们都需要了解您所写的内容。项目是一项团队运动，很可能需要多人参与。 

您如何确保需求清晰易懂？

如果您感谢您的要求的读者群，这将有所帮助。调查它们适合业务与技术知识规模的位置，并相应地调整您的文档。如果您必须为商业读者添加一些技术方面的内容，请确保您在文档中解释了含义。如果您有业务领域术语并且需要技术人员来理解它们，则同样适用。甚至可能包括涵盖所有基础的术语表。 

最后，您可以确保需求不会太难阅读并具有出色的可读性指标。您可以使用 Microsoft Word 或 Grammarly 等工具，我目前正在使用这些工具来撰写这篇文章。我认为 Grammarly 有一些很棒的工具可以在很多方面改进你的写作。

良好的需求示例

一辆新的电动自行车应配备能够支持 100 英里（或 160 公里）的自行车续航里程的电池。 

2. 完成要求

为什么完整的要求很重要？

完整性很难实现。目标是包含成功项目所需的所有要求。因此，我们需要更全面地研究项目的整个需求集，并问自己它们是否共同涵盖了整体业务需求或目标。 

然而，很难知道你不知道的事情，但你仍然应该知道。否则，项目可能会失败。那么，如何解决这个无法解决的问题！？

你如何确保需求是完整的？

首先，您应该通过利益相关者分析了解所有利益相关者。查看我关于 利益相关者管理的帖子。让利益相关者和主题专家 (SME) 审查需求，并询问尚未涵盖的内容。

其次，检查您的需求是否涉及所有范围元素，这些元素应该在项目管理过程的早期定义。 

第三，与主要利益相关者组织一次研讨会并通过用例。假设会议利益相关者描述的流程步骤不一致，然后恭敬地向业务部门提出解释。您应该能够引发讨论（而不是争论）以消除一些未知数并改进您的要求。

3.正确的要求

为什么正确的要求很重要？

这个问题其实有两个答案。 

• 我们已经回答了一个问题，即确保最终产品满足用户需求。因此，我们在整篇文章中讨论的所有标准都使需求正确。
• 但是，我们可以考虑第二个答案。当它捕捉到项目首先要做什么时，需求是正确的，即解决特定的业务问题。

请记住，我们还不想捕获解决方案，我们应该保持我们的需求解决方案不可知论。如果您将解决方案作为要求包括在内，市场上可能会有不同的出色解决方案将被丢弃或不考虑。

如何确保需求是正确的？

考虑帖子中讨论的所有标准。

另外，想想每个需求是否解决了企业试图解决的问题或问题。

对于您的所有要求，请考虑您是否提供解决方案而是描述需求。

4. 可测试要求

为什么可测试的需求很重要？

每个项目都会有一个测试阶段。当您构建系统或更改流程时，您希望确保它最终能够正常工作。因此，您需要以可以完成测试的方式列出您的要求。 

为了使它们可测试，我们需要确保我们的要求是具体的、客观的（即与主观相反）和可测量的。如果您的文件中没有记录详细信息，您将无法知道特定测试结果是成功还是失败。

如何确保需求是可测试的？

好吧，您想要查看您的需求并添加尽可能多的具体和可衡量的属性。如果电动自行车一次充电需要行驶 160 公里，那么这就是您提出的要求。另外，拥有这些特定数字会使要求变得客观。

想象一下，要求说：“电动自行车一次充电就能达到可接受的续航里程。” 谁决定的！？什么可以接受！？在这些情况下，您仍然有出路；您可以在文档中放置特定的高级人员来做出决定。

5. 优先要求

为什么优先需求很重要？

所有追求利润的企业都希望最大化他们使用资源所获得的价值。项目在商业环境中运作，当然，我们也希望如此。所有项目都有时间、成本和范围三重约束，这会影响项目结果的质量。 

我们不能为所有需求提供所有资源，也不是所有需求都是平等的。因此，我们需要在发起人的帮助下决定解决方案中包含哪些需求，哪些不会带来太大价值。 

如果您正在运行一个处理工作包的项目，例如敏捷项目，那么优先级是必不可少的。敏捷框架用于重复项目，你总是先完成最高优先级的需求，并定期打包发布。

您如何确保要求优先考虑？

最好先与提出要求的人讨论优先级。如果要求来自文件或流程，则可能由发起人来决定。 

根据业务和项目目标审查需求的重要性。如果您发现业务目标和优先级之间存在差异，请与提出要求的高级利益相关者进行澄清。 

如果高级利益相关者之间对每个要求的重要性存在分歧，请与他们进行更广泛的讨论。您可能需要升级到更高的管理层，例如指导委员会(SteerCo)。

6. 可追溯的需求

为什么可追溯的需求很重要？

您的要求可能来自各种来源，例如采访记录、研讨会甚至非正式的茶歇。然而，当您将所有内容合并到一个需求文档中时，您可能会失去来源。这可能是个问题。 

了解源头很重要，因为当您完成需求分析或需要澄清开发中的任何内容时，您可能需要返回源头以获取更多详细信息，甚至挑战需求。

如何确保需求是可追溯的？

有几种方法可以确保质量。首先比较直接，在文档中记录需求的来源。 

第二个类似。您想创建一个可追溯矩阵，通过启发、构建和测试来跟踪需求。它有助于跟踪源并确保您的所有需求都已得到解决和测试。

7. 可达到的要求

为什么可实现的要求很重要？

文档中存在无法实现的需求会带来一些风险。 

如果您在积压中保留无法实现的需求，您可能会创建错误的利益相关者期望您的项目计划完成这些。因此，它可能会在以后引起失望。

此外，由于误解，项目团队可能会无意中尝试解决无法解决的需求，从而分散他们对实际可实现的注意力的注意力。 

你如何确保要求是可以实现的？

简单的答案是您需要从需求文档中删除它们。也许只是将它们保留在附录中以备记录。但是，如果您不是自己做出这个决定，那将会有所帮助。 

该要求可能已在流程中作为可实现的目标开始，但环境的变化已经改变了状态。例如，您与技术团队讨论了需求，他们建议解决方案将超出时间或预算。您需要向利益相关者传达新信息，并要求增加资源或删除需求。如果他们无法做出决定，您可能需要升级到 SteerCo。然后相应地更新您的需求文档。

8. 分类要求

为什么分类要求很重要？

简单的答案是，将它们分组时更容易处理您的需求。假设您正在制造一辆电动自行车，那么您将希望与车架相关的所有功能需求都集中在一个地方。它可以帮助您查看依赖关系、查找重叠，甚至可以节省时间的区域。

您如何确保对需求进行分类？

您只需要找出在您的项目中有意义的各种组。该标准是使用 功能性或非功能性要求、 技术性和通用性的。看看我在这两个方面的帖子。当您有组时，请确保您可以过滤或至少在视觉上单独查看每个组。

九、相关要求

为什么相关要求很重要？

您希望您的要求具有相关性和重点，有两个原因。 

一是您要确保需求涉及您在项目早期达成的范围。如果您不处理范围元素，那么您正在管理范围之外的东西，这会引入“范围蔓延”。 

其次，可能是需求正在解决范围。然而，它实际上并没有为项目的整个需求集提供任何新信息，并且没有比您已经拥有的更好地描述业务需求。因此，它可能会给人们造成混乱和时间，让人们弄清楚是否存在差异。

你如何确保需求是相关的？

您可以做的第一件事是检查您的项目启动文件或参考条款（取决于项目）。你有什么作为一个范围，以及你的要求如何适应整个画面。然后验证您的需求是否有权单独存在。还是应该将它们与不同的要求结合起来？ 

假设您正在构建一个电动自行车车架，并且有一个将其制作成三角形金属车架的说明。然后在下一个要求中，您指定它应该是铝合金框架。所以，相反，你可以说我们需要一个三角形的铝合金框架。现在，它是相关且更简洁的，这是我们的下一个属性。

10. 简洁的要求

为什么简洁的要求很重要？

在这里，我们应该独立考虑单个需求和项目需求的整个列表。 

在单独考虑每个需求时，我们需要判断它是否切中要害，或者我们可以删除一些单词而不改变含义。你不应该使用像“为了达到 95% 的准确率……”这样的冗长短语，而不是使用“为了达到 95% 的准确率……”。 

除了研究个人需求外，我们还应该探索整个项目集。类似于我们的铝合金框架示例。如果没有遗漏关键信息，您应该尝试将两个相似的要求合二为一。另外，相似之处可能是因为我们用不同的词表达了相同的想法，或者采取了不同的方法来描述相同的问题或需求。

您希望避免这两种类型的问题，因为理解和处理需求需要时间，如果没有必要，那就是在浪费项目资源的时间。如果您改进您的要求，您和读者都可以专注于项目试图实现的要点。

如何确保需求简洁？

如您所见，我们可以做一些事情。 

一是明智并通读所有要求，考虑使用的特定单词是否提供任何其他重要信息。有时整个段落可能不相关或不重要。所以，你只需要按“删除”。

此外，如果这不会改变需求的含义，您可能需要将多个需求合并为一个。

最后，我们应该使用主动语态。在企业界，人们喜欢使用被动语态。这听起来可能更正式，但实际上，它阻碍了可读性。 

11. 独特要求

为什么独特的要求很重要？

唯一性链接回简洁和相关的需求。但是还有一个我们没有涉及的重复问题。 

如果您有两个相似的要求，但由于使用了特定的短语，它们相互矛盾。因此，它可能会导致执行问题，因为开发人员或项目团队可能会发现很难理解实际需要做什么。 

如何确保需求是唯一的？

在研究分类的、相关的和简洁的需求时，我们已经涵盖了一些内容。例如，您需要对需求进行分类以帮助您查看是否有任何重叠。

可追溯性策略也将在这里有所帮助。假设您遵循了之前的建议，您拥有出色的可追溯性地图。它将挽救您的生命，因为如果有相互矛盾的需求，您将能够识别来源或所有者，并找出需求是否确实重叠或不同。 

• 如果只是重复或重叠，您可以在利益相关者确认后删除或合并。
• 如果您发现这些实际上是不同的要求，您应该重新措辞以揭示差异。

12. 符合要求

为什么一致性要求很重要？

拥有标准格式有助于节省时间、减少错误并提高您自己和审阅者的可读性。每当您编写新需求时 ，您不必创建“战争与和平”。

敏捷用确切的故事格式很好地说明了一致性质量。它是这样的：“作为一个……我想要（去）……所以……”。 例如，“作为开发人员，我想在网站的标题中创建一个按钮。这样用户就可以轻松订阅时事通讯”。该结构告诉 您在哪里寻找“谁”、“什么”和“为什么”。

如何确保需求符合要求？

这将取决于您的项目使用的项目框架的类型；如果它是敏捷项目，您可以使用规定的格式。如果您的项目框架是瀑布或类似的，您可能需要为单个需求或整个业务需求文档 (BRD) 创建标准。如果这不是第一个项目，请不要忘记与您的企业核实；可能已经有可用的模板。

如果您是唯一一个进行需求分析的人，那么遵循格式可能很容易。尽管您可能希望就标准达成一致，但如果您有朋友，您将提前跟进。

13. 自有需求

为什么自有需求很重要？

每个需求都应该有一个可以决定或解释的所有者，例如澄清需求、解决两个相似需求之间的差异或批准更改。另外，当项目完成执行时，我们需要这个人来确认项目是否按预期交付了需求。 

在许多项目中，业主将是项目发起人，他们经常提供预算。尽管如此，情况并非总是如此，其他一些高级利益相关者可能是需求的所有者。 

如果您没有明确的所有者，那么您将没有人可以验证您是否按照预期执行了所有操作。如果在项目中需要更改，则没有人批准。所以，简而言之，如果没有明确的方向，项目就会停滞不前。

你如何确保需求被拥有？

当有人提出新的需求时，您应该在开始时将请求者记录为所有者。然而，所有者可能会通过项目而改变。

因此，如果您发现更高级别的经理最终需要签署新要求，请更新您的文档。这样，您将始终有人可以进行任何澄清。

14. 一致的要求

为什么一致的要求很重要？

一致性就是在整个项目中传递相同的信息或含义。如果您说特定需求是针对客户的，则需要确保该客户在其他需求中具有相同的含义。 

此外，不同的需求不应包含相互矛盾的信息，因为这会使项目团队感到困惑并降低成功的可能性，即交付业务所要求的。 

你如何确保需求是一致的？

做的简单的事情是交叉检查您分配给多个单词的要求和各种含义。 

为了更加彻底，您可以创建术语表或词典来解释每个概念并避免任何可能的不一致。您还可以在您的标准操作程序 (SOP) 中重复使用术语表来实现相同目的。

编写好的需求结论

我希望在阅读完这篇文章后，您可以看到一些方法可以改善您当前的项目需求并增加成功的概率。我们去做一些质量要求吧！？一个好的需求不仅是有趣的东西，而且在项目后期消除了许多令人头疼的问题。 

不幸的是，对于需求，它并不像记录利益相关者告诉您的所有内容那么简单。作为一个项目团队，我们需要确保我们有质量要求，我们可以在整个项目到最终交付中使用这些要求。

让我知道您是否曾经以多种方式考虑过良好的需求。但是，我敢肯定，如果您之前因要求而有任何问题，那么帖子中的一项品质将在未来解决这些问题。

更多产品经理资源，请关注我们的资源网站：

都有吧资源网站（产品经理资源网），为互联网人提供最优质的学习、娱乐等综合资源！提高工作效率，提升个人核心竞争力，丰富业余生活！

资源网站：https://www.douyoubuy.cn

DUB官方网站：https://zy.douyoubuy.cn