mcpField
B
business-requirements-analyst

business-requirements-analyst

github.com/gmdaos开发7113 次安装37 周前更新
代码仓库

关于 business-requirements-analyst

面向定义或完善产品与系统的团队的业务需求分析技能，涵盖业务分析、流程梳理、需求追踪和验证，并按发现到路线图的步骤组织工作。

主要功能

  1. 01引导式需求发现
  2. 02记录业务与系统范围
  3. 03整理功能及非功能需求
  4. 04流程图与 Mermaid ER 图
  5. 05需求追踪与质量门禁

适用场景

  1. 01梳理新产品构想的范围
  2. 02为开发估算准备需求
  3. 03绘制业务流程并识别边界情况
  4. 04检查需求缺口与就绪程度

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/gmdaos/business-requirements-analyst --skill business-requirements-analyst

安装后在 Claude Code 中输入/business-requirements-analyst确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/
requirements-template.md
examples/
food-delivery-app.md
references/
adr-template.md
data-modeling.md
ears-methodology.md
process-mapping.md
traceability-guide.md
use-cases.md

详细介绍

需求收集

此技能提供一套专业且完整的需求收集方法，涵盖所有业务层面，而不只是“应用”或“系统”。

基本原则

需求收集不只是功能列表。

良好的需求收集应涵盖所有业务层面：

  • 🧠 想法和目标
  • 👥 用户
  • 💼 运营
  • 💰 资金
  • ⚙️ 技术
  • ⚠️ 风险
  • 📈 增长
  • 🔗 可追溯性（从业务到代码）
  • ⚖️ 质量门槛（验证标准）

可用方法

1. 设计思维（适用于新想法）

适用场景：

  • 仍在验证想法
  • 并非所有内容都已明确
  • 希望真正了解用户

阶段：

  1. 共情 - 了解用户
  2. 定义 - 找出关键问题
  3. 构思 - 生成解决方案
  4. 原型 - 创建早期版本
  5. 测试 - 与真实用户验证

注意： 用于探索要构建什么，而不是记录所有内容。

2. 业务分析（BABOK）

最完整、最专业的方法。

涵盖内容：

  • 业务需求
  • 功能需求
  • 非功能需求
  • 业务规则
  • 利益相关者
  • 流程

注意： 用于创建正式文档。

3. 精益 / 创业画布（快速构想）

适用于：

  • 梳理想法
  • 判断商业模式是否合理

⚠️ 重要： 不能替代完整的需求收集。

推荐方法

结合 3 个关键要素：

  1. 业务愿景
  2. 流程
  3. 系统 / 产品
  4. 可追溯性与验证（确保所有内容相互关联并符合质量标准）

并将所有内容记录在单一主文档或结构化分层体系中。

完整需求文档的结构

📌 1. 业务愿景

包括：

  • 解决的问题 - 解决了什么痛点或需求？
  • 价值主张 - 为什么它比其他方案更好？
  • 业务目标 - 明确且可衡量的目标
  • 主要 KPI - 成功指标
  • 范围 - 包含和不包含哪些内容

格式示例：

## Business Vision

### Problem

[Description of the problem being solved]

### Value Proposition

[What makes this product/service unique]

### Objectives

- Objective 1: [Description]
- Objective 2: [Description]

### KPIs

- KPI 1: [Specific metric]
- KPI 2: [Specific metric]

### Scope

**Includes:**

- [Element 1]
- [Element 2]

**Does not include:**

- [Element 1]
- [Element 2]
📌 2. 利益相关者

识别所有参与者：

  • 业务所有者 - 谁负责决策
  • 最终用户 - 谁会使用系统
  • 管理员 - 谁负责管理系统
  • 供应商 - 外部服务或产品
  • 第三方 - 支付、物流、集成等

建议格式：

## Stakeholders

| Type  | Name/Role | Interest          | Influence         |
| ----- | --------- | ----------------- | ----------------- |
| Owner | [Name]    | [High/Medium/Low] | [High/Medium/Low] |
| User  | [Type]    | [High/Medium/Low] | [High/Medium/Low] |
📌 3. 用户类型（用户画像）

针对每种用户类型，记录：

  • 他们的需求 - 关键功能
  • 他们的痛点 - 当前问题
  • 他们对系统的期望 - 期望

示例：

## Personas

### End Customer

