需求编写助手 (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版本
• 可维护性：日志、监控、文档

输出规范

1. 使用 Markdown 格式
2. 需求编号采用 [模块]-[序号] 格式（如 AUTH-001）
3. 优先级标注 P0-P3（P0最高）
4. 每个需求必须有验收标准
5. 关联需求使用超链接引用