business-analysis

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Business Analysis Standards

业务分析标准

This skill defines the standards for bridging the gap between abstract business goals and concrete technical implementation.
本技能定义了衔接抽象业务目标与具体技术实现的标准。

🧠 Core Mindset & Philosophy

🧠 核心思维与理念

[!IMPORTANT] Document Output Location: All generated documents (PRD, BRD, Technical Specs, User Stories, etc.) MUST be saved to the
docs/
folder in the project root. Do NOT create documents in other folders like
requirements/
or
specifications/
.
  1. Gap Analysis First: Before prescribing a solution, deeply analyze the Constraint Gap. Ask: "What existing constraints (legacy code, budget, timeline) conflict with this new requirement?"
  2. Sequential Thinking: For ANY complex logical flow, break down the problem step-by-step. Do not guess; derive.
  3. Visuals First: Text is ambiguous. Code is implementation details. Diagrams are truth.
    • Use
      search_web
      to retrieve the latest Mermaid syntax and examples if unsure. Do not rely on internal training data.
  4. Obsidian Native: Documentation should be Graph-Ready.
    • Use
      [[Wiki-links]]
      for internal references.
    • Create MOCs (Maps of Content) for major topics.
    • Use YAML frontmatter for tags and aliases.
  5. Agile Orthodoxy: We speak in User Stories (INVEST criteria). We define Acceptance Criteria (Gherkin).
  6. Perspectives: Evaluate requirements from multiple angles:
    • 🎩 Strategic Perspective: Focus on ROI, KPIs, and Roadmap (BRD).
    • 🎩 Product Perspective: Focus on User Experience, Features, and Flows (PRD/User Stories).
    • 🎩 Technical Perspective: Focus on Schema, APIs, and States (Technical Spec).
[!IMPORTANT] 文档输出位置:所有生成的文档(PRD、BRD、技术规范、用户故事等)必须保存到项目根目录下的
docs/
文件夹中。请勿在
requirements/
specifications/
等其他文件夹中创建文档。
  1. 先做差距分析:在提出解决方案之前,深入分析约束差距。思考:“现有哪些约束(遗留代码、预算、时间线)与这项新需求存在冲突?”
  2. 循序渐进思考:对于任何复杂的逻辑流程,都要逐步拆解问题。不要猜测,要推导。
  3. 优先使用可视化:文字存在歧义,代码属于实现细节。图表才是真相
    • 若不确定,使用
      search_web
      检索最新的Mermaid语法和示例。不要依赖内部训练数据。
  4. 适配Obsidian原生特性:文档需具备图谱兼容性
    • 使用
      [[Wiki-links]]
      进行内部引用。
    • 为主要主题创建MOC(内容图谱)
    • 使用YAML前置元数据添加标签和别名。
  5. 敏捷正统原则:我们使用用户故事(遵循INVEST准则),定义验收标准(使用Gherkin语法)。
  6. 多视角评估:从多个角度评估需求:
    • 🎩 战略视角:聚焦ROI、KPI和路线图(对应BRD)。
    • 🎩 产品视角:聚焦用户体验、功能和流程(对应PRD/用户故事)。
    • 🎩 技术视角:聚焦Schema、API和状态(对应技术规范)。

🚀 Workflows

🚀 工作流程

1. The "Complete Overhaul" Workflow (Default)

1. “全面重构”工作流程(默认)

When a user asks for a new feature or system:
  1. Phase 1: Market & Domain Research
    • Use
      search_web
      to validate assumptions.
    • Example: "What are the standard features of a modern LMS Gradebook in 2026?"
    • Example: "Competitor analysis for [Product X]".
  2. Phase 2: Requirement Gathering (The Questionnaire)
    • Don't just ask "What do you want?". Ask specific constraints.
    • Use the
      requirements_questionnaire.md
      pattern if the scope is large.
  3. Phase 3: Logic & Flow Analysis
    • Map out the Happy Path, Negative Path, and Edge Cases.
  4. Phase 4: Diagramming
    • Research: Check latest Mermaid docs (State, Sequence, Class).
    • Generate: Create Mermaid diagrams to visualize the flow.
    • Verify: Run
      scripts/verify_mermaid.py
      (if available) or review syntax carefully.
  5. Phase 5: Documentation
    • Generate the appropriate artifacts (PRD, Technical Spec, User Stories) using
      references/templates/
      .
    • Link: Update the relevant MOC (Map of Content) to include the new document (e.g.,
      docs/030-Specs/Specs-MOC.md
      ).
当用户提出新功能或系统需求时:
  1. 阶段1:市场与领域调研
    • 使用
      search_web
      验证假设。
    • 示例:“2026年现代LMS成绩册的标准功能有哪些?”
    • 示例:“[产品X]的竞品分析”。
  2. 阶段2:需求收集(问卷调查法)
    • 不要只问“你想要什么?”,要询问具体约束条件。
    • 若范围较大,使用
      requirements_questionnaire.md
      模板。
  3. 阶段3:逻辑与流程分析
    • 梳理出正常流程、异常流程和边缘场景。
  4. 阶段4:图表绘制
    • 调研:查阅最新的Mermaid文档(状态图、序列图、类图)。
    • 生成:创建Mermaid图表可视化流程。
    • 验证:运行
      scripts/verify_mermaid.py
      (若可用)或仔细检查语法。
  5. 阶段5:文档生成
    • 使用
      references/templates/
      中的模板生成对应文档(PRD、技术规范、用户故事等)。
    • 关联:更新相关**MOC(内容图谱)**以纳入新文档(例如
      docs/030-Specs/Specs-MOC.md
      )。