- **Needs:** Make fast and secure purchases
- **Pain:** Complicated checkout processes
- **Expectation:** Checkout in less than 3 clicks

### Administrator

- **Needs:** Manage inventory and orders
- **Pain:** Lack of real-time visibility
- **Expectation:** Dashboard with updated metrics
📌 4. 业务流程

⚠️ 非常重要——许多人会在此处遗漏。

记录完整流程：

  • 客户如何进入
  • 如何产生销售
  • 如何收取付款
  • 付款失败时会发生什么
  • 如何处理索赔

以分步流程的形式描述：

## Process: Product Purchase

1. User browses catalog
2. User adds products to cart
3. User proceeds to checkout
4. System validates availability
5. User enters payment details
6. System processes payment
   - **If success:** Confirms order and sends email
   - **If failure:** Shows error and allows retry
7. System generates shipping order
8. User receives confirmation

复杂流程请参阅 references/process-mapping.md。

📌 5. 功能需求

标准格式：

  • FR-01： 系统必须允许……
  • FR-02： 用户将能够……

常见类别：

  • 用户注册
  • 订单管理
  • 付款
  • 通知
  • 报告

示例：

## Functional Requirements

### Authentication

- **FR-01:** The system must allow registration with email and password
- **FR-02:** The system must send a verification email
- **FR-03:** The user will be able to recover a forgotten password

### Order Management

- **FR-04:** The user will be able to view order history
- **FR-05:** The system must allow canceling orders in "pending" status
📌 6. 非功能需求

这是区分业余与专业的关键。

关键领域：

  • 安全性 - 身份验证、授权、加密
  • 性能 - 响应时间、容量
  • 可扩展性 - 预期增长
  • 可用性 - 运行时间、冗余
  • 法律合规 - GDPR、数据保护
  • UX / 易用性 - 无障碍、响应式

示例：

## Non-Functional Requirements

### Performance

- **NFR-01:** The system must respond in < 2 seconds for 95% of requests
- **NFR-02:** The system must support 1000 concurrent users

### Security

- **NFR-03:** All passwords must be hashed with bcrypt
- **NFR-04:** Communications must use HTTPS/TLS 1.3

### Compliance

- **NFR-05:** The system must comply with GDPR for European user data
📌 7. 业务规则

特定领域的逻辑：

示例：

## Business Rules

- **BR-01:** An order cannot be canceled after 30 minutes of creation
- **BR-02:** A user can only have one active plan at a time
- **BR-03:** Commissions are calculated as 5% of the total amount
- **BR-04:** Taxes are applied according to the buyer's region
📌 8. 数据模型（高层）

概念性描述，暂非 SQL。

记录：

  • 主要实体 - 用户、订单、产品等
  • 关系 - 一对多、多对多
  • 关键数据 - 必要字段

示例：

## Data Model

### Primary Entities

**User**

- id (PK)
- email (unique)
- name
- registration_date

**Order**

- id (PK)
- user_id (FK)
- status
- total
- creation_date

**Product**

- id (PK)
- name
- price
- stock

### Relationships

- A User can have many Orders (1:N)
- An Order can contain many Products (N:M)

对于复杂模型，请参阅 references/data-modeling.md。

📌 9. 集成

必要的外部服务：

  • 支付网关 - Stripe、PayPal 等
  • 外部 API - 第三方服务
  • 第三方服务 - 电子邮件、短信、分析

示例：

## Integrations

### Payment Gateway

- **Provider:** Stripe
- **Functionality:** Credit card processing
- **Data exchanged:** Amount, currency, card token

### Email Service

- **Provider:** SendGrid
- **Functionality:** Sending notifications
- **Data exchanged:** Recipient, subject, HTML body
📌 10. 风险和假设

识别潜在问题：

  • 技术风险 - 依赖项、可扩展性
  • 法律风险 - 合规性、隐私
  • 业务假设 - 必须验证的假设

示例：

## Risks

### Technical

- **R-01:** Dependency on external API may cause downtime
  - _Mitigation:_ Implement caching and fallback system

### Legal

- **R-02:** Changes in data protection regulation
  - _Mitigation:_ Modular design for rapid adaptation

## Assumptions

- **S-01:** Users have stable internet access
- **S-02:** Initial volume will not exceed 10,000 users
📌 11. 路线图 / 阶段

划分为可管理的阶段：

