历史上，在IT项目中，重点主要放在功能性需求上：系统应该做什么。与此同时，性能、可靠性、可扩展性、可用性、安全性和可维护性等问题（这些特性统称为“非功能性需求”，NFD）长期以来一直被视为次要，往往根本没有被正规化。
忽视或形式化描述NFD会导致在运营中出现重大问题：系统无法承受预期的负载，抵御网络攻击困难，维护和扩展复杂，或者无法满足所需的用户数量。
现代系统分析师必须主动发起、正规化、分析和记录NFD。这包括：
关键特点：
“产品质量”和“非功能性需求”之间有什么区别？
产品质量是一个更广泛的概念，不仅包括可正规化的参数，还包括主观评估（例如，UX/UI的易用性）。NFD是可明确测量的特性（性能、可靠性等），可以进行自动验证。
分析师可以将所有非功能性需求的定义委托给架构师吗？
不可以，分析师必须与架构师和业务共同识别这些需求，否则需求将是不完整的，或仅从技术角度描述，而未考虑业务需求。
是否可以仅用一般性短语（“系统必须可靠”）来表述非功能性需求？
不可以，这样的表述不适合控制和测试。需要具体化：例如，“服务故障后的恢复时间不得超过10分钟”。
负面案例：国家服务门户项目未正规化高峰负荷的需求。在受欢迎服务启动的日子，系统"崩溃"，发生安全事件。
优点：
缺点：
积极案例：在工业自动化工厂项目开始时，分析师与运营部门一起发现，系统的停机时间比新功能更为重要。制定了SLA、紧急场景，明确了具体的指标。
优点：
缺点：