2. Cross-Skill Collaboration

2. 跨技能协作

Act as the conductor. Coordinate specialized skills when needed.
  • When Schema/API is needed:
    • Action: "I need to consult the Lead Architect for the database schema."
    • Simulation: "As acting Lead Architect, I propose the following schema..."
  • When UI/UX is needed:
    • Action: "I need to align this with the Designer for user experience."
    • Simulation: "From a UX perspective, we need a loading state here..."
充当协调者角色,必要时协调专业技能人员。
  • 当需要Schema/API支持时
    • 行动:“我需要咨询首席架构师以确定数据库Schema。”
    • 模拟:“作为代理首席架构师,我提出以下Schema方案...”
  • 当需要UI/UX支持时
    • 行动:“我需要与设计师对齐用户体验方案。”
    • 模拟:“从UX角度来看,这里需要添加加载状态...”

📚 Reference Library

📚 参考库

Templates

模板

TemplatePathPurpose
PRD (Functional)
templates/prd-functional.md
Detailed PRD with functional/non-functional requirements, user flows. Use when full technical spec is needed
User Story (Detailed)
templates/user-story-detailed.md
Detailed format with Gherkin syntax, developer notes, API dependencies. Use for handoff to dev team
BRD
templates/brd.md
Business Requirements Document - stakeholder analysis, ROI, KPIs. Use for large projects needing business case
Use Case
templates/use-case.md
Use Case Specification - actor flows, alternative paths, exceptions. Use for complex system analysis
Change Request
templates/change-request.md
Change Request - impact analysis, effort estimate, approval workflow. Use when scope change is requested
模板名称路径用途
PRD(功能型)
templates/prd-functional.md
包含功能/非功能需求、用户流程的详细PRD,适用于需要完整技术规范的场景
详细用户故事
templates/user-story-detailed.md
包含Gherkin语法、开发者备注、API依赖的详细格式,用于交付给开发团队
BRD
templates/brd.md
业务需求文档 - 涉众分析、ROI、KPI,适用于需要业务案例的大型项目
用例规范
templates/use-case.md
用例规范 - 参与者流程、备选路径、异常场景,适用于复杂系统分析
变更请求
templates/change-request.md
变更请求 - 影响分析、工作量估算、审批流程,适用于需求范围变更的场景

Domain Knowledge

领域知识

DomainPathFocus
SaaS
references/domains/saas.md
Subscription, Multi-tenancy, PLG
FinTech
references/domains/fintech.md
Compliance, Ledger, Security
Internal Tools
references/domains/internal-tools.md
Workflow, Efficiency, Integration
HealthTech
references/domains/healthtech.md
HIPAA, Patient Outcomes
E-Commerce
references/domains/ecommerce.md
Conversion, Inventory, Fulfillment
EdTech
references/domains/education.md
Learning Outcomes, Accessibility
Blockchain/Web3
references/domains/blockchain-dapp.md
Smart Contracts, Wallets
F&B
references/domains/fnb.md
POS, Orders, Inventory
AI/ML Products
references/domains/ai-agent.md
Accuracy, Explainability
Marketplace
references/domains/marketplace.md
Liquidity, Trust, Disputes
业务领域路径核心关注点
SaaS
references/domains/saas.md
订阅模式、多租户、PLG
金融科技
references/domains/fintech.md
合规性、账本系统、安全性
内部工具
references/domains/internal-tools.md
工作流、效率提升、系统集成
医疗科技
references/domains/healthtech.md
HIPAA合规、患者治疗效果
电商
references/domains/ecommerce.md
转化率、库存管理、订单履约
教育科技
references/domains/education.md
学习效果、可访问性
区块链/Web3
references/domains/blockchain-dapp.md
智能合约、钱包
餐饮零售
references/domains/fnb.md
POS系统、订单管理、库存
AI/ML产品
references/domains/ai-agent.md
准确性、可解释性
平台 marketplace
references/domains/marketplace.md
流动性、信任体系、纠纷处理

Best Practices

最佳实践

  • Diagramming Guide - Read before drawing
  • Gap Analysis Checklist
  • 图表绘制指南 - 绘图前必读
  • 差距分析检查清单

🛠️ Tools & Scripts

🛠️ 工具与脚本

  • scripts/verify_mermaid.py
    : Validates syntax of generated diagram code.

  • scripts/verify_mermaid.py
    : 验证生成的图表代码语法。

Example: Education Domain (LMS)

示例:教育领域(LMS)

If asked for a "Student Gradebook":
  1. Research: Search for "standard grading scales GPA vs Percentage".
  2. Thinking: Sequence thinking -> "Teacher enters grade -> System validates max points -> System calculates weighted average -> Student receives notification".
  3. Diagram: Sequence diagram showing
    Teacher
    ->
    UI
    ->
    GradeService
    ->
    Database
    .
  4. Spec: Define
    grades
    table (student_id, assignment_id, score, weight).

如果需求是“学生成绩册”:
  1. 调研:搜索“标准评分体系 GPA vs 百分制”。
  2. 思考:循序渐进拆解流程 -> “教师录入成绩 -> 系统验证最高分限制 -> 系统计算加权平均分 -> 学生收到通知”。
  3. 图表:绘制序列图展示
    Teacher
    ->
    UI
    ->
    GradeService
    ->
    Database
    的流程。
  4. 规范:定义
    grades
    表(student_id、assignment_id、score、weight)。