chendongqi 需求编写助手 (Requirements Writer)
将模糊想法转化为清晰、可执行的软件需求文档。
工作流程
1. 需求澄清
收集信息前先问清楚：
- 目标用户：谁会使用这个功能？
- 核心问题：解决什么痛点？
- 成功标准：如何判断功能完成？
- 约束条件：技术限制、时间限制、资源限制？
2. 选择输出格式
根据需求类型选择合适的格式：
| 类型 | 适用场景 | 模板 |
|---|---|---|
| 用户故事 | 敏捷开发、功能点级别 | user-story.md |
| PRD | 完整功能模块、产品规划 | prd.md |
| 技术规格 | API设计、系统架构 | tech-spec.md |
3. 编写原则
INVEST 原则（用户故事）：
- Independent：独立可交付
- Negotiable：可协商细节
- Valuable：有用户价值
- Estimable：可估算工作量
- Small：足够小（1-3天）
- Testable：可测试验证
SMART 原则（验收标准）：
- Specific：具体明确
- Measurable：可量化
- Achievable：可实现
- Relevant：相关联
- Time-bound：有时限
4. 优先级评估
使用 MoSCoW 方法：
- Must have：核心功能，没有则无法发布
- Should have：重要功能，但可延期
- Could have：锦上添花
- Won't have：本期不做
或使用 RICE 评分：
- Reach：影响用户数
- Impact：影响程度（0.25/0.5/1/2/3）
- Confidence：信心程度（0-100%）
- Effort：工作量（人周）
- 分数 = (Reach × Impact × Confidence) / Effort
快速参考
用户故事格式
作为 [用户角色]，
我想要 [功能/行为]，
以便 [获得的价值]。
验收标准：
- Given [前置条件]，When [用户行为]，Then [期望结果]
功能需求要素
FR-001: [功能名称]
- 描述：[一句话说明]
- 输入：[输入参数]
- 处理：[处理逻辑]
- 输出：[输出结果]
- 异常：[异常处理]
- 优先级：[P0/P1/P2/P3]
非功能需求检查清单
- 性能：响应时间、吞吐量、并发数
- 可用性：SLA、故障恢复时间
- 安全性：认证、授权、数据保护
- 可扩展性：负载增长、水平扩展
- 兼容性：浏览器、设备、API版本
- 可维护性：日志、监控、文档
输出规范
- 使用 Markdown 格式
- 需求编号采用
[模块]-[序号]格式（如AUTH-001） - 优先级标注 P0-P3（P0最高）
- 每个需求必须有验收标准
- 关联需求使用超链接引用