mcpField
R
requirements-from-brief

requirements-from-brief

github.com/mattjmdesign开发48 次安装
代码仓库

关于 requirements-from-brief

将产品简报转化为可测试的功能与非功能需求，并在选择界面方案前明确范围。适用于梳理产品目标和依赖的团队，也会列出假设、待解问题及建议的后续步骤。

主要功能

  1. 01提取目标与约束
  2. 02编写可测试的功能需求
  3. 03覆盖非功能需求
  4. 04明确范围与依赖
  5. 05列出假设和待解问题
  6. 06建议验收标准与流程规划

适用场景

  1. 01将早期产品简报转为需求
  2. 02梳理 API、数据和身份验证依赖
  3. 03定义首版不包含的事项
  4. 04准备验收标准和用户流程

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mattjmdesign/dengskills --skill requirements-from-brief

安装后在 Claude Code 中输入/requirements-from-brief确认已加载。

附带文件agents/openai.yamlevals/evals.json

详细介绍

简报中的需求

在选择界面方案之前，使用此技能将产品意图转化为需求。需求描述用户和系统需要什么，而不是要使用哪个组件。

流程

  1. 提取用户目标、业务目标、约束条件以及数据/API/身份验证依赖项。
  2. 将功能需求写为 FR-XX: The system shall [action] when [condition] so that [outcome].
  3. 视情况编写有关性能、无障碍性、响应式设计、浏览器支持、安全/隐私、可靠性和国际化的非功能需求。
  4. 明确列出 v1 的范围外事项。
  5. 确定假设和待解决问题。
  6. 建议下一步制定验收标准、站点地图或用户流程映射。

输出格式

## Requirements

### Functional requirements
FR-01: The system shall ... when ... so that ...

### Non-functional requirements
NFR-01: ...

### Dependencies
- Data/API:
- Auth/permissions:
- Design system:

### Out of scope for v1
- [item]

### Assumptions
- [item]

### Open questions
- [item]

**Recommended next step:**

示例

需求

功能需求

FR-01：系统应在用户打开仪表板时显示该用户过去 30 天的活动，以便用户无需导航即可查看近期工作。 FR-02：系统应在 URL 中保留所选的日期范围筛选条件，以便视图可以分享和加入书签。

非功能需求

NFR-01：在 4G 移动网络上，仪表板的初始加载 LCP 应低于 2.5 秒。 NFR-02：所有仪表板控件都应可通过键盘访问，并满足 WCAG 2.2 AA 对比度要求。

依赖项
  • 数据/API：活动 API 已存在；速率限制尚未记录
  • 身份验证/权限：基于角色——管理员可查看所有团队
  • 设计系统：尚无
v1 范围外
  • 自定义报告生成器、CSV 定时任务、移动推送通知
假设
  • 活动数据存储在服务端，并可按日期范围查询
待解决问题
  • 超过 30 天的数据如何处理——分页还是显示摘要视图？

**建议的下一步：**为应用外壳和仪表板路由规划站点地图。

需要避免的常见错误

  • 不要将需求写成 UI 方案。“比较 20 个项目”是需求；“显示表格”是可能的方案。
  • 不要因为用户只描述了功能就跳过非功能需求。
  • 不要用含糊的措辞掩盖身份验证、权限或 API 依赖项。

适用范围

  • 如果想法仍然模糊，不要使用此技能——请先运行 $product-intent-clarifier。
  • 如果需求已存在，且待解决问题是信息架构，请使用 $sitemap-planner。
  • 不要将需求写成 UI 方案——表格是方案；比较项目才是需求。

完成前验证

  • 每项功能需求都可测试。
  • 除非显然不相关，否则至少要将无障碍性和响应式设计纳入非功能需求的考量。
  • 未知事项应明确列为假设或待解决问题。

另请参阅

评论

支持 Markdown