tikazyq/nfr-to-user-impact

NFR to User Impact Skill

Scope: REQUIREMENTS

版本: 0.1.0 | 创建日期: 2025-12-04

---

概述

将技术性的Non-Functional Requirements（NFR）转换为用户能感知的影响描述，让PM/客户/BA理解技术约束背后的业务价值。

核心价值：

• 技术约束 → 用户感知（100%业务语言）
• 抽象指标 → 具体体验（可观察的现象）
• 技术术语 → 日常语言（易于理解）
• 帮助非技术人员理解NFR的重要性

适合人群：不熟悉技术术语的PM/BA/客户，需要理解NFR的业务价值

---

适用场景

场景1：客户不理解为什么需要NFR

现状：

## NFR-PERF-001: 响应时间要求

**约束**: 所有页面请求响应时间必须 < 500ms
**类型**: 性能

问题：

• 客户不明白"500ms"意味着什么
• 不理解为什么要设置这个约束
• 觉得NFR是技术人员的事，与业务无关

场景2：需要向管理层解释技术投入的价值

管理层质疑为什么要花时间做性能优化、安全加固，需要用业务语言说明价值

场景3：PM需要向客户确认NFR优先级

PM需要帮助客户理解不同NFR的影响，以便客户做出优先级决策

---

执行步骤

步骤1：读取NFR基本信息

• 读取NFR的Front Matter（id, sn, type, priority）
• 提取NFR的约束描述
• 识别NFR类型（性能/安全/可用性/易用性/兼容性）

步骤2：NFR类型识别与分类

类型1：性能类（Performance）

技术约束：

• 响应时间（如 < 500ms）
• 吞吐量（如 1000 QPS）
• 并发用户数（如 支持10000并发）
• 加载时间（如 首屏2秒内）

类型2：安全类（Security）

技术约束：

• 数据加密（如 AES-256加密）
• 身份认证（如 双因素认证）
• 权限控制（如 RBAC）
• 数据保护（如 敏感信息脱敏）

类型3：可用性类（Availability）

技术约束：

• 正常运行时间（如 99.9%可用性）
• 故障恢复时间（如 RTO < 1小时）
• 备份频率（如 每日备份）

类型4：易用性类（Usability）

技术约束：

• 学习曲线（如 新用户10分钟上手）
• 操作步骤（如 3步完成关键操作）
• 界面响应（如 点击即时反馈）

类型5：兼容性类（Compatibility）

技术约束：

• 浏览器支持（如 Chrome/Firefox/Safari最新版）
• 设备支持（如 手机/平板/桌面）
• 操作系统（如 Windows/Mac/Linux）

步骤3：转换策略（技术→业务）

策略1：性能约束 → 用户等待感知

# 技术约束 → 用户影响

"响应时间 < 500ms" →
  **用户影响**：
  - 用户点击按钮后，立即看到反馈，无明显等待
  - 就像现实中立即得到回应，体验流畅
  - 不会出现"卡顿"或"无响应"的感觉

"首屏加载 < 2秒" →
  **用户影响**：
  - 用户打开页面后，2秒内看到完整内容
  - 不用盯着空白页面或加载动画等待
  - 类似翻开一本书，内容立刻呈现

"支持10000并发用户" →
  **用户影响**：
  - 即使在促销高峰期（如双11），系统仍然流畅
  - 用户不会因为"访问人数过多"被拒绝
  - 就像商场再拥挤，每个顾客都能正常购物

策略2：安全约束 → 用户数据保障

# 技术约束 → 用户影响

"密码AES-256加密存储" →
  **用户影响**：
  - 用户的密码不会被管理员看到
  - 即使数据库被黑客攻击，密码也无法破解
  - 就像把钱存在保险柜里，只有用户自己知道密码

"双因素认证（2FA）" →
  **用户影响**：
  - 即使密码被盗，黑客也无法登录账户（需要手机验证码）
  - 用户账户安全性大大提升
  - 就像家门有两道锁，更安全

"HTTPS加密传输" →
  **用户影响**：
  - 用户输入的密码、银行卡号等敏感信息不会被窃取
  - 在公共WiFi下也能安全使用
  - 就像用密封信封寄信，中途不会被拆看

"敏感信息脱敏" →
  **用户影响**：
  - 客服人员只能看到"138****5678"，看不到完整手机号
  - 用户隐私得到保护
  - 就像医生病历只写"王先生"，不写完整姓名

策略3：可用性约束 → 服务可靠性

# 技术约束 → 用户影响

