需求分析 基础

文章目录

• • 一、核心理念（一句话要义）
  • 二、核心四步流程（主干脉络）
  • • [补充：用户故事 是什么](#补充：用户故事 是什么)
    • • 核心结构（必须包含三要素）
      • "C"原则（判断好故事的标准
      • 经典模板（直接套用）
      • 实际案例
      • 高质量用户故事的INVEST原则
      • 避坑指南
      • 一句话记忆
  • 三、三大关键思维（要义精髓）
  • 四、实用速查表
  • 一句话口诀

在开发中等个人项目过程中，经常陷入迷茫 "接下来该做什么"，"实现效果达到什么样才算可以"，"我的目标具体是什么" 等。一番思索后，经常追溯到 对项目的核心诉求不清晰，需求不够明确具体，导致 方案设计模糊。想起之前看的 需求分析课程，在 deepseek 的帮助下 快速整理了一下 需求分析的基本逻辑，以备后用

一、核心理念（一句话要义）

"不是用户要什么就给什么，而是挖出他们真正需要解决的业务/体验问题"

二、核心四步流程（主干脉络）

1. 需求挖掘（Discover）

• 关键动作：访谈/观察/数据分析
• 核心问题："用户想达成什么目标？现在卡点在哪？"
• 产出物：用户故事、业务流程图、痛点清单

补充：用户故事 是什么

用户故事：一句话讲清
"以用户视角描述需求的标准化格式，聚焦价值而非功能细节。"

核心结构（必须包含三要素）

作为【某个角色】
我想要【执行某个操作】
以便于【获得某种价值/解决某个问题】

示例对比

• ❌ 传统需求："需要登录功能"

• ✅ 用户故事：

  作为【未注册用户】
  我想要【用手机号快速注册】
  以便于【立即购买限时优惠商品】

. 聚焦价值 ：强迫思考"为什么需要这个功能"

. 沟通桥梁 ：业务、开发、测试都能理解

. 轻量灵活：比冗长的需求文档更易迭代

"C"原则（判断好故事的标准

Card （卡片） 简洁，可写在卡片上，能否在1分钟内说清？
Conversation （对话） 引发讨论而非最终答案 是否需要和用户/团队进一步沟通？
Confirmation（确认） 有明确的验收标准 怎么算完成？如何测试？

经典模板（直接套用）

基础模板 作为【用户类型/角色】 我想要【执行某个操作/完成某个任务】 以便于【达成某个业务目标/获得价值】

扩展模板（添加更多信息）

故事：【一句话描述】 用户类型：【具体角色】 需求背景：【为什么需要】 具体描述：【用户操作流程】 验收标准：【完成标准】
  - 场景1：当...应该...
  - 场景2：如果...则... 优先级：【高/中/低】

实际案例

案例1：电商场景 作为【忙碌的上班族】 我想要【保存常用收货地址】 以便于【下次购物时一键选择，节省时间】

案例2：协作工具 作为【团队负责人】 我想要【查看项目成员的任务进度】 以便于【及时发现延误风险并协调资源】

案例3：内容平台 作为【文章作者】 我想要【定时发布文章】 以便于【在读者最活跃的时间自动发布】

---

高质量用户故事的INVEST原则

I ndependent（独立） 可独立开发/交付 ------ 是否依赖其他故事？
N egotiable（可协商） 细节可讨论 ------ 是否写得太死，没有调整空间？
V aluable（有价值） 对用户/客户有价值 ------ 用户是否愿意为此付费？
E stimable（可估算） 可评估工作量 ------ 开发能否估算时间？
S mall（小） 足够小，可迭代 ------ 能否在一个迭代内完成？
Testable（可测试） 有明确的验收标准 ------ 能否写出测试用例？

避坑指南

常见错误：

• ❌ 只有"我想要..."缺少"以便于..."（没价值）
• ❌ 描述技术实现而非用户目标（"需要API接口"）
• ❌ 一个故事包含多个价值点（应拆分为多个小故事）

修正方法：

1. 问"为什么"：直到找到用户真实目标
2. 站在用户角度：用他们的语言，非技术语言
3. 拆分成小故事：每个故事只解决一个核心问题

一句话记忆

"不是描述功能，而是讲述用户如何使用系统达成目标的小故事。"

用户故事的核心是视角的转变 ：从"系统要有什么功能"变成"用户能用系统做什么有价值的事"。它是敏捷开发中最小化的价值交付单元

2. 需求定义（Define）

• 关键动作：分类、优先级排序
• 核心方法 ：
  • Kano模型：基础型/期望型/兴奋型需求
  • MoSCoW法则：Must/Should/Could/Won't have
  • 价值-难度矩阵：优先做高价值低难度
• 产出物：优先级需求列表

3. 需求转化（Translate）

• 关键动作：将业务语言转为技术语言
• 核心产出 ：
  • 用户故事："作为[角色]，我想[做什么]，以便[达成价值]"
  • 需求规格：功能描述、验收标准、业务规则

4. 需求验证（Validate）

• 关键动作：原型测试、需求评审
• 核心问题："这个方案真能解决用户问题吗？"
• 产出物：验证报告、调整后的需求

三、三大关键思维（要义精髓）

1. 问题思维

• ❌ 错误："用户要一个按钮"
• ✅ 正确："用户需要更快完成支付，按钮是方案之一"

2. 场景思维

• 问5W：谁（Who）在什么情况（When/Where）为何（Why）如何（How）做什么（What）

3. 边界思维

• 明确：要做什么 & 不做什么
• 控制：需求蔓延（避免无休止增加功能）

四、实用速查表

遇到...	应该...	避免...
用户提具体方案	问"你想解决什么问题"	直接照搬实现
需求太多做不完	用价值-难度矩阵排序	来者不拒全做
需求频繁变更	追溯业务目标是否变化	抱怨"为什么不早说"
各方意见冲突	回归用户场景和数据验证	凭感觉决定

一句话口诀

"挖问题 → 定价值 → 转方案 → 验效果"

记住：需求分析不是记录员，是业务翻译官 + 用户代言人。你的核心价值不是传递需求，而是甄别真伪、定义价值。