答案。

业务分析师负责全面收集、协调和记录不仅是功能性需求，还有非功能性需求：系统的响应速度、安全性、可扩展性、可用性、用户界面的友好性。为此，他需要与利益相关者（特别是业务和IT）紧密合作，使用场景并分析标准。他不仅要收集显性期望，还要识别隐性需求（例如，数据保护法规）。最终，分析师将在文档中格式化非功能性需求，与项目和技术团队达成一致，并在整个项目过程中监控这些需求的遵守情况。

关键特点：

• 通过访谈和标准分析识别隐性和特定需求
• 确保非功能性需求的文档记录和协调
• 控制实现与协商一致的非功能性标准的一致性

有陷阱的问题。

单纯在文本中描述非功能性需求而不提供指标和具体信息是否足够？

不够，抽象的描述（“快速”、“安全”）不适合验证。需要明确的参数：例如，响应时间不超过2秒。

非功能性需求是否仅仅是技术人员的关注？

不是，分析师必须与业务共同识别和形式化这些需求，因为不遵循这些需求将导致业务的关键利益不满。

是否可以将处理非功能性需求的工作推迟到项目的最终阶段？

不可以，这些需求通常对解决方案的架构至关重要。在后期发现这些需求会导致返工和高额成本。

常见错误和反模式

• 对非功能特性的隐性、形式化或过于笼统的描述
• 忽视安全标准、SLA、法律要求
• 在后期发现非功能性需求，面临重大返工的风险

实际案例

负面案例： 在技术规格中描述了预期的“友好性”和“响应速度”，却没有记录具体的指标。 优点：撰写文档时成本较低 缺点：当结果未能满足客户时无法对团队提出异议。

正面案例： 协商一致：“页面加载速度——在1000用户负载下不超过2秒，SLA水平——99.95%”。格式化了对个人数据保护的要求。 优点：结果检查明确，降低了返工风险，透明度提高。 缺点：需要与IT和法律团队的时间和协调。