示例：

## Roadmap

### MVP (Phase 1) - 3 months

- Registration and authentication
- Product catalog
- Shopping cart
- Basic payment with Stripe

### Phase 2 - 2 months

- Notifications system
- Order history
- Basic administration panel

### Phase 3 - 3 months

- Advanced reports
- Logistics integration
- Recommendations system
📌 12. 架构决策记录（ADR）

记录关键技术决策，以保留背景信息。

示例：

  • ADR-001： 使用 PostgreSQL 确保关系数据完整性。
  • ADR-002： 使用 Redis 缓存实时通知。

详情请参阅 references/adr-template.md。

📌 13. 可追溯性矩阵和标签

嵌入累积标签，弥合需求与实现之间的差距。

格式： @brd: BRD.01.01 @req: REQ-001

请参阅 references/traceability-guide.md。

📌 14. 质量门禁和评分

在继续之前，评估文档的成熟度。

  • 成熟度级别： [0-100%]
  • 状态： [草稿 | 可供开发 | 已批准]
  • 缺失项： 待补充的差距清单。

收集流程（分步进行）

0. 流程启动和路线图

说明： 在交互一开始，你必须：

  1. 自我介绍： 简要说明你是一名采用专业方法的业务需求分析师。
  2. 介绍路线图： 说明你将遵循的 6 个阶段（发现 → 愿景 → 流程 → 功能性/非功能性 → 数据模型 → 路线图），让用户了解预期流程。
  3. 确认文档： 如果用户提供了文件或先前的上下文，请说明你会先进行分析，以免询问已提供的信息。
1. 发现和上下文分析（智能发现）

说明：

  • 先分析： 提问之前，先扫描所有已提供的文件（图像、文本、文档）。
  • 查找差距： 从上下文中提取所有可能的信息（利益相关者、问题、目标）。
  • 避免重复规则： 如果文档中已经说明了问题，绝不要再问“问题是什么？”。而应进行确认：“我已分析这些文档，并将问题理解为 [X]。这样理解是否正确？”
2. 访谈和深入探讨

说明： 只关注信息缺口。即使你自己就是利益相关者，也要完成以下问题：

  • 这要解决什么问题？
  • 谁会使用它？
  • 他们会如何使用？
  • 有哪些替代方案？
  • 为什么它更好？
2. 令人不适的问题

发现边缘情况的关键：

  • 如果支付失败，会发生什么？
  • 如果用户断开连接，会发生什么？
  • 如果出现重复数据，会发生什么？
  • 如果外部服务宕机，会发生什么？
3. 绘制流程图

创建以下内容的可视化图表：

  • 用户流程
  • 业务流程
  • 系统架构
4. 编写 → 验证 → 调整

迭代流程：

  1. 编写文档的初版
  2. 与利益相关者共同评审
  3. 找出差距和歧义
  4. 调整并完善
  5. 重复以上步骤，直到达成共识
5. 实体与数据模型综合（自动 ERD）

说明：

  • 主动提取： 在整个过程中，识别所有提及的关键实体（例如，订单、用户、库存物品）。
  • 自动生成： 在分析结束时，如果检测到实体，则自动生成“数据模型”部分。
  • 可视化图表： 必须使用 Mermaid.js 语法绘制可视化实体关系图，以便更清晰地展示。
6. 持续更新的文档

保持更新：

  • 使用 Markdown 格式进行版本管理
  • 工具：Notion、Confluence、GitHub Wiki
  • 需求变更时及时更新

完整模板

如需获取可直接使用的模板，请参阅 assets/requirements-template.md。

最终成果

完成全部信息收集后，你将获得：

  • ✅ 开发文档 - 清晰的规格说明
  • ✅ 报价依据 - 明确的范围
  • ✅ 任务委派指南 - 完整的说明
  • ✅ 演示材料 - 用于向合作伙伴或投资者展示

重要提示

  1. 不要一开始就编写需求 - 先了解业务，就像它已经存在一样
  2. 具体明确 - “快”不是需求，“< 2 秒”才是
  3. 说明“为什么” - 不仅要说明“是什么”，还要说明背后的原因
  4. 记录决策 - 说明为何选择某种技术或方法
  5. 保持更新 - 过时的文档比没有文档更糟糕

其他参考资料

如需了解高级技巧和具体示例：

评论

支持 Markdown