skills/jssfy/k-skills/go-backend-requirement-analysis

go-backend-requirement-analysis

SKILL.md

Go 后端需求分析

在技术设计或编码前使用,适用于涉及后端功能、API、异步任务、存储变更或服务集成的需求。

适用时机

  • 用户说"分析一下这个需求" / "帮我梳理需求" / "requirement analysis"
  • 开始技术设计或编码前,需求尚未明确
  • 用户描述的是业务目标,尚未转化为后端实现边界
  • 任何涉及 API 设计、数据存储、异步任务或服务集成的新功能

输入

按优先级获取需求内容:

  1. 对话上下文:用户在消息中描述了需求,直接使用
  2. 用户提供路径:用户指定了 PRD / 需求文档路径,直接读取
  3. 自动发现:在当前工作目录中查找最近修改的需求文档
ls -t $(find . -maxdepth 3 \( -name "*prd*" -o -name "*requirement*" -o -name "*需求*" \) -name "*.md" 2>/dev/null) 2>/dev/null | head -5

若自动发现到多个候选文件,列出并让用户确认。若未找到任何文件,提示用户描述需求或提供文档路径。

目标

  • 用后端术语重新描述业务请求
  • 区分已确认事实、假设和未知项
  • 产出可实施的验收标准
  • 尽早暴露后端特有风险

工作流程

第一步:理解请求

提取以下信息:

  • 业务目标
  • 用户或上游系统的动作
  • 预期输出
  • 用户已明确的约束

如果用户描述模糊,做最小安全假设并标注为「假设」。

EARS 结构化:将需求改写为结构化句式,消除歧义:

句式 适用场景 示例
When [事件], the system shall [行为] 事件触发型 When 用户提交订单,系统应扣减库存
While [状态], the system shall [行为] 持续状态型 While 支付待处理,系统应禁止取消
If [条件], then the system shall [行为] 条件分支型 If 超出配额,系统应返回 429 并附 retry-after
The system shall [行为] 无条件约束 系统应对 PII 字段静态加密

每条核心需求至少用一种 EARS 句式表达。

第二步:拆解后端维度

始终分析以下维度:

  • 领域实体与状态转换
  • API 或消息契约
  • 读写路径
  • 数据校验规则
  • 权限与租户隔离边界
  • 一致性与幂等性要求
  • 失败处理与重试策略
  • 可观测性预期
  • 性能与容量预期
  • 发布与回滚约束

现状验证(必做)

在产出需求文档之前,验证以下三项可行性:

数据可用性

  • 所需数据是否已存在于系统中?
  • 是否需要新增采集或迁移?历史数据如何处理?

接口可行性

  • 依赖的上下游接口是否已存在?
  • 契约是否稳定(版本、字段、SLA)?是否需要协调外部团队?

依赖就绪度

  • 所需基础设施(队列、缓存、存储)是否已就绪?
  • 依赖服务的当前状态(稳定 / 开发中 / 计划中)?

第三步:输出需求文档

使用以下结构:

# 需求分析

## 核心结论

> **结论**:[一句话说明需求是否可行、主要约束、推荐的 MVP 范围]
>
> **关键风险**:[最高优先级的 1-3 个风险]
>
> **建议行动**:[下一步最重要的决策或确认项]

## 需求追溯表

| Req# | 需求描述 | 优先级 | 来源/假设 | 验收标准编号 |
|------|----------|--------|-----------|-------------|
| R1   |          | Must   | 用户明确  | AC1, AC2    |
| R2   |          | Should | 假设      | AC3         |

## 目标

## 范围内

## 范围外

## 参与方与依赖

## 领域模型

## API 或事件契约

## 业务规则

## 非功能需求

## 验收标准

| AC# | 场景 | 前置条件 | 操作 | 预期结果 | 可验证 |
|-----|------|----------|------|----------|--------|
| AC1 |      |          |      |          | ✅/⚠️/❌ |

> 可验证标注:✅ 数据和接口已就绪 | ⚠️ 需前置工作 | ❌ 当前不可验证(列入待确认项)

## 风险与待确认项

第四步:定义验收标准

好的验收标准应具备:

  • 可观测性(能被测试或监控验证)
  • 后端可验证(不依赖前端)
  • 边界感知(覆盖边界条件)
  • 失败感知(覆盖失败路径)

必须包含以下路径:

  • 正常路径
  • 无效输入路径
  • 重复请求路径
  • 依赖失败路径
  • 权限失败路径

Go 后端关注清单

  • 是否有明确的请求边界和处理入口?
  • DTO 是否与领域对象分离?
  • 状态转换是否明确?
  • 写操作是否需要幂等性?
  • 最终一致性是否可接受?
  • 超时、重试和取消规则是否已定义?
  • 是否需要审计日志或指标?
  • 是否有 SLO 或延迟目标要求?

输出规则

  • 不要过早进入包结构或表结构设计。
  • 不要写具体的 IDL 定义、数据库 schema 或代码片段——需求层只描述"需要哪些参数、什么类型、互斥关系",具体字段编号、annotation、Go struct 留给技术设计阶段。
  • 不隐藏未知项,明确列出。
  • 如果需求过大,拆分为阶段:MVP、加固、规模化。
  • 优先给出精确的验收标准,而非实现建议。
  • 核心结论必须置顶,包含可操作的决策建议。
  • 需求追溯表必须在核心结论之后,确保每条需求可追溯至验收标准。

参考资料

  • 快速问题清单参见 references/checklist.md

交接

需求分析完成后,在对话末尾告知用户可选的后续步骤,等待用户明确指示后再继续,不得自动进入下一阶段

  • /go-backend-technical-design — 组件与接口设计
  • /go-backend-architecture — 跨服务或长期架构决策(可选)
Weekly Installs
10
Repository
jssfy/k-skills
GitHub Stars
1
First Seen
4 days ago
Installed on
claude-code10
github-copilot9
codex9
kimi-cli9
gemini-cli9
cursor9