"99.9%可用性（全年停机 < 8.76小时）" →
  **用户影响**：
  - 系统几乎不会停机，用户随时可以使用
  - 全年365天，只有不到9小时无法访问
  - 就像水电一样可靠，随时可用

"RTO < 1小时（故障恢复时间）" →
  **用户影响**：
  - 即使系统出故障，1小时内就能恢复正常
  - 用户不会长时间无法使用系统
  - 就像停电后1小时内就来电

"每日自动备份" →
  **用户影响**：
  - 即使系统出现严重故障，用户的数据不会丢失
  - 最多只丢失最近1天的数据
  - 就像每天给重要文件拍照备份

策略4：易用性约束 → 操作简便性

# 技术约束 → 用户影响

"新用户10分钟上手" →
  **用户影响**：
  - 用户不需要培训，看界面就能知道怎么用
  - 10分钟内就能完成第一次操作
  - 就像微信一样简单直观

"关键操作 ≤ 3步完成" →
  **用户影响**：
  - 用户完成常用操作（如下单）只需3步
  - 不用翻找多个页面、填写大量表单
  - 就像ATM取款：插卡 → 输密码 → 选金额

"错误提示清晰友好" →
  **用户影响**：
  - 用户操作失败时，看到明确的提示（如"密码长度至少8位"）
  - 而不是"错误代码500"等技术信息
  - 就像朋友提醒你"密码太短了"，而不是说"ERR_500"

策略5：兼容性约束 → 设备自由度

# 技术约束 → 用户影响

"支持Chrome/Firefox/Safari最新3个版本" →
  **用户影响**：
  - 用户用任何主流浏览器都能正常使用
  - 不会出现"请使用Chrome浏览器"的限制
  - 就像DVD能在任何品牌的播放器上播放

"响应式设计（手机/平板/桌面）" →
  **用户影响**：
  - 用户在手机、平板、电脑上都能舒适使用
  - 界面自动适应屏幕大小，不用横向滚动
  - 就像报纸可以折叠成不同大小阅读

"支持离线操作（基础功能）" →
  **用户影响**：
  - 用户在没有网络的情况下，仍能浏览已加载的内容
  - 网络恢复后，自动同步数据
  - 就像飞行模式下仍能看已下载的电影

步骤4：生成用户影响说明

格式1：嵌入原NFR（推荐）

在原NFR的约束描述下方增加"用户影响"章节：

## NFR-PERF-001: 响应时间要求

**约束**: 所有页面请求响应时间必须 < 500ms
**类型**: 性能
**优先级**: 高

**用户影响**：
当用户点击任何按钮或链接时，页面会立即响应（不到半秒），用户感觉系统非常流畅，没有"卡顿"或"等待"的感觉。就像现实中与人对话，对方立即回应，体验非常好。

**业务价值**：
- 提升用户满意度（用户不会因为等待而放弃操作）
- 减少用户流失率（研究表明，响应时间每增加1秒，转化率下降7%）
- 增强品牌形象（系统流畅 = 专业可靠）

**反例说明**（如果不满足）：
用户点击"提交订单"后，要等待2-3秒才看到反馈，期间页面无响应。用户会怀疑：
- "是不是没点上？"
- "要不要再点一次？"
- "系统是不是坏了？"
最终可能放弃购买。

格式2：对比表（适用于多个NFR对比）

## 性能类NFR用户影响对比

| 技术约束 | 用户影响（满足时） | 用户感受（不满足时） |
|---------|------------------|---------------------|
| 响应 < 500ms | 点击立即反馈，流畅 | 等待2-3秒，怀疑系统故障 |
| 首屏 < 2秒 | 打开即看到内容 | 盯着空白页或加载动画 |
| 10000并发 | 促销高峰期正常使用 | "访问人数过多"被拒绝 |

步骤5：添加业务价值说明

除了用户影响，还应说明对业务的价值：

**业务价值**（为什么要做这个NFR）：

1. **提升转化率**：
   - 性能优化可以将订单转化率提升10-15%
   - 研究表明，加载时间每减少1秒，转化率提升7%

2. **降低成本**：
   - 良好的性能减少服务器负载，降低硬件成本
   - 减少客服咨询量（用户不会因为"系统太慢"投诉）

3. **增强竞争力**：
   - 用户会将系统与竞品对比，性能好的更容易胜出
   - 口碑传播：用户会推荐"又快又稳"的系统

4. **合规要求**：
   - 某些安全NFR是法律要求（如GDPR数据保护）
   - 不满足可能面临法律风险

---

快速开始

最快的3步使用流程：

