跨功能需求（CFR）/ 非功能性需求（NFR）的目标设定

原文参见本人博客：跨功能需求（CFR）/ 非功能性需求（NFR）的目标设定

跨功能需求的目标

最近整理 跨功能需求（CFR）/ 非功能性需求（NFR） 相关的”标准”，目标是在组织层面设定一些规范，当一个项目启动时，可以根据项目的业务目标和特点来找到关键的跨功能需求，并设定跨功能需求的目标。

跨功能需求（CFR）/ 非功能性需求（NFR）作为软件产品的 质量属性，包含了各种维度，是一个非常大的集合。在实际的产品研发中，大部分情况是开发团队优先满足业务需求的目标，Tech Lead 或架构师会从技术架构设计的层面考虑跨功能需求，但这非常依赖 Tech Lead 或架构师的经验和能力，实际落地效果会差异很大。

然而，在需求分析阶段如果缺少对跨功能需求的整理和目标设计，在方案设计和开发交付阶段必然会缺乏关注，大部分问题只能等到产品上线后暴露出来。

回想我们遇到的线上问题，功能性的问题通常表现为软件产品无法应对一些异常业务场景，比如因数据和流程差异导致的问题，这部分问题虽然每天都会发生，但并不影响整个软件产品对外提供服务。而真正影响核心流程，会导致大部分用户无法正常使用产品的往往是跨功能需求（CFR）/ 非功能性需求（NFR），比如兼容性问题，性能问题，稳定性问题等等。

因此，在需求分析阶段对跨功能需求进行梳理和分析，并结合业务场景设定相应的目标，是非常有必要的。

不同项目背景下的跨功能需求

我们拿几个项目来看看不同的跨功能需求：

项目 A：大型 ToB 系统，微服务 100 个左右，集成外部系统超过 50 个，主要通过 API 提供服务，前端包括网页应用移动端应用，活跃用户在几万人。主要业务是辅助 B 端用户快速完成日常业务，稳定性要求较高。

项目 B：中型 ToB 系统，微服务 20 个左右，核心是数据，从多个上游系统获取数据，通过处理后，给 B 端用户提供数据的查询功能。用户量较小（<1000)，系统内微服务之间的通信采用消息机制，每天需要处理的消息量级在千万级，用户对数据的准确性要求较高。

项目 C：小型 ToB + ToC 系统，微服务 5-10 个，集成系统不超过 10 个，通过 API 提供服务，前端是网页应用，数据量不大，C 端用户主要由 B 端用户触达。软件产品的主要业务是辅助 B 端用户完成线下推广流程，促成交易。

具象化到这三个具体的项目，不同的业务场景，可以直观感受到，这三个软件产品的跨功能需求是有所不同的，即便是相同的跨功能需求，目标也是不同的。

通常情况下，没有软件产品是不需要关注性能指标的，我们就拿性能来看一下这几个项目的区别：

• 项目 A：关注在大量并发请求的情况下，能够提供稳定、高效的响应，要关注 Throughput，Response Time 以及 Error Rate（API 调用响应异常的占比）。

• 项目 B：虽然也有 API 查询的需求，但并发请求量较小，而每个上游系统的数据变更会产生一系列的消息，结合对系统数据准确性的要求，每个上游系统数据变更需要在约定时间内更新到本地数据中，性能的关注点在于 TPS。

• 项目 C：从提供服务的方式上跟项目 A 的系统更相似，在数据量、集成数量以及并发量上都比项目 A 要小，但因为有 C 端用户，从用户体验侧对性能的要求会更高，关注 Response Time 和 Error Rate。

可见在不同的项目中，因为面对的业务场景不一样，跨功能需求也不一样。我们需要根据软件产品所应用的不同业务场景，找到更相关的跨功能需求，并为止设定目标。

如何设定跨功能需求目标

那么具体如何来确定哪些 NFR 更适合衡量当前项目的软件系统质量呢？通常有下面几种方法：

1. 质量属性工作坊（Quality Attribute Workshop）：这种方法涉及利益相关者之间的协作会议，通过讨论和优先排序，明确系统需要满足的跨功能特性，如性能、可用性、安全性等。

2. 问题分析法：通过分析系统可能面临的问题和风险，来推导出相关的跨功能需求。这种方法的关键是深入分析系统可能面临的问题，并将其转化为具体的需求。这个过程需要团队成员的专业知识和分析能力，以及与利益相关者的有效沟通和合作。

3. 场景法：场景法是一个实际且直观的方法，通过具体的使用场景和案例来识别和量化跨功能需求。这种方法易于理解和应用，并且能够帮助团队更好地把握系统行为和用户期望。

这三种方法侧重点不同，第 1 个关注在团队的共识上，第 2 个关注在系统可能产生的问题和风险上，第 3 个更关注业务场景。

在真正实操的过程中，我们往往需要结合多个方法，灵活地确定软件系统跨功能需求的目标。推荐以场景法为主导，辅以质量属性工作坊和问题分析法。因为场景法将用户需求放在核心位置，通过描述具体的使用场景和用户故事，从用户的角度出发来理解和捕捉系统的行为和需求。这种用户导向的方法可以更好地满足用户的真实需求和期望，提供用户满意的系统体验。也有助于团队全面理解系统的功能和跨功能需求，更好地捕捉和处理系统的各种交互情况和使用情景，从而确保系统的完整性和一致性。

重点关注哪些跨功能需求

在之前介绍 跨功能需求（CFR） 的文章中，给出了一个列表，里面包含了大部分我们可以想到的跨功能需求条目，实际操作过程中可以用作 CheckList 来分析软件产品的跨功能需求。

最近在查阅文献时，发现在 ISO/IEC 25000 系列标准中，给出了对于软件系统质量属性的定义，并给出了计算和度量方法。

从上面两个图（图片来源：iso25000.com）中可以看到，对于软件产品质量和数据产品质量，都有很多属性可以用来衡量产品质量的好坏。不同的产品可能关注不同的属性。例如，大部分软件产品（包含一些数据功能，如简单的报表等）给终端用户提供访问界面，可以在多种设备上操作。这些产品更关注性能、兼容性、安全性、稳定性以及数据的准确性和一致性。因此，我们需要根据不同的产品需求场景，分析跨功能需求，并确定优先级。

不只关注指标

然而，即便我们找到了可以衡量软件产品质量的指标，这并不代表我们就能达到我们期望的目标。我们需要在项目的生命周期中持续关注跨功能需求指标，并采取适当的措施来确保软件产品的质量。这可能涉及到对软件架构和设计的调整，对代码的重构和优化，以及对测试和部署流程的改进。此外，监控系统的实际性能和指标数据也是非常重要的，这可以帮助团队及时发现和解决问题，以及及时调整计划和策略。

最后，还是要强调一下，指标度量不是目的，我们定义了跨功能需求的目标，重点在目标要达成的效果，而不是用来衡量目标的这些指标。同时，跨功能需求的目标并非永恒不变的，它们可能会随着项目的变化和发展而调整。因此，我们需要保持敏捷和灵活，及时调整以确保软件产品始终能够满足用户的需求和期望。