---
name: sr-ar-decomposition
description: SR→AR decomposition methodology and templates for requirements engineering. Use when decomposing System Requirements (SR) into Allocation Requirements (AR), applying DDD bounded context mapping, defining subsystem interfaces and dependencies, or establishing IR→SR→AR traceability chains.
---

# Skill: SR-AR 分解分配（需求分解分配）

## 技能用途

基于功能列表和需求信息，结合当前**代码项目**和**业界参考方案**，将系统级需求（SR）分解为模块级分配需求（AR），应用领域驱动设计（DDD）进行限界上下文划分，定义子系统接口与依赖关系，建立完整的 IR→SR→AR 追溯链。

本技能的输出直接支撑后续两个设计阶段：

- **系统功能设计**：以 SR 清单和 NFR 为输入，进行系统级规格分解
- **模块功能设计**：以 SR-AR 映射为输入，进行逐功能实现设计

---

## Input Context

Before beginning analysis, scan all available context sources in the current workspace. Do not assume fixed file locations — look for:

- **功能列表文档** (required): containing functional descriptions, NFR/DFX summary
- **需求信息文档 / IR** (required): 5W2H structured initial requirement document
- **Project codebase** (strongly recommended): for understanding existing module boundaries, interface contracts, and tech stack constraints
- **Existing architecture documents** (if present): deployment topology, module inventory
- **Domain reference materials** (if present): structured requirement summaries, design references

---

## 核心指导原则

### 1. SR 保守原则（重要）

**SR 的数量应保持克制，默认从 1 个 SR 开始，只有在有充分理由时才增加。**

在分解出第二个（或更多）SR 之前，先问自己：

```
"这个 SR 为什么不能合并到已有的 SR 中？"

合理的拆分理由：
  ✅ 两个 SR 归属于完全不同的子系统（Who 不同）
  ✅ 两个 SR 的性能/规模指标差异显著，需要独立分解 How Much
  ✅ 两个 SR 的生命周期阶段明显不同（When 不同）

不合理的拆分理由：
  ❌ "功能比较多" — 功能多不等于 SR 多，一个 SR 可以关联多个功能
  ❌ "感觉可以分开" — 拆分需要明确业务理由
  ❌ 照搬功能列表逐一生成 SR — SR 是系统能力视角，不是功能枚举
```

**若需要超过 2 个 SR，必须在继续前与用户确认**（见「与用户协作」章节）。

### 2. SR 与功能的对应关系

**SR 是一组相关功能的系统级聚合**，一个 SR 通常对应功能列表中的多个功能。

```
SR（系统能力视角）
  └── F001 用户登录认证
  └── F002 登录失败处理
  └── F003 会话管理

SR（系统能力视角）
  └── F004 角色配置
  └── F005 权限校验
```

从功能列表出发识别 SR 的方法：

1. 将功能按业务域或子系统归组
2. 同一归组的功能 → 候选 SR
3. 判断这组功能是否真的需要独立 SR，还是可以合并

### 3. SR 5W2H 描述规范

SR 的 5W2H 聚焦于**系统实现层面**，而非业务层面：

| 维度 | 含义 | 填写指南 |
| :--- | :--- | :--- |
| **Who** | 系统或子系统 | 哪个系统/子系统负责此需求，明确到子系统级别 |
| **When** | 系统生命周期阶段 | 功能在哪个生命周期起作用（启动/运行/升级/维护等） |
| **What** | 功能内容 | 新增或变更的功能描述，区分新增与变更 |
| **Where** | 功能运行上下文 | 服务端/客户端、部署单元、网络分区 |
| **How Much** | 规模/规格指标 | 从 IR 的 How Much 继承或分解，含余量 |
| **How** | 使用方式 | 在当前系统中怎么使用这个功能、如何与其他功能协作 |

**填写经验：**

