业务需求 → 用户需求 → 系统需求
(为什么) (做什么) (怎么做)
| 层次 | 来源 | 示例 |
|---|
| 业务需求 | 利益相关者 | 提升用户留存率20% |
| 用户需求 | 最终用户 | 用户能快速找到所需商品 |
| 系统需求 | 开发团队 | 搜索响应时间<200ms |
| 类型 | 说明 | 示例 |
|---|
| 功能需求 | 系统应该做什么 | 用户可以创建订单 |
| 非功能需求 | 系统应该做到什么程度 | 订单创建响应时间<500ms |
非功能需求分类（FURPS+）：
| 类别 | 说明 | 示例 |
|---|
| Functionality | 功能性 | 功能完整性 |
| Usability | 可用性 | 学习曲线、操作步骤 |
| Reliability | 可靠性 | MTBF、容错能力 |
| Performance | 性能 | 响应时间、吞吐量 |
| Supportability | 可支持性 | 可维护性、可扩展性 |
| 方法 | 适用场景 | 优点 | 缺点 |
|---|
| 访谈 | 深入了解需求 | 信息丰富 | 耗时 |
| 问卷调查 | 大范围收集 | 覆盖面广 | 深度不够 |
| 观察 | 了解实际工作流 | 真实场景 | 可能影响行为 |
| 原型 | 需求不明确 | 直观反馈 | 成本较高 |
| 文档分析 | 现有系统改造 | 基于事实 | 可能过时 |
| 焦点小组 | 收集多方意见 | 多角度 | 组织难度大 |
1. 识别利益相关者
2. 确定获取策略
3. 执行获取活动
4. 整理和记录需求
5. 验证需求完整性
标准格式：
作为 [角色]，
我希望 [功能]，
以便 [业务价值]
INVEST原则：
| 原则 | 说明 |
|---|
| Independent | 故事之间尽量独立 |
| Negotiable | 故事是可协商的 |
| Valuable | 对用户或业务有价值 |
| Estimable | 可以估算工作量 |
| Small | 足够小，一个Sprint内完成 |
| Testable | 可以验证是否完成 |
| 拆分模式 | 说明 | 示例 |
|---|
| 按工作流步骤 | 拆分流程中的步骤 | 搜索→筛选→下单 |
| 按数据变体 | 拆分不同数据类型 | 国内支付→国际支付 |
| 按操作 | 拆分CRUD操作 | 创建订单→查看订单 |
| 按业务规则 | 拆分不同规则 | 普通用户→VIP用户 |
| 按界面 | 拆分不同界面 | 移动端→桌面端 |
| 元素 | 符号 | 说明 |
|---|
| 参与者 | 小人 | 与系统交互的外部实体 |
| 用例 | 椭圆 | 系统提供的功能 |
| 系统边界 | 矩形 | 系统范围 |
| 关联 | 实线 | 参与者与用例的关系 |
| 包含 | «include» | 必然执行的行为 |
| 扩展 | «extend» | 条件执行的行为 |
| 泛化 | 空心箭头 | 一般到特殊 |
用例名称: 用户登录
参与者: 注册用户
前置条件: 用户已注册
主流程:
1. 用户输入用户名和密码
2. 系统验证凭据
3. 系统创建会话
4. 系统跳转到首页
备选流程:
2a. 凭据无效: 提示错误，允许重试
2b. 账户锁定: 提示联系管理员
后置条件: 用户已登录
变更请求 → 影响分析 → 变更评审 → 批准/拒绝 → 实施 → 验证
| 步骤 | 关键活动 |
|---|
| 变更请求 | 记录变更内容和原因 |
| 影响分析 | 评估对进度、成本、质量的影响 |
| 变更评审 | CCB（变更控制委员会）决策 |
| 实施 | 修改需求和设计 |
| 验证 | 确认变更正确实施 |
需求追踪矩阵：
| 需求ID | 需求描述 | 设计文档 | 代码模块 | 测试用例 | 状态 |
|---|
| REQ-01 | 用户登录 | HLD-3.1 | auth.py | TC-01~03 | 完成 |
| REQ-02 | 密码重置 | HLD-3.2 | reset.py | TC-04~06 | 开发中 |
| 方法 | 说明 |
|---|
| 需求评审 | 同行评审需求文档 |
| 原型验证 | 用原型确认需求理解 |
| 验收测试 | 用户确认需求满足 |
| 需求基线 | 确认的需求版本冻结 |