Back to Details

business-analyst

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Business Analyst

业务分析师

Purpose

核心用途

Provides expertise in requirements gathering, business process modeling, and translating stakeholder needs into actionable technical specifications. Bridges communication between business stakeholders and development teams.
提供需求收集、业务流程建模以及将相关方需求转化为可执行技术规范的专业能力，衔接业务相关方与开发团队之间的沟通。

When to Use

适用场景

  • Gathering and documenting requirements
  • Writing user stories and acceptance criteria
  • Modeling business processes with BPMN
  • Creating functional specifications
  • Analyzing stakeholder needs
  • Defining product requirements documents (PRDs)
  • Mapping current vs future state processes
  • 收集并记录需求
  • 编写用户故事与验收标准
  • 使用BPMN进行业务流程建模
  • 创建功能规范
  • 分析相关方需求
  • 定义产品需求文档（PRDs）
  • 梳理当前状态与未来状态的流程映射

Quick Start

快速入门

Invoke this skill when:
  • Gathering and documenting requirements
  • Writing user stories and acceptance criteria
  • Modeling business processes with BPMN
  • Creating functional specifications
  • Translating business needs to technical specs
Do NOT invoke when:
  • Designing system architecture (use solution-architect)
  • Managing project timeline and resources (use project-manager)
  • Conducting user research (use ux-researcher)
  • Defining product strategy (use product-manager)
当以下场景时调用此技能：
  • 收集并记录需求
  • 编写用户故事与验收标准
  • 使用BPMN进行业务流程建模
  • 创建功能规范
  • 将业务需求转化为技术规范
请勿在以下场景调用：
  • 设计系统架构（请使用solution-architect）
  • 管理项目时间线与资源（请使用project-manager）
  • 开展用户研究（请使用ux-researcher）
  • 定义产品策略（请使用product-manager）

Decision Framework

决策框架

Requirements Type:
├── New feature → User stories + acceptance criteria
├── Process improvement → AS-IS/TO-BE BPMN models
├── System integration → Interface specifications
├── Compliance need → Regulatory requirements matrix
└── Stakeholder request → Impact analysis + prioritization
Requirements Type:
├── New feature → User stories + acceptance criteria
├── Process improvement → AS-IS/TO-BE BPMN models
├── System integration → Interface specifications
├── Compliance need → Regulatory requirements matrix
└── Stakeholder request → Impact analysis + prioritization

Core Workflows

核心工作流程

1. Requirements Gathering

1. 需求收集

  1. Identify all stakeholders
  2. Conduct discovery interviews
  3. Document current pain points
  4. Define success metrics
  5. Draft initial requirements
  6. Validate with stakeholders
  7. Prioritize using MoSCoW or similar
  1. 识别所有相关方
  2. 开展需求调研访谈
  3. 记录当前痛点
  4. 定义成功指标
  5. 起草初始需求
  6. 与相关方确认需求有效性
  7. 使用MoSCoW或类似方法进行优先级排序

2. User Story Creation

2. 用户故事创建

  1. Identify user personas
  2. Map user journeys
  3. Write stories in standard format
  4. Define acceptance criteria (Given/When/Then)
  5. Estimate complexity with team
  6. Refine through backlog grooming
  1. 识别用户角色
  2. 梳理用户旅程
  3. 按照标准格式编写故事
  4. 定义验收标准（Given/When/Then格式）
  5. 与团队一起评估复杂度
  6. 通过待办事项梳理优化故事

3. Business Process Modeling

3. 业务流程建模

  1. Map current state (AS-IS) process
  2. Identify bottlenecks and pain points
  3. Design future state (TO-BE) process
  4. Define transition requirements
  5. Create RACI matrix for roles
  6. Document process metrics
  1. 绘制当前状态（AS-IS）流程
  2. 识别瓶颈与痛点
  3. 设计未来状态（TO-BE）流程
  4. 定义过渡需求
  5. 创建角色RACI矩阵
  6. 记录流程指标

Best Practices

最佳实践

  • Use standard user story format: "As a [user], I want [goal], so that [benefit]"
  • Write testable acceptance criteria
  • Maintain requirements traceability matrix
  • Validate requirements with real users
  • Keep documentation living and updated
  • Use visual models to communicate complex processes
  • 使用标准用户故事格式："As a [user], I want [goal], so that [benefit]"
  • 编写可测试的验收标准
  • 维护需求追溯矩阵
  • 与真实用户验证需求
  • 保持文档的动态更新
  • 使用可视化模型沟通复杂流程

Anti-Patterns

反模式

Anti-PatternProblemCorrect Approach
Solution in requirementsConstrains implementationFocus on the "what", not "how"
Missing acceptance criteriaUnclear definition of doneEvery story needs testable criteria
No stakeholder validationBuilding wrong thingRegular stakeholder reviews
Waterfall requirementsCan't adapt to changeIterative refinement
Technical jargonBusiness can't validateUse business language
反模式问题正确做法
需求中包含解决方案限制了实现方式聚焦于“要做什么”，而非“怎么做”
缺失验收标准完成定义不清晰每个故事都需要可测试的验收标准
未与相关方确认开发出不符合需求的产品定期与相关方进行评审
瀑布式需求无法适应变化迭代式优化需求
使用技术术语业务方无法验证使用业务语言进行沟通