需求收集模拟技能Skill simulate

---

名称: simulate 描述: 运行多利益相关方模拟以从不同视角生成需求。模拟最终用户、技术、业务、合规和运营利益相关方。 参数提示: <主题> [–personas <角色列表>] [–domain <域名>] [–mode <模拟模式>] 允许的工具: Read, Glob, Grep, Write, Task, Skill

模拟命令

当真实利益相关方不可用时，运行多利益相关方模拟以从不同视角生成需求。

用法

/requirements-elicitation:simulate "结账重新设计"
/requirements-elicitation:simulate "支付处理" --personas technical,compliance
/requirements-elicitation:simulate "用户仪表板" --domain "分析" --mode conflict
/requirements-elicitation:simulate "移动应用" --personas all --mode comprehensive

参数

参数	必需	描述
topic	是	要模拟利益相关方视角的功能、系统或主题
–personas	否	逗号分隔的列表: end-user, technical, business, compliance, operations, 或 all (默认: all)
–domain	否	用于组织输出文件的域名
–mode	否	模拟模式: standard, conflict, comprehensive (默认: standard)

模拟模式

标准模式

• 每个角色独立生成需求
• 基本冲突检测
• 适用于初始发现

冲突模式

• 专注于识别视角间的冲突
• 角色“讨论”冲突需求
• 建议解决方案

综合模式

• 多轮模拟
• 角色响应彼此的需求
• 最彻底但耗时较长

工作流程

步骤 1: 初始化模拟

解析参数并设置上下文:

simulation_context:
  topic: "{来自参数}"
  domain: "{来自--domain或推导}"
  personas: ["{选定角色}"]
  mode: "{来自--mode或默认}"
  session_id: "SIM-{时间戳}"

步骤 2: 加载利益相关方模拟技能

调用 requirements-elicitation:stakeholder-simulation 技能以加载角色配置文件。

步骤 3: 运行角色模拟

对于每个选定角色，启动相应的代理:

统一代理与角色参数:

使用 stakeholder-persona 代理并指定角色类型参数:

• stakeholder-persona end-user - 可用性、用户体验、可访问性
• stakeholder-persona technical - 架构、可扩展性、安全性
• stakeholder-persona business - 投资回报率、市场匹配、价值
• stakeholder-persona compliance - 法规、法律、审计
• stakeholder-persona operations - 部署、监控、支持

步骤 4: 收集和分析

从所有角色收集需求:

• 按类型和优先级分类
• 检测视角间的冲突
• 识别共同主题

步骤 5: 整合

合并和去重需求:

• 组合相似需求
• 注明哪些角色支持每个需求
• 标记冲突以供解决

步骤 6: 保存和报告

保存到 .requirements/{domain}/simulations/ 显示发现摘要。

示例

基本模拟

/requirements-elicitation:simulate "电子商务结账"

输出:

利益相关方模拟: 电子商务结账
会话: SIM-20251225-150000
模式: standard

模拟 5 个角色...

最终用户角色:
- 生成 8 个需求
- 焦点: 简洁性、速度、错误恢复

技术利益相关方:
- 生成 6 个需求
- 焦点: 安全性、可扩展性、集成

业务利益相关方:
- 生成 5 个需求
- 焦点: 转化率、收入、竞争性功能

合规利益相关方:
- 生成 7 个需求
- 焦点: PCI-DSS、数据保护、同意

运营利益相关方:
- 生成 4 个需求
- 焦点: 监控、部署、恢复

摘要:
- 总需求: 30
- 唯一需求 (去重后): 26
- 检测到冲突: 3

冲突:
1. [最终用户 vs 技术] 简洁性 vs 安全性
   - 最终用户要求: "一键结账"
   - 技术要求: "所有交易都需多因素认证"
   - 建议: "基于风险的身份验证"

2. [业务 vs 合规] 数据收集
   - 业务要求: "收集浏览数据以推荐商品"
   - 合规要求: "最小化数据收集"
   - 建议: "明确同意下的选择性加入"

保存到: .requirements/e-commerce/simulations/SIM-20251225-150000.yaml

聚焦模拟