```
Who 的粒度控制：
  ✅ "用户认证子系统" — 明确到子系统级别
  ✅ "订单管理模块（OrderService）" — 已有系统可到模块级别
  ❌ "系统" — 太笼统，无法指导 AR 分配

How Much 的分解原则：
  IR: "系统支持 1000 TPS"
  若只有一个 SR → 直接继承（可加余量：1100 TPS）
  若拆为多个 SR → 每个 SR 独立分解，下游 ≥ 上游含余量：
    SR-001 API 层：1200 TPS（含 20% 余量）
    SR-002 数据层：1100 TPS（含 10% 余量）

How 要结合现有系统：
  ✅ "通过 Spring Security OAuth2 实现认证，JWT Token 作为会话凭证，
      与现有 UserService 集成获取用户信息"
  ❌ "实现认证功能" — 没有描述如何在当前系统中发挥作用
```

---

### 4. AR 分配方法论

**AR 编号规则：** `AR-SSS-NN`（SSS 为 SR 编号后三位，NN 为该 SR 下的 AR 序号）。例：AR-001-01, AR-001-02。

**AR 数量控制原则（重要）：**

**每个 SR 默认对应 1-2 个 AR，只有在有充分理由时才增加到 3 个及以上。**

在分解出第三个（或更多）AR 之前，先问自己：

```
"这个 AR 为什么不能合并到已有的 AR 中？"

合理的拆分理由：
  ✅ 两个 AR 归属不同的系统元素（不同的模块/服务）
  ✅ 两个 AR 的实现技术栈不同（如前端 UI vs 后端 API）
  ✅ 两个 AR 可以被不同开发者并行实现，且边界清晰
  ✅ 两个 AR 的 NFR/DFX 约束差异显著

不合理的拆分理由：
  ❌ "功能点比较多" — 多个功能点可以在一个 AR 中描述
  ❌ "方便分工" — AR 是需求分配单元，不是任务拆分单元
  ❌ 每个功能点生成一个 AR — AR 是模块级分配，不是功能枚举
```

**若一个 SR 需要超过 3 个 AR，必须在继续前与用户确认**（见「与用户协作」章节）。

**AR 描述规范：**

| 字段 | 要求 |
| :--- | :--- |
| **系统需求** | 对应的 SR 编号和名称 |
| **分配需求描述** | 必须比 SR 更具体，接近实现层面，包含可验证的指标 |
| **系统元素** | 明确到具体的服务/组件/模块（如 OrderService） |

**AR 粒度控制：**

```
太粗：AR-001-01 "实现订单管理全部功能"
合适：AR-001-01 "OrderService 接收订单请求，执行参数校验和价格计算，在 80ms 内完成"
太细：AR-001-01 "校验订单金额不为空"

判断标准：
- 一个 AR 是否可以被一个开发者独立实现和测试？
- AR 的描述是否足够具体，开发者无需再做架构判断？
- AR 是否只归属于一个系统元素？
```

**系统元素识别：**

```
已有系统：
  优先分配到已有系统元素；只有现有元素无法承载时才新增，并说明原因

新建系统：
  从 DDD 限界上下文推导；参考业界同类系统模块划分
  命名采用 {业务域}{职责} 模式（如 OrderService、PaymentGateway）

注意：系统元素 ≠ 代码类。一个系统元素可包含多个代码类。
```

---

### 5. DDD 限界上下文映射

```
步骤 1: 识别业务域
  从功能列表中提取业务领域（认证域、订单域、支付域等）
  已有系统以现有代码模块划分为起点

步骤 2: 划分限界上下文
  每个限界上下文 = 一个内聚的业务模块
  参考业界同类系统验证合理性

步骤 3: 定义上下文映射关系
  确定模块间的依赖和集成模式

步骤 4: 分配 AR 到系统元素
  每个 AR 归属到唯一的系统元素
```

**限界上下文划分检验：**

| 原则 | 检验方法 |
| :--- | :--- |
| 高内聚 | 上下文内的功能是否都服务于同一业务能力？ |
| 低耦合 | 移除某个上下文后，其他上下文是否仍能独立定义？ |
| 单一职责 | 能否用一句话描述此上下文的职责？ |

**上下文映射关系类型：**

