需求获取与分析

🏠 “我要一个学生选课系统”——但这不够

客户说：“我要一个学生选课系统。”

这就像你去装修公司说”我要装修”——然后甩手走了。装修师傅没法开工——因为”装修”太模糊了：铺什么地板？刷什么颜色？要不要拆墙？预算多少？

同样，“学生选课系统”也远远不够。需求分析就是把这种模糊的”我想要”变成精确的、可执行的规格说明的过程。

📐 需求分析（Requirements Analysis）：确定”系统应该做什么”的过程。不是”怎么实现”，而是”到底要做什么”。

最著名的需求失败案例：丹佛国际机场的行李处理系统——需求定义不足导致系统延期 16 个月交付，超支 32 亿美元。

---

📋 需求的两种类型

① 功能需求——“系统能做什么”

描述系统应该提供的具体功能：

学生选课系统的功能需求：
✅ 学生能登录系统
✅ 学生能浏览课程列表
✅ 学生能选择课程（选课）
✅ 学生能查看已选课程
✅ 学生能退选课程
✅ 教师能发布课程信息
✅ 管理员能管理用户账号

功能需求应该是可验证的——“选课功能正常”不够精确，应该写”学生在选课开放期间可以点击’选课’按钮，系统在 1 秒内返回’选课成功’或失败原因”。

② 非功能需求——“系统有多好”

描述系统的质量属性——不关乎”做什么”，而关乎”做得怎么样”：

常见非功能需求维度：

性能：    系统能支持 5000 人同时选课，页面加载 < 2 秒
安全性：  密码必须加密存储，所有通信使用 HTTPS
可用性：  系统 99.9% 时间可用（每年停机 < 8.76 小时）
可维护性：代码必须有单元测试覆盖 > 80%
兼容性：  支持 Chrome、Firefox、Safari 最新版本

🚗 类比：买车

功能需求：能坐 5 个人、有空调、有天窗、后备箱能放两个行李箱。

非功能需求：百公里加速 < 10 秒、油耗 < 8L/100km、安全评级 5 星、质保 5 年。

功能需求决定了”这辆车能做什么”，非功能需求决定了”这辆车好不好用”。

---

🔍 需求获取方法

方法	怎么做	适用场景
访谈	和用户/客户一对一交流	探索性需求、高层目标
问卷	大规模收集意见	用户基数大、需求相对明确
观察	看用户实际怎么工作	用户”说不清自己要什么”
原型	做一个低保真 Demo 让用户试用	验证对需求的理解是否一致
文档分析	研究现有系统的文档	替换旧系统时

一个经典问题：用户根本说不清自己要什么。

“如果我问人们想要什么，他们会说’更快的马’。“——亨利·福特

需求的挑战不是”记录用户说的”，而是理解用户真正需要什么。用户说”要更快的马”——实际需要的是”更快地到达目的地”——所以汽车才是对的。

---

📝 用户故事（User Story）——敏捷中的需求表达

在敏捷开发中，需求通常写成用户故事——一种简洁的”角色-功能-价值”格式：

作为 <角色>
我希望 <功能>
以便 <价值>

示例：
作为 学生
我希望 在线退选已选的课程
以便 在课程时间冲突时可以调整选课方案

好的用户故事遵循 INVEST 原则：

字母	含义	说明
I	Independent（独立）	故事之间不互相依赖
N	Negotiable（可协商）	不必太细致，细节可以讨论
V	Valuable（有价值）	对用户有明确的价值
E	Estimable（可估算）	团队能估算工作量
S	Small（小型）	一个 Sprint 内能完成
R	Testable（可测试）	有明确的验收条件

验收条件（Acceptance Criteria）

用户故事不能只有一句话——必须有明确的验收条件才能说”做完了”：

作为 学生
我希望 用学号和密码登录系统
以便 查看我的选课信息

验收条件：
1. 输入正确的学号和密码 → 登录成功，跳转到主页
2. 输入错误的密码 → 显示"密码错误"
3. 学号不存在 → 显示"学号未注册"
4. 连续 5 次输入错误 → 账号锁定 30 分钟

---

📄 需求文档

传统项目中，需求被写成详细的需求规格说明（SRS, Software Requirements Specification）：

1. 引言
  1.1 目的
  1.2 范围
  1.3 定义
2. 总体描述
  2.1 产品视角
  2.2 用户特征
  2.3 假设和依赖
3. 具体需求
  3.1 功能需求
    3.1.1 用户登录
    3.1.2 课程浏览
    ...
  3.2 非功能需求
    3.2.1 性能需求
    3.2.2 安全需求
    ...

💡 在敏捷中，文档可以”薄”很多——用户故事卡片 + 验收条件通常就够了。但不管用什么形式，“需求对齐”这件事本身不能跳过。

---

📝 小结

概念	一句话
功能需求	系统”做什么”——功能、行为
非功能需求	系统”做得多好”——性能、安全、可用性
用户故事	”作为X，我希望Y，以便Z”——敏捷的需求表达方式
INVEST 原则	好用户故事的 6 个标准
验收条件	”怎么才算做完了”的具体标准
需求陷阱	用户说不清自己要什么——需要主动挖掘

🎯 小练习：为”图书馆借书系统”写 5 个用户故事和对应的验收条件。包括：借书、还书、查询、预约、逾期处理。

为什么先学这个？ 需求明确了，才能谈”怎么设计”——软件架构与设计模式。