• [ ] 第1步：确认已有NFR文档

  • 文件位置：spec/requirements/nfr.md（或 non_functional_requirements.md）
  • 格式要求：每个NFR包含约束描述和类型（性能/安全/可用性等）
  • 数量建议：至少2-3个NFR（可以处理更多）

• [ ] 第2步：调用SKILL转换为业务语言

  • 命令：>>nfr-to-impact 或 >>nfr-impact-batch
  • AI会自动读取NFR并转换为用户能理解的影响描述
  • 转换内容：将"AES-256加密"变成"密码存在保险柜里，管理员也看不到"
  • 处理时间：约3-5分钟 / 10个NFR

• [ ] 第3步：查看增强后的NFR

  • 结果位置：原NFR文件（新增3个章节）
  • 原技术约束完全保留，只是在下方新增：
    • 用户影响：用户能感受到什么（100%业务语言）
    • 业务价值：为什么要做这个NFR（量化收益）
    • 反例说明：如果不做会怎样（风险提示）
  • 可直接用于客户沟通：客户能理解，愿意支持

⏱️ 预计耗时：3-5分钟 / 10个NFR

🆘 遇到问题？ 查看下方"使用说明"章节获取详细指导

---

使用说明

📥 AI会读取什么（输入）

自动读取的文档：

• AI会读取 spec/requirements/ 文件夹下的非功能需求文档（NFR）
• 文档需要是 .md格式（如 nfr.md 或 non_functional_requirements.md）
• 每个NFR需要包含：
  • 约束描述（如"响应时间 < 500ms"）
  • 文档头部的编号信息（如 id: NFR-PERF-001）
  • NFR类型（如性能/安全/可用性）

项目结构示例：

你的项目/
└── spec/
    └── requirements/
        ├── user_stories.md
        ├── acceptance_criteria.md
        └── nfr.md  ← AI会读取这个文件

AI会做什么转换：

• 将技术术语转为日常语言（"AES-256加密" → "密码存在保险柜里"）
• 将抽象指标转为具体感受（"响应时间 < 500ms" → "点击立即反馈"）
• 添加日常生活类比（"99.9%可用性" → "就像水电一样可靠"）

可选的补充信息：

• 如果有项目背景描述，AI能生成更贴合业务场景的说明
• 如果有用户画像，AI能用更符合用户认知水平的语言

📤 AI会产生什么（输出）

修改的内容： AI会在原有NFR文件中新增3个章节，原有的约束描述完全保留

新增章节包含：

1. 用户影响（用户能感受到什么）：

   • 不再是"响应时间 < 500ms"，而是"用户点击后立即看到反馈，无明显等待"
   • 不再是"AES-256加密"，而是"用户的密码不会被管理员看到，更安全"
   • 每个影响都用日常语言描述，配有生活类比

2. 业务价值（为什么要做这个NFR）：

   • 量化的收益（如"转化率提升7%"、"减少客服投诉50%"）
   • 风险规避（如"避免数据泄露赔偿500万"、"符合《网络安全法》要求"）
   • 竞争优势（如"比竞品快2倍"）

3. 反例说明（如果不做会怎样）：

   • 用户会遇到什么问题（如"等待2-3秒，怀疑系统坏了"）
   • 可能导致的后果（如"用户流失"、"法律风险"）

结果位置：

• 修改后的文档仍在原位置：spec/requirements/nfr.md
• 原有的约束描述不会改变
• 只是在每个NFR下方新增3个章节

示例（修改前后对比）：

# 修改前（技术版）
## NFR-PERF-001: 响应时间要求

**约束**: 所有页面请求响应时间必须 < 500ms
**类型**: 性能
**优先级**: 高

---

# 修改后（友好版）
## NFR-PERF-001: 响应时间要求

**约束**: 所有页面请求响应时间必须 < 500ms
**类型**: 性能
**优先级**: 高

**用户影响**：
当用户点击任何按钮或链接时，页面会立即响应（不到半秒），用户感觉系统非常流畅，没有"卡顿"或"等待"的感觉。就像现实中与人对话，对方立即回应，体验非常好。

**业务价值**：
- 提升用户满意度（用户不会因为等待而放弃操作）
- 减少用户流失率（研究表明，响应时间每增加1秒，转化率下降7%）
- 增强品牌形象（系统流畅 = 专业可靠）

**反例说明**（如果不满足）：
用户点击"提交订单"后，要等待2-3秒才看到反馈，期间页面无响应。用户会怀疑"是不是没点上？"、"系统是不是坏了？"，最终可能放弃购买。

🎯 如何使用

第1步：确保文档已准备好

• 打开 spec/requirements/ 文件夹
• 确认有NFR文档（.md格式）
• 确认NFR包含约束描述和类型