```
[U/D] Upstream/Downstream — 上下游依赖
[ACL] Anti-Corruption Layer — 防腐层（隔离外部模型）
[OHS] Open Host Service — 开放主机服务（提供标准接口）
[PL]  Published Language — 发布语言（共享数据格式）
[CF]  Conformist — 跟随者（直接使用上游模型）
[SK]  Shared Kernel — 共享内核（共享部分模型）
```

---

### 6. NFR/DFX 到 AR 的分配

NFR 必须被分配到具体 AR 才能被实现和验证，不能作为"全局"悬空约束。

| NFR 类型 | 分配策略 |
| :--- | :--- |
| 性能 | 分配到直接处理数据流的 AR |
| 安全 | 分配到涉及认证/授权/加密的 AR |
| 可靠性 | 分配到关键路径上的 AR |
| 隐私 | 分配到处理敏感数据的 AR |

**NFR 冲突解决（strictest-metric）：** 取最严格值。优先级：IR 约束 > 场景需求 > 用例 DFX 属性。

---

## 实战工作流程

### 七步法

```
步骤 1: 读取输入
  读取功能列表和 IR 文档，提取所有功能和约束

步骤 2: 收集参考资料
  浏览当前项目代码：模块划分、接口定义、技术栈
  搜索业界参考方案：同类系统架构、设计模式

步骤 3: 功能归组 → 草拟 SR
  将功能按业务域归组，草拟候选 SR
  默认从 1 个 SR 开始；拆分前先问"为什么？"
  超过 2 个 SR 时，与用户确认

步骤 4: DDD 限界上下文划分
  结合现有代码结构，识别业务域和上下文
  确定系统元素

步骤 5: SR 分解
  为每个 SR 填写 5W2H，继承/分解 IR 的 When 和 How Much
  关联对应的功能编号列表

步骤 6: AR 分配
  将每个 SR 分解为一或多个 AR，确定系统元素
  将 NFR/DFX 约束传递到相关 AR 描述中

步骤 7: 汇总、追溯验证与确认
  建立 IR→SR 映射总览，检查追溯完整性
  向用户确认分解方案，输出文档
```

---

## 与用户协作

以下确认对话均需通过提问工具以列表形式一次性呈现多个问题或确认项，而非在自然语言中直接列出，确保信息收集的完整性和效率。

### SR 数量超限确认（超过 2 个时触发）

```
"我识别出 N 个 SR 候选，超出了建议的 1-2 个上限：

- SR-001：[名称]，关联功能：F001, F002, F003
- SR-002：[名称]，关联功能：F004, F005
- SR-003（新增候选）：[名称]，关联功能：F006
  拆分理由：[具体说明 Who/When/How Much 的差异]

请确认：
1. 是否认可 SR-003 单独拆分的理由？
2. 还是将 F006 合并到 SR-001 或 SR-002？"
```

### AR 数量超限确认（单个 SR 超过 3 个 AR 时触发）

```
"SR-{NNN} 分解出 N 个 AR，超出了建议的 1-3 个上限：

- AR-{NNN}-01：[名称]，系统元素：[元素名]
- AR-{NNN}-02：[名称]，系统元素：[元素名]
- AR-{NNN}-03：[名称]，系统元素：[元素名]
- AR-{NNN}-04（新增候选）：[名称]，系统元素：[元素名]
  拆分理由：[具体说明系统元素/技术栈/N约束的差异]

请确认：
1. 是否认可 AR-{NNN}-04 单独拆分的理由？
2. 还是将 [功能点] 合并到现有 AR 中？"
```

### 分解方案确认对话

```
"我完成了 SR-AR 分解初稿：

【SR 分解概要】
- 共 N 个 SR，关联 M 个功能
- SR-001 [名称]：关联 F001, F002, F003
- SR-002 [名称]：关联 F004, F005

【AR 分配概要】
- 共 K 个 AR，分配到 P 个系统元素
- 系统元素：[列表]

【关键设计决策】
- [决策1及依据]
- [决策2及依据]

请确认：
1. SR 的功能归组是否合理？
2. 5W2H 描述是否准确？
3. AR 的系统元素分配是否合理？
4. 是否有遗漏的系统需求？"
```

