非功能需求怎么落地
非功能需求指性能、安全、可靠性、可维护性与可用性等质量属性。在敏捷中它们不单独排成一个大阶段，而是作为验收标准与完成定义的一部分，每个迭代持续验证，并预留固定容量的技术加固时间。原因在于这类要求很难事后补：架构定型后再追性能或安全，往往需要结构性改动，代价远高于在迭代中持续守住。
基本信息
| 常见类别 | 性能与容量、安全与隐私、可靠性与可用性、可维护性、兼容性 |
|---|---|
| 纳入方式 | 写成可测量的验收标准或完成定义条款，随故事一起交付 |
| 验证方式 | 每迭代执行关键性能与安全检查，纳入自动化流水线 |
| 容量安排 | 预留固定比例处理技术债与加固工作 |
| 欠账处理 | 未达标项登记为技术债并按影响排序，不隐性挂账 |
典型使用场景
- 新功能涉及用户数据，需要把安全与隐私要求写进验收标准而不是事后补审
- 系统在业务高峰期响应变慢，需要在迭代中持续做容量验证
- 对外接口有服务水平约定，需要把响应时间与可用性指标纳入完成定义
- 技术债累积影响交付速度，需要固定容量逐步偿还而不是等专项
- 上线前需要集中做性能与安全测试，需要判断是否已经过晚
写法示例
写法示例
改写前：系统应具备良好的性能与安全性
改写后：列表页在 1 万条数据下首屏响应时间不超过 2 秒（95 分位）
改写后：所有对外接口需鉴权并做输入校验，日志不记录身份证与手机号明文
改写后：核心服务可用性达到约定水平，故障切换演练每季度执行一次专项容量安排
| 做法 | 说明 | 注意 |
|---|---|---|
| 固定比例 | 每迭代预留容量处理技术债与加固 | 比例写入团队工作协议并公开 |
| 专项时段 | 大范围加固集中安排 | 需与业务窗口协调，避免长期冻结交付 |
| 验收并入 | 指标写进完成定义并回归验证 | 指标需可测量，否则验收时争论无依据 |
全部留到上线前做性能与安全专项，返工成本高且上线日期不可控。涉及合规要求时，事后整改还可能带来额外的审查与通报成本。