答案。

功能性需求描述系统应该做什么：业务操作、流程、用户场景——即_功能_。

非功能性需求确定系统应该如何工作：限制、质量参数、性能、安全性、可用性等。这些需求通常影响技术选择、可扩展性和解决方案的稳定性。

为什么区分这些很重要：

• 明确的划分有助于为开发者和测试人员正确设定任务。
• 避免遗漏关键特性（例如，安全性、可扩展性）。
• 未考虑的非功能性需求常常成为项目失败的根源。

关键特点：

• 功能性需求——系统的_行为_。
• 非功能性需求——质量_和_限制。
• 两种类型都必须清楚记录并达成一致。

迷惑性问题。

“界面的易用性”是否属于功能性需求？

不，这是非功能性参数（可用性）。功能性需求是例如有一个“保存”按钮，非功能性需求是其响应速度和使用的简便性。

如果客户并未明确指出，是否可以忽略非功能性需求？

不可以。分析师有责任讨论并形式化即使是隐含的非功能性需求，否则启动风险、用户投诉和额外成本都会增加。

“系统必须能够每分钟处理1000个请求”。这是功能性需求吗？

不，这是非功能性需求——性能特性。

常见错误和反模式

• 仅关注功能（“主要是可以工作，速度稍后再说”）。
• 非功能性需求的模糊表述——“应该快”，“要可靠”，“要安全”。
• 忽视非功能性测试。

实例

负面案例： 系统完全实现了声明的业务功能，但在大负载下开始“卡顿”，因为根本没有考虑性能。 优点：

• 快速开发，准确执行声明的场景。 缺点：
• 在实际负载情况下系统不适合运行，公司不得不紧急调整架构。

正面案例： 分析师与架构师和客户一起在需求中确定了极限负载、响应标准，进行了负载测试。 优点：

• 产品稳定运行并承受用户增长。
• 发展计划预见了可扩展性。 缺点：
• 在设计初期必须花费更多时间进行讨论和额外测试。