### 微确认问题

```
"SR-NNN 的 Who 无法确定：功能 F-NNN 涉及多个子系统（认证 + 权限），
应归属哪个子系统？还是需要拆分为两个 SR？"

"IR 的 How Much 为'支持 1000 并发'，当前只有一个 SR 是否直接继承（加余量为 1100）？"

"现有代码中 [ModuleName] 已实现部分功能，SR-NNN 的 What 应描述为
'新增功能'还是'功能变更'？变更点是：[具体描述]"
```

---

## 输出格式

**主输出文件：** `sr-ar-decomposition.md`，放置于项目当前工作目录或与其他分析文档相同的目录。

完整模板格式参见 `references/sr-ar-template.md`。

**输出结构概要：**

```markdown
# SR-AR 分解分配表

## IR-SR 映射总览

| 初始需求 | 系统需求 | 需求描述摘要 | 关联功能 |
| :--- | :--- | :--- | :--- |
| IR-001 | SR-001 | [SR 描述摘要] | F001, F002, F003 |
| IR-001 | SR-002 | [SR 描述摘要] | F004, F005 |

## SR 分解

### SR-001（{SR 名称}）

#### 初始需求
[对应的 IR 编号和简要描述]

#### 系统需求描述
- **Who**: [子系统名称]
- **When**: [生命周期阶段]
- **What**: [功能内容/变更点]
- **Where**: [运行上下文]
- **How Much**: [规模/规格指标]
- **How**: [在系统中如何使用和发挥作用]

#### 关联功能
- F001 [功能名称]
- F002 [功能名称]
- F003 [功能名称]

## AR 分配

### AR-001-01（{AR 名称}）

#### 系统需求
SR-001: [SR 名称]

#### 分配需求描述
[详细实现要求，比 SR 更具体，含可验证指标]

#### 系统元素
[负责实现的逻辑元素名称]
```

---

## 质量检查清单

```
□ 所有 IR 都被至少一个 SR 覆盖
□ SR 数量克制（通常 1-2 个），超过 2 个已获用户确认
□ 每个 SR 都关联了对应的功能编号列表
□ 每个 SR 的 5W2H 描述完整
□ SR 的 Who 明确到子系统级别，非笼统的"系统"
□ SR 的 How Much 正确继承或分解了 IR 的 How Much
□ SR 的 How 描述了功能在当前系统中的使用方式
□ 每个 SR 被分解为至少一个 AR
□ 每个 SR 的 AR 数量克制（通常 1-3 个），超过 3 个已获用户确认
□ AR 编号格式正确（AR-SSS-NN），无重复
□ 每个 AR 的描述比 SR 更具体，包含可验证指标
□ 每个 AR 只归属于一个系统元素（单一归属原则）
□ NFR/DFX 已传递到具体 AR，非全局悬空约束
□ DDD 限界上下文划分合理（高内聚、低耦合）
□ IR→SR→AR 追溯链完整，无断链、无孤立 AR
□ 用户已确认分解方案和关键设计决策
```

## 反模式（Anti-Patterns）

**不要：**

- 将功能列表逐一映射为 SR — SR 是系统能力聚合，不是功能枚举
- SR 过多而无充分理由 — 默认 1-2 个，超出需自问"为什么"
- SR 的 Who 写"系统"而不指明具体子系统
- SR 的 How 只写"实现 XX 功能" — 必须描述在当前系统中如何运作
- NFR 作为"全局约束"而不传递到具体 AR
- 一个 AR 归属多个系统元素
- 照搬 SR 描述作为 AR 描述 — AR 应更具体、更接近实现

**要做：**

- 功能先归组，再从归组中识别 SR
- 先问"能合并吗"，再决定是否拆分 SR
- 每个 SR 的 5W2H 完整，特别是 Who、How Much 和 How
- AR 比 SR 更具体，包含实现层面的决策
- 分析现有代码结构后再分配 AR
- NFR 落实到具体 AR 描述中