功能需求是什么
功能需求描述系统对外表现出的行为：在什么条件下、接收什么输入、执行什么处理、产生什么输出以及状态如何变化。它回答“系统做什么”。非功能需求不描述具体功能，而是描述系统做得怎么样：性能、可用性、安全性、可维护性等质量属性，以及合规、部署环境、成本等外部约束，它回答“系统要达到什么水平”。两类需求加上约束条件共同构成需求基线，架构设计主要依靠非功能需求提供取舍依据。
基本信息
| 功能需求 | 系统行为与业务规则：输入、处理、输出、状态变化 |
|---|
| 非功能需求 | 质量属性与外部约束：性能、可用性、安全、合规、成本 |
|---|
| 约束类需求 | 不可协商的边界：技术选型、部署环境、法规与数据存放地 |
|---|
| 质量特征 | 可验证、无歧义、完整、一致、可行、可追踪 |
|---|
| 责任归属 | 业务方定义目标，开发与测试共同确认可验证口径 |
|---|
典型使用场景
- 立项阶段对齐范围：用功能需求清单确认系统覆盖哪些业务流程、哪些明确不做
- 编写验收用例前：把每条功能需求拆成正常路径与异常路径的可判定条件
- 架构取舍讨论时：按非功能需求的指标排序，决定延迟、可用率与成本谁让步
- 上线前评审：确认性能与安全指标都有明确的度量方法和测试场景
- 需求变更评估：借助需求唯一标识回溯到设计、代码与测试，估算影响面
- 外包与采购：把非功能需求写成可验收条款，避免交付后双方口径不一致
两类需求对照
| 维度 | 示例 | 验证方式 |
|---|
| 功能 | 提交订单时校验库存并扣减 | 功能测试、验收用例 |
| 非功能 | 订单查询接口 p95 响应时间不超过 500 毫秒 | 压测报告、生产监控 |
| 约束 | 数据存储必须位于境内 | 架构评审、合规审计 |
| 组合口径 | 同一功能在峰值负载下的错误率与延迟同时达标 | 压测与灰度观察 |
把口号改成指标
| 常见口号 | 可度量写法 | 度量方式 |
|---|
| 系统要快 | 订单查询 p95 不超过 500 毫秒，峰值支持 2000 QPS | 压测与线上监控 |
| 要稳定 | 月度可用率不低于 99.95%，单次故障恢复不超过 30 分钟 | 监控统计与故障复盘 |
| 要安全 | 口令加盐哈希存储，登录失败 5 次锁定 15 分钟 | 安全测试与代码审计 |
| 要好维护 | 新增一个支付渠道的接入工作量不超过 3 人日 | 变更前置时间统计 |
只收集功能需求而忽略质量属性与外部约束，架构阶段就失去取舍依据；等上线后才发现性能或合规不达标，返工成本远高于前期澄清。
每条需求应有唯一标识，便于用追踪矩阵关联设计文档、代码与测试用例；评审时逐条检查是否可验证，而不是只检查写得是否完整。
需求质量检查项
| 检查项 | 判定问题 | 不合格表现 |
|---|
| 必要 | 去掉它系统还能否达成目标 | 为技术而技术的要求混入基线 |
| 无歧义 | 换个人读能否得到同一理解 | 出现“快速”“适当”等无量化词 |
| 完整 | 正常与异常路径是否都覆盖 | 只描述成功场景，遗漏失败处理 |
| 可验证 | 能否设计出判定通过与失败的用例 | 无法给出度量方法或观察点 |
| 可追踪 | 能否关联到设计、代码与测试 | 没有唯一标识，改动影响面说不清 |
