问题背景：
最初对需求的形式化关注于功能能力，但随着时间的推移，人们逐渐意识到那些乍一看“不可见”的标准（性能、安全性、容错性等）对产品的成功实施和生存至关重要。忽视它们会导致在启动后出现故障和不可预测的行为。
问题：
非功能性需求通常以模板化的形式记录，没有考虑上下文。它们的列出仅仅是为了“打勾”，或者被过于抽象地表述，例如：“系统应便于使用”或“系统应响应迅速”。这并没有为开发者、架构师和测试人员提供明确的KPI。
解决方案：
系统分析师与业务部门、IT和运营专家召开会议，以识别实际限制，记录数值指标（例如，SLA、TPS、延迟指标），在规范中明确描述非功能性需求，并通过与测试用例和项目架构文档的连接确保它们可被测试。
关键特征：
可以将需求组仅作为“系统应全天候可用”列出而不进行详细说明吗？
不，可以明确可用性参数（例如，99.95%）和恢复条件。
仅仅指出“响应速度应迅速”是否足够？
不，这种表述是不可行的。需要明确说明，例如：响应时间 < 3 秒，95% 请求在负载 X 下。
如果仅在一般技术规范中列出而没有进一步详细说明，非功能性需求是否就被形式化了？
不，它们需要进行分解，并与架构解决方案和测试计划关联，否则它们将无法执行或无法验证。
负面案例：e-banking项目以“24/7可用，快速响应”的要求启动，但没有明确SLA。
优点：
缺点：
正面案例：分析师与运营部门合作，记录了99.9%的正常运行时间，最大响应2秒，描述了降级场景。
优点：
缺点：