第2步：调用这个SKILL

• 在与AI对话时输入：>>nfr-to-impact
• AI会自动读取所有NFR并开始转换
• 处理时间：约3-5分钟 / 10个NFR

第3步：查看结果

• 打开原来的NFR文档
• 你会看到每个NFR下面新增了3个章节：用户影响、业务价值、反例说明
• AI会在对话中告诉你具体修改了哪些NFR

常见问题：

Q: AI会覆盖我原来的NFR约束吗？ A: 不会。AI只会新增3个章节（用户影响、业务价值、反例说明），原有的约束描述完全保留。

Q: 为什么需要用户影响说明？ A: 技术约束（如"AES-256加密"）客户看不懂，转为用户影响（"密码存在保险柜里，管理员也看不到"）后，客户能理解NFR的价值，愿意投入资源。

Q: 业务价值的数据从哪来？ A: AI会基于行业研究和常见数据生成（如"响应时间每增加1秒，转化率下降7%"是业界公认的数据）。你可以根据实际情况调整。

Q: 如果我的NFR类型不对怎么办？ A: AI会提示你哪些NFR需要调整，比如："NFR-PERF-001缺少类型字段，请补充（性能/安全/可用性等）"。

Q: 生成的类比合适吗？ A: AI会尽量使用日常生活类比（如"保险柜"、"水电"），如果你觉得不合适，可以手动修改为更符合你的用户认知的类比。

---

质量检查

必检项（100%通过）

• [ ] 用户影响描述准确（不夸大、不低估）
• [ ] 100%业务语言（0个技术术语）
• [ ] 原NFR约束未被修改
• [ ] Front Matter完全保留
• [ ] 用户影响可感知（不抽象）

建议项（≥80%通过）

• [ ] 包含类比说明（如"就像..."）
• [ ] 包含业务价值量化（如"提升X%"）
• [ ] 包含反例说明（不满足时的后果）
• [ ] 用户影响长度适中（50-150字）
• [ ] 业务价值有数据支持（行业研究）

---

限制条件

✅ 适用场景

• 已有NFR文档，包含技术性约束描述
• NFR过于技术化（如"AES-256"、"QPS"、"RTO"），客户看不懂
• 需要向客户或管理层解释NFR的价值，争取资源和支持
• 需要帮助客户做NFR优先级决策（哪些先做）
• 准备需求评审会议，希望非技术人员能理解NFR

❌ 不适用场景

• 完全���有NFR文档 → 先定义NFR约束
• NFR已经用业务语言写的很友好 → 无需使用本SKILL
• NFR只给技术团队看，不对外沟通 → 技术团队能看懂技术约束，无需转换
• 需要的是详细的技术设计方案 → 本SKILL生成业务语言，不是技术设计
• NFR类型不明确（缺少性能/安全/可用性等分类） → 先补充NFR类型

📋 前置条件

• 至少有2-3个Non-Functional Requirements（包含约束描述）
• NFR文档是.md格式，位于spec/requirements/目录下
• NFR类型明确（性能/安全/可用性/易用性/兼容性）
• NFR约束有具体的技术指标（如"< 500ms"、"99.9%"、"AES-256"）
• 愿意接受AI生成的类比和业务价值数据（可根据实��情况后续调整）

---

特别说明（针对敏捷新手）

为什么需要转换NFR为用户影响？

NFR的常见问题：

1. 🤔 技术术语多：PM/客户看不懂"AES-256"、"RTO"、"QPS"
2. 📉 优先级难定：不知道哪个NFR更重要，全都想要
3. 💰 价值不明确：不理解为什么要花时间做性能优化
4. ❓ 验收困难：不知道如何验证"响应时间 < 500ms"

转换为用户影响后：

1. ✅ 易于理解：用日常语言描述，人人都能看懂
2. ✅ 优先级清晰：理解影响后，自然知道哪个更重要
3. ✅ 价值明确：看到业务价值（如"转化率提升7%"），愿意投入
4. ✅ 验收简单：用户自己能感受到（如"点击很流畅"）

技术约束 vs 用户影响的区别

| 维度 | 技术约束（NFR原文） | 用户影响（转换后） | |------|-------------------|------------------| | 语言 | 技术术语（API, QPS, AES） | 日常语言（流畅, 安全, 可靠） | | 受众 | 技术人员 | PM/客户/BA/用户 | | 可感知性 | 抽象指标（500ms） | 具体感受（立即响应） | | 验收方式 | 工具测试（压测） | 用户体验（手动测试） | | 价值体现 | 技术指标 | 业务价值（转化率, 成本） |

