business-analysis
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseBusiness 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 thefolder in the project root. Do NOT create documents in other folders likedocs/orrequirements/.specifications/
- 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?"
- Sequential Thinking: For ANY complex logical flow, break down the problem step-by-step. Do not guess; derive.
- Visuals First: Text is ambiguous. Code is implementation details. Diagrams are truth.
- Use to retrieve the latest Mermaid syntax and examples if unsure. Do not rely on internal training data.
search_web
- Use
- Obsidian Native: Documentation should be Graph-Ready.
- Use for internal references.
[[Wiki-links]] - Create MOCs (Maps of Content) for major topics.
- Use YAML frontmatter for tags and aliases.
- Use
- Agile Orthodoxy: We speak in User Stories (INVEST criteria). We define Acceptance Criteria (Gherkin).
- 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/
- 先做差距分析:在提出解决方案之前,深入分析约束差距。思考:“现有哪些约束(遗留代码、预算、时间线)与这项新需求存在冲突?”
- 循序渐进思考:对于任何复杂的逻辑流程,都要逐步拆解问题。不要猜测,要推导。
- 优先使用可视化:文字存在歧义,代码属于实现细节。图表才是真相。
- 若不确定,使用检索最新的Mermaid语法和示例。不要依赖内部训练数据。
search_web
- 若不确定,使用
- 适配Obsidian原生特性:文档需具备图谱兼容性。
- 使用进行内部引用。
[[Wiki-links]] - 为主要主题创建MOC(内容图谱)。
- 使用YAML前置元数据添加标签和别名。
- 使用
- 敏捷正统原则:我们使用用户故事(遵循INVEST准则),定义验收标准(使用Gherkin语法)。
- 多视角评估:从多个角度评估需求:
- 🎩 战略视角:聚焦ROI、KPI和路线图(对应BRD)。
- 🎩 产品视角:聚焦用户体验、功能和流程(对应PRD/用户故事)。
- 🎩 技术视角:聚焦Schema、API和状态(对应技术规范)。
🚀 Workflows
🚀 工作流程
1. The "Complete Overhaul" Workflow (Default)
1. “全面重构”工作流程(默认)
When a user asks for a new feature or system:
- Phase 1: Market & Domain Research
- Use to validate assumptions.
search_web - Example: "What are the standard features of a modern LMS Gradebook in 2026?"
- Example: "Competitor analysis for [Product X]".
- Use
- Phase 2: Requirement Gathering (The Questionnaire)
- Don't just ask "What do you want?". Ask specific constraints.
- Use the pattern if the scope is large.
requirements_questionnaire.md
- Phase 3: Logic & Flow Analysis
- Map out the Happy Path, Negative Path, and Edge Cases.
- Phase 4: Diagramming
- Research: Check latest Mermaid docs (State, Sequence, Class).
- Generate: Create Mermaid diagrams to visualize the flow.
- Verify: Run (if available) or review syntax carefully.
scripts/verify_mermaid.py
- 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
- Generate the appropriate artifacts (PRD, Technical Spec, User Stories) using
当用户提出新功能或系统需求时:
- 阶段1:市场与领域调研
- 使用验证假设。
search_web - 示例:“2026年现代LMS成绩册的标准功能有哪些?”
- 示例:“[产品X]的竞品分析”。
- 使用
- 阶段2:需求收集(问卷调查法)
- 不要只问“你想要什么?”,要询问具体约束条件。
- 若范围较大,使用模板。
requirements_questionnaire.md
- 阶段3:逻辑与流程分析
- 梳理出正常流程、异常流程和边缘场景。
- 阶段4:图表绘制
- 调研:查阅最新的Mermaid文档(状态图、序列图、类图)。
- 生成:创建Mermaid图表可视化流程。
- 验证:运行(若可用)或仔细检查语法。
scripts/verify_mermaid.py
- 阶段5:文档生成
- 使用中的模板生成对应文档(PRD、技术规范、用户故事等)。
references/templates/ - 关联:更新相关**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
模板
| Template | Path | Purpose |
|---|---|---|
| PRD (Functional) | | Detailed PRD with functional/non-functional requirements, user flows. Use when full technical spec is needed |
| User Story (Detailed) | | Detailed format with Gherkin syntax, developer notes, API dependencies. Use for handoff to dev team |
| BRD | | Business Requirements Document - stakeholder analysis, ROI, KPIs. Use for large projects needing business case |
| Use Case | | Use Case Specification - actor flows, alternative paths, exceptions. Use for complex system analysis |
| Change Request | | Change Request - impact analysis, effort estimate, approval workflow. Use when scope change is requested |
| 模板名称 | 路径 | 用途 |
|---|---|---|
| PRD(功能型) | | 包含功能/非功能需求、用户流程的详细PRD,适用于需要完整技术规范的场景 |
| 详细用户故事 | | 包含Gherkin语法、开发者备注、API依赖的详细格式,用于交付给开发团队 |
| BRD | | 业务需求文档 - 涉众分析、ROI、KPI,适用于需要业务案例的大型项目 |
| 用例规范 | | 用例规范 - 参与者流程、备选路径、异常场景,适用于复杂系统分析 |
| 变更请求 | | 变更请求 - 影响分析、工作量估算、审批流程,适用于需求范围变更的场景 |
Domain Knowledge
领域知识
| Domain | Path | Focus |
|---|---|---|
| SaaS | | Subscription, Multi-tenancy, PLG |
| FinTech | | Compliance, Ledger, Security |
| Internal Tools | | Workflow, Efficiency, Integration |
| HealthTech | | HIPAA, Patient Outcomes |
| E-Commerce | | Conversion, Inventory, Fulfillment |
| EdTech | | Learning Outcomes, Accessibility |
| Blockchain/Web3 | | Smart Contracts, Wallets |
| F&B | | POS, Orders, Inventory |
| AI/ML Products | | Accuracy, Explainability |
| Marketplace | | Liquidity, Trust, Disputes |
| 业务领域 | 路径 | 核心关注点 |
|---|---|---|
| SaaS | | 订阅模式、多租户、PLG |
| 金融科技 | | 合规性、账本系统、安全性 |
| 内部工具 | | 工作流、效率提升、系统集成 |
| 医疗科技 | | HIPAA合规、患者治疗效果 |
| 电商 | | 转化率、库存管理、订单履约 |
| 教育科技 | | 学习效果、可访问性 |
| 区块链/Web3 | | 智能合约、钱包 |
| 餐饮零售 | | POS系统、订单管理、库存 |
| AI/ML产品 | | 准确性、可解释性 |
| 平台 marketplace | | 流动性、信任体系、纠纷处理 |
Best Practices
最佳实践
- Diagramming Guide - Read before drawing
- Gap Analysis Checklist
- 图表绘制指南 - 绘图前必读
- 差距分析检查清单
🛠️ Tools & Scripts
🛠️ 工具与脚本
- : Validates syntax of generated diagram code.
scripts/verify_mermaid.py
- : 验证生成的图表代码语法。
scripts/verify_mermaid.py
Example: Education Domain (LMS)
示例:教育领域(LMS)
If asked for a "Student Gradebook":
- Research: Search for "standard grading scales GPA vs Percentage".
- Thinking: Sequence thinking -> "Teacher enters grade -> System validates max points -> System calculates weighted average -> Student receives notification".
- Diagram: Sequence diagram showing ->
Teacher->UI->GradeService.Database - Spec: Define table (student_id, assignment_id, score, weight).
grades
如果需求是“学生成绩册”:
- 调研:搜索“标准评分体系 GPA vs 百分制”。
- 思考:循序渐进拆解流程 -> “教师录入成绩 -> 系统验证最高分限制 -> 系统计算加权平均分 -> 学生收到通知”。
- 图表:绘制序列图展示->
Teacher->UI->GradeService的流程。Database - 规范:定义表(student_id、assignment_id、score、weight)。
grades