/requirements-elicitation:simulate "API 安全性" --personas technical,compliance,operations

输出:

利益相关方模拟: API 安全性
会话: SIM-20251225-151500
模式: standard
角色: technical, compliance, operations

技术利益相关方:
- OAuth 2.0 + JWT 需求
- 速率限制需求
- 输入验证需求

合规利益相关方:
- 审计日志需求
- 数据加密需求
- 访问控制需求

运营利益相关方:
- API 监控需求
- 事件响应需求
- 密钥轮换需求

摘要:
- 总需求: 18
- 在安全基础上有强烈共识
- 日志详细程度有轻微冲突

保存到: .requirements/api/simulations/SIM-20251225-151500.yaml

冲突聚焦模拟

/requirements-elicitation:simulate "功能优先级排序" --mode conflict --domain "产品路线图"

输出:

利益相关方模拟: 功能优先级排序
会话: SIM-20251225-153000
模式: conflict (专注于分歧)

冲突分析:

冲突 1: 发布时间线
- 业务: "在 2 个月内发布最小可行产品"
- 技术: "需要 4 个月进行适当架构设计"
- 运营: "需要 3 个月进行适当监控设置"
→ 解决方案: 分阶段发布，使用功能标志

冲突 2: 功能范围
- 最终用户: "保持简单，功能较少"
- 业务: "更多功能以实现竞争均势"
→ 解决方案: 核心最小可行产品 + 可选高级功能

冲突 3: 数据保留
- 业务: "保留所有数据用于分析"
- 合规: "根据 GDPR 90 天后删除"
- 运营: "归档存储成本高"
→ 解决方案: 分级保留，使用匿名化

冲突 4: 身份验证
- 最终用户: "仅社交登录"
- 技术: "需要企业单点登录"
- 合规: "敏感操作需多因素认证"
→ 解决方案: 多种认证方法，基于风险的多因素认证

保存到: .requirements/产品路线图/simulations/SIM-20251225-153000.yaml

输出格式

保存的 YAML 结构

simulation_session:
  id: "SIM-{时间戳}"
  topic: "{主题}"
  domain: "{域名}"
  mode: standard|conflict|comprehensive
  timestamp: "{ISO-8601}"

personas_simulated:
  - name: end-user
    agent: stakeholder-persona
    agent_arg: end-user
    requirements_count: 8
  - name: technical
    agent: stakeholder-persona
    agent_arg: technical
    requirements_count: 6
  # ... 更多角色

requirements:
  - id: REQ-SIM-001
    text: "{需求}"
    perspectives: [end-user, business]
    priority: must
    confidence: medium
    needs_validation: true

  - id: REQ-SIM-002
    text: "{需求}"
    perspectives: [technical, operations]
    priority: should
    confidence: medium
    needs_validation: true

conflicts:
  - id: CONFLICT-001
    topic: "身份验证复杂性"
    positions:
      end-user: "简单登录"
      technical: "需多因素认证"
    suggested_resolution: "基于风险的身份验证"
    requires_decision: true

themes:
  - name: "安全性"
    requirements: [REQ-SIM-003, REQ-SIM-007, REQ-SIM-012]
  - name: "性能"
    requirements: [REQ-SIM-004, REQ-SIM-009]

validation_notes:
  - "所有模拟需求都需要利益相关方验证"
  - "冲突解决方案仅为建议"
  - "优先级分配基于角色共识"

集成

后续命令

# 与真实利益相关方验证
/requirements-elicitation:interview "产品经理" --context "验证模拟"

# 检查缺口
/requirements-elicitation:gaps

# 研究出现的特定主题
/requirements-elicitation:research "基于风险的身份验证最佳实践"

# 与其他来源整合
/requirements-elicitation:discover "{域名}" --sources simulations,interviews

重要说明

置信度: 所有模拟需求的置信度为 medium，且 needs_validation: true。模拟不能替代真实利益相关方输入。

最佳用途: 模拟适用于:

• 初始发现当利益相关方不可用时
• 验证现有需求的完整性
• 在利益相关方会议前识别潜在冲突
• 需要多视角的独立开发者