对比示例

# ❌ 技术约束（不够友好）

## NFR-SEC-001: 数据加密要求

**约束**: 用户密码使用AES-256算法加密存储，传输使用TLS 1.3协议
**类型**: 安全

# ✅ 用户影响（友好易懂）

## NFR-SEC-001: 数据加密要求

**约束**: 用户密码使用AES-256算法加密存储，传输使用TLS 1.3协议
**类型**: 安全

**用户影响**：
用户的密码被加密保护，就像存在保险柜里：
- 管理员和开发人员都无法看到用户的真实密码
- 即使黑客攻击数据库，也无法破解密码（需要数百年才能暴力破解）
- 用户在公共WiFi下登录，密码也不会被窃取

**业务价值**：
- 符合《网络安全法》和《个人信息保护法》要求，避免法律风险
- 提升用户信任度，用户更愿意使用系统
- 降低数据泄露风险，避免巨额赔偿（参考：某公司数据泄露赔偿5000万）

**反例说明**（如果不加密）：
- 数据库被攻击后，所有用户密码明文泄露
- 用户在其他网站用相同密码，也会被盗号
- 公司面临法律诉讼和巨额罚款
- 品牌信誉严重受损，用户流失

PM/BA使用指南

如何用这个SKILL帮助客户理解NFR：

1. 准备阶段：

   • 收集所有NFR，逐一使用本SKILL转换
   • 准备业务价值数据（行业研究、竞品对比）

2. 展示阶段：

   • 先展示用户影响（让客户感同身受）
   • 再展示业务价值（量化收益）
   • 最后展示反例（不做的后果）

3. 决策阶段：

   • 让客户基于用户影响和业务价值做优先级排序
   • 而不是基于技术复杂度排序

4. 验收阶段：

   • 邀请客户亲自体验（如"点击看看流不流畅"）
   • 而不是给客户看压测报告

常见NFR类型的转换模板

性能类模板

**技术约束**: [具体指标，如响应时间 < 500ms]

**用户影响**:
用户[执行什么操作]时，[感受到什么体验]，[与日常生活类比]。

**业务价值**:
- 提升[具体指标，如转化率]约[百分比]
- 降低[具体成本]
- 增强竞争力（对比竞品）

**反例说明**:
如果不满足，用户会[具体感受]，导致[业务后果]。

安全类模板

**技术约束**: [具体技术，如AES-256加密]

**用户影响**:
用户的[什么数据]被[如何保护]，就像[日常类比，如保险柜]：
- [保护效果1]
- [保护效果2]
- [保护效果3]

**业务价值**:
- 符合[法律法规]要求
- 避免[风险]（如数据泄露赔偿X万）
- 提升用户信任度

**反例说明**:
如果不做，可能导致[法律风险]、[财务损失]、[品牌受损]。

可用性类模板

**技术约束**: [具体指标，如99.9%可用性]

**用户影响**:
系统[稳定程度]，用户[使用感受]。全年365天，只有[X小时]无法访问，就像[日常类比，如水电]。

**业务价值**:
- 减少用户投诉（停机 = 投诉）
- 避免收入损失（停机1小时 = 损失X元）
- 提升口碑（稳定可靠）

**反例说明**:
频繁停机会导致[用户流失]、[收入损失]、[口碑下降]。

---

>> 命令

>>nfr-to-impact            # 为单个NFR生成用户影响说明
>>nfr-impact-batch         # 批量为所有NFR生成用户影响
>>nfr-value-report         # 生成NFR业务价值报告（汇总）
>>nfr-compare-table        # 生成NFR对比表（技术 vs 影响 vs 价值）

---

相关 Skills

配合使用：

• us-enrich-context - US增加场景感，NFR增加影响说明，两者互补
• interview-to-us - 从访谈中提取NFR后，用本SKILL增加影响说明

后续流程：

• test-strategy - NFR影响说明帮助制定测试策略（如性能测试）
• design-architecture - NFR约束指导架构设计

质量保证：

• document-quality - 确保NFR文档质量（包括影响说明）
• principle-kiss - NFR影响说明应简洁易懂

工作流位置：

• WORKFLOW S3-7（用户验收确认）前使用，帮助用户理解NFR
• 或在需求评审会议前使用，便于讨论优先级

---

注意：

1. 用户影响描述应该准确，不夸大也不低估（基于技术约束的实际效果）
2. 业务价值最好有数据支持（行业研究、A/B测试、竞品对比）
3. 类比要贴近用户的日常生活（不要用更复杂的技术类比）
4. 本SKILL是可选工具，当PM/客户对NFR有疑问时使用