需求分析七宗罪之需求质量不高——复用性&可测性&可实现性

在整理需求时，应避免在文档中重复描述相同的内容。相反，应该只定义一次，并在其他相同的地方进行引用。这样做不仅增加了需求文档的可复用性，还可以避免由于需求变更而遗漏某个环节，从而导致错误的发生。

在梳理一个系统时，产品经理应该重点考虑以下内容的抽取和共通复用：

除了共通事项之外，我们通常会采用抽象的方式来提高文档的复用性。在需求文档中，除了重复的表达，可能还存在很多类似的表达方式。如果系统中存在大量相似的流程，我们应该对这些流程进行抽象处理。

此外，还可以通过状态的决策矩阵进行抽象，利用行状态和列操作的正交矩阵来覆盖所有的组合情况。这样做可以进一步提高文档的复用性。

可测性是指需求描述应该能够通过测试来验证其是否正确实现。可测性要求不仅适用于功能性需求，也适用于非功能性需求，并需要清晰地描述。

为了确保可测性，需要在测试用例设计方面提供明确的指导和参考。通过提供明确的指导和参考，可以确保测试用例的设计符合可测性要求。同时，可测试性的保障也有助于确保需求的一致性、完整性和准确性，同时提高项目的管理性。

1. 保证系统具备良好的性能

如果不描述具体的访问量和响应时间，这个需求就无法进行有效的测试。为了确保可测试性，需求应明确规定系统在何种访问量和响应时间下被认为具备良好的性能。

2.提升用户体验

如果不描述在什么情况下使用什么控件，测试人员将不知道如何进行测试。为了确保可测试性，需求应明确指定在何种情况下使用何种控件以提升用户体验，以便测试人员能够准确地进行测试。

3.保证系统易于使用

易于使用的标准对每个人可能都不同，这可能导致测试人员和开发人员对需求的理解不一致，从而产生争议是否是一个BUG。为了确保一致性，需求应明确定义系统易于使用的具体标准，以避免测试人员和开发人员之间的理解差异和争议。

除了上述问题，还需要考虑公司内部的设备资源是否满足测试要求。如果在测试阶段才发现无法搭建环境或缺乏特定依赖的设备，那就为时已晚了。因此，在需求阶段就要考虑到测试所需的设备资源，以确保测试的顺利进行。

相反，具备可测性的标准是什么？

1. 明确需求

需求描述应该清晰、简明、具体和明确，避免歧义和模糊性。确保需求描述能够准确传达所需功能或特性，避免误解和不必要的猜测。

2. 可衡量的需求

需求的描述应该是可量化的，可以通过一些标准或指标来衡量，例如时间、成本、性能等。这样可以确保需求的可验证性和可追踪性，便于后续的评估和验证。

3. 可测性

我们可以通过设计测试用例来验证需求是否满足。需求应该具备可测性，即能够通过测试来验证其正确实现。为了实现可测性，需求描述应该具备明确的测试目标和预期结果。

4. 需求确认

需要确认需求描述是否满足实际需求，否则设计出的测试用例也毫无意义。在需求确认阶段，相关的利益相关者应该对需求进行评审和确认，以确保需求描述准确反映了他们的期望和需求。

5.需求分解

将大的需求分解为小的需求，以便更好地实现可测性。通过将大的需求拆分为更小的、可测试的子需求，可以更好地管理和验证需求的实现。这样也有助于提高可测性和可追踪性，同时降低开发和测试的复杂度。

下面给大家列出了几个可实现性的标准：

1.技术可行性

需求是否符合现有的技术能力，是否需要进行新的技术研发或采购，是否需要额外的资源投入。产品经理需要与开发团队紧密合作，提供有关技术的详细信息，评估技术实现的难度和可行性。

2.时间可行性

3.操作可行性

需求是否能够被开发人员理解和执行。解决这个问题的方法有很多种，其中可视化需求分析是最有效的方法之一。通过可视化工具和技术，可以更清晰地传达需求，减少误解和沟通障碍。

4.成本可行性

需求是否符合组织的资源能力，包括人力、物力和财力。需求是否符合可接受的成本限制。产品经理需要与财务和资源管理团队合作，评估需求的成本效益，确保需求在可接受的成本范围内实现。

通过评估这些可实现性标准，可以确保需求的可行性和可实现性，避免提出无法实现的需求，从而提高项目的成功率和效率。

确保可实现性首先需要排除一些不可实现的需求，即伪需求。本章不涉及伪需求的内容，后续会有专门的篇章来了解伪需求。至此，关于需求标准的内容讲解就到这里，但是可视化需求的知识分享将会继续，请大家及时关注公众号的动态。