Back to Details

cleanddd-requirements-analysis

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

CleanDDD 需求分析技能

CleanDDD Requirements Analysis Skill

面向 CleanDDD 建模前的需求澄清与拆解，产出的结构化需求描述（场景、干系人、业务实体归类），便于后续建模或实现。
For requirements clarification and decomposition prior to CleanDDD modeling, produce structured requirement descriptions (scenarios, stakeholders, business entity classification) to facilitate subsequent modeling or implementation.

前置输入

Prerequisite Inputs

  • 已获得业务需求/变更说明（文档、会议纪要或对话）。
  • 未经模型化或需要对现有模型做重大调整时，先运行本技能再交给 cleanddd-modeling。
  • Business requirements/change descriptions (documents, meeting minutes or conversations) have been obtained.
  • When requirements are not modeled or major adjustments to existing models are needed, run this skill first before passing to cleanddd-modeling.

工作流（只做需求分析与结构化描述，不做建模定义）

Workflow (Only Requirements Analysis and Structured Description, No Modeling Definitions)

  1. 获取与确认范围：收集业务场景、角色、输入输出、约束；缺失信息先追问。
  2. 干系人识别：列出所有参与角色（如 C 端客户、后台管理员、审计、运营等），明确每条需求面向的对象。
  3. 需求拆分：按“查看/创建/修改/关闭/异步任务”切分为可执行条目，给需求ID，并标注对应干系人。
  4. 业务实体归类：将需求条目按负责满足需求的业务实体/领域对象归类，记录核心职责与约束（不做聚合/命令/事件建模）。
  5. “当 X 时做 Y”触发场景：识别事件/状态/操作触发的后续动作，按“触发条件 → 动作/影响 → 涉及角色/实体”记录，仍停留在需求级，不进入建模。
  6. 约束与输入输出：补充关键业务规则、前置条件、依赖系统或数据；标注缺口与假设。
  7. 汇总输出并二次确认：向用户呈现表格，标注假设与待确认项。
  1. Scope Acquisition and Confirmation: Collect business scenarios, roles, inputs/outputs, and constraints; follow up on missing information first.
  2. Stakeholder Identification: List all participating roles (e.g., C-end customers, backend administrators, auditors, operations, etc.), and clarify the target object for each requirement item.
  3. Requirement Decomposition: Split into executable items by "view/create/modify/close/asynchronous task", assign requirement IDs, and label corresponding stakeholders.
  4. Business Entity Classification: Classify requirement items by the business entities/domain objects responsible for meeting the requirements, and record core responsibilities and constraints (no aggregation/command/event modeling).
  5. "Do Y When X" Trigger Scenarios: Identify follow-up actions triggered by events/states/operations, record them in the format of "trigger condition → action/impact → involved roles/entities", and remain at the requirement level without entering modeling.
  6. Constraints and Inputs/Outputs: Supplement key business rules, preconditions, dependent systems or data; label gaps and assumptions.
  7. Summary Output and Secondary Confirmation: Present a table to the user, labeling assumptions and items to be confirmed.

输出格式（结构化 Markdown）

Output Format (Structured Markdown)

  • 干系人表：角色 | 目标/痛点 | 权限/限制 | 备注
  • 需求条目表：需求ID | 场景描述 | 干系人/对象 | 所属业务实体 | 操作类型（查看/创建/修改/关闭/异步等） | 约束/前置 | 备注/缺口
  • 业务实体视图：业务实体 | 覆盖的需求条目 | 主要职责/规则 | 关键输入/输出
  • 触发/后续动作表：触发条件（当 X 操作/事件/状态） | 后续动作/影响（就做 Y） | 相关干系人 | 受影响的业务实体 | 备注/假设
  • 业务规则与依赖（可选）：规则/约束 | 相关实体 | 依赖系统/数据 | 备注
  • 假设与待确认清单：项 | 描述 | 责任人 | 截止/优先级
  • Stakeholder Table: Role | Goals/Pain Points | Permissions/Restrictions | Remarks
  • Requirement Item Table: Requirement ID | Scenario Description | Stakeholder/Target | Belonging Business Entity | Operation Type (view/create/modify/close/asynchronous, etc.) | Constraints/Preconditions | Remarks/Gaps
  • Business Entity View: Business Entity | Covered Requirement Items | Core Responsibilities/Rules | Key Inputs/Outputs
  • Trigger/Follow-up Action Table: Trigger Condition (When X operation/event/state) | Follow-up Action/Impact (Do Y) | Relevant Stakeholders | Affected Business Entities | Remarks/Assumptions
  • Business Rules and Dependencies (Optional): Rules/Constraints | Relevant Entities | Dependent Systems/Data | Remarks
  • Assumptions and To-Confirm List: Item | Description | Responsible Person | Deadline/Priority

统一命名与放置约定

Unified Naming and Placement Conventions

  • 表格命名与列头：统一按章节中的表头格式输出，便于下游技能解析。
  • 术语统一：本技能停留在“需求级”术语，避免提前引入聚合/命令等建模术语；与 
    cleanddd-modeling
    的术语区分清晰。
  • 文档位置：建议将本技能输出保存为仓库内 
    analysis/requirements.md
    或由 Agent 汇总在会话记录中，便于后续 
    cleanddd-modeling
    引用。
  • Table Naming and Column Headers: Output uniformly according to the header format in the chapters to facilitate parsing by downstream skills.
  • Term Uniformity: This skill stays at the "requirement-level" terminology, avoiding premature introduction of modeling terms such as aggregation/commands; clearly distinguish from the terminology of 
    cleanddd-modeling
    .
  • Document Location: It is recommended to save the output of this skill as 
    analysis/requirements.md
    in the repository or have it summarized in the session records by the Agent, for easy reference by subsequent 
    cleanddd-modeling
    .

产出后提醒

Post-Production Reminders

  • 在输出末尾附“参数汇总 + 是否执行”提示，便于后续确认或传递给下游建模技能。
  • 明确未决问题与假设，便于后续建模或实现阶段承接。
  • Attach a "Parameter Summary + Execution Confirmation" prompt at the end of the output to facilitate subsequent confirmation or transfer to downstream modeling skills.
  • Clearly define unresolved issues and assumptions for smooth handover in subsequent modeling or implementation phases.