business-requirements-interview

业务需求访谈

分析你的项目构想，找出其中的缺漏，并提出针对具体情境的问题。

流程

1. 了解构想

请用户描述项目：

“描述一下你的项目：要解决的问题、目标用户，以及你想实现的目标。”

分析用户的回答：

• 领域（CLI、Web 应用、API 等）
• 已明确与未明确的内容
• 缺少的信息（用户、范围、限制）
• 需要提出的问题

2. 提出针对具体情境的问题

根据用户的项目生成问题，而不是使用通用表单。

示例 - CLI 验证器：

用户：“构建用于 CI/CD 的 YAML 验证器”

问题：

1. “使用什么架构格式？JSON Schema、自定义 DSL，还是基于代码？”
2. “谁会使用它？仅用于 CI/CD，还是也用于本地开发？”
3. “错误输出格式是什么？JSON、自然语言，还是两者都要？”
4. “性能要求如何？需要处理数千个文件还是几十个？”

示例 - Web 仪表板：

用户：“用于指标分析的仪表板”

问题：

1. “谁会查看它？高管、项目经理、分析师，还是以上人群？”
2. “需要哪些指标？收入、使用情况、参与度？”
3. “需要实时数据还是批量处理？数据要有多新？”
4. “数据来源有哪些？数据库、API、数据仓库？”

3. 根据回答调整

每个回答都会影响下一个问题：

• CI/CD → 退出代码、自动化
• 本地开发 → 用户体验、错误消息
• 多个用户 → 访问控制

问题类型

澄清：“你说的‘验证’是指架构、业务规则，还是两者都包括？”

范围：“以下哪些属于 v1：[具体列表]，还是要留到 v2？”

优先级：“速度、详细的错误信息，还是可扩展性——哪项最重要？”

限制：“技术、时间安排或团队方面是否有任何限制？”

成功标准：“如何判断它是否正常工作？哪些指标很重要？”

结构模板

生成前请先查看：references/structure-template.yaml

其中展示了所需的 YAML 结构。请将其用作模板。

关键结构规则：

• overview.scope → 对象，包含 in_scope 和 out_of_scope 数组（不能是使用 | 的字符串）
• timeline → 对象，包含 phase、duration、milestones（不能是字符串）
• functional_requirements[].id → 按顺序编号：FR-1、FR-2、FR-3（不能跳号，也不能使用 FR-001）
• use_cases[].actor → 必须与某个 personas[].name 完全一致，或为 "System"

必须涵盖的内容

收集以下信息：

• 问题：是什么问题、涉及哪些人、为什么重要
• 价值：可衡量的影响
• 范围：v1 中包含和不包含的内容
• 用户：用户是谁、目标和痛点
• 用例：排名前 3-5 的场景
• 需求：5-10 项具体且可测试的需求
• 成功标准：可量化的目标
• 限制：技术、业务、时间安排
• 风险：可能出现的问题

避免

❌ 通用问题：“你要解决什么问题？” ✅ 具体问题：“错误应该采用 JSON（供机器读取）、自然语言（供人阅读），还是两者都要？”

❌ 宽泛分类：“1. 开发者 2. 团队 3. 企业” ✅ 结合情境：“1. 验证配置的开发者 2. 执行标准的平台 3. 两者都包括”

进度跟踪

保存到 {base_directory}/artifacts/business-interview.jsonl：

{"category":"analysis","question":"initial_idea","answer":"CLI YAML validator","timestamp":"2024-05-14T10:30:00Z"}
{"category":"schema","question":"Schema format?","answer":"JSON Schema","rationale":"Industry standard","timestamp":"2024-05-14T10:32:15Z"}

输出

完成后，在 {base_directory}/requirements/business-requirements.yaml 中生成文件。

重要： 严格遵循 references/structure-template.yaml 中的 YAML 结构。

详细的架构文档请参阅 references/output-spec.md。

输出必须包含：

• project、version、generated（根字段）
• overview（problem、value_proposition、scope）
• personas（name、description、goals、pain_points）
• use_cases（name、actor、description、outcome）
• functional_requirements（id：FR-1、FR-2……，category、description、priority、rationale）
• non_functional_requirements
• success_criteria
• constraints
• dependencies
• timeline
• assumptions
• risks

ID 格式： FR-1、FR-2、FR-3（按顺序编号，不得跳号）

完整示例请参阅 references/example.yaml。

生成前请确认：

“准备好起草需求文档，其中包含：

• 问题和价值主张
• 3 个角色及其用例
• 8 条功能需求
• 成功标准和约束

继续吗？”

验证

sherpy validate -t business-requirements -f {base_directory}/requirements/business-requirements.yaml --strict

立即修复错误。

差距分析

检查以下方面：

• ✅ 具体、可测试的需求
• ✅ 目标各异且定义清晰的角色
• ✅ 可衡量的成功标准
• ✅ 明确的范围边界
• ✅ 已识别并制定缓解措施的风险

如有差距：“注意到 [gap]。现在处理还是继续？”

后续步骤

1. 使用 sherpy validate 进行验证
2. 检查差距
3. /technical-requirements-interview
4. /implementation-planner

主要区别

旧版： 固定问题、通用选项，适用于所有项目
新版： 先分析，再提出结合上下文的问题，进行自适应且智能的对话