SE-02 需求工程
02 · 需求工程（Requirements Engineering）
📅 预计 45 分钟 | ⭐ = 核心概念 | 📌 中英术语见文末
✍️ 配套练习：课程中心「软件工程」模块在线测验
2.1 什么是需求：点菜，还是被点菜
需求是"你要什么"，不是"我能做什么"
想象你去餐厅点菜：你心里想的是"一盘宫保鸡丁"，跟服务员说出来的可能是"来点辣的下饭的"，后厨做出来的却是"麻婆豆腐"。你想的、你说的、我做的，三个版本对不上——这就是需求问题的本质。
软件需求（requirement）是指用户希望系统做什么、做到什么程度的描述。需求工程就是一套系统化方法，用来搞清楚用户真正要什么，并把它变成开发团队能照着做的文档和模型。
在需求阶段犯的错，代价是全线最高的：修改一个需求错误的成本，往往是在测试阶段发现的几十倍。所以有句行话——"需求是所有错误的源头"。
💡 记忆口诀：需求三问 = 做什么（功能）、做多好（非功能）、谁来做（干系人）。
⚠️ 常见错误
- 把需求理解为"开发自己想做什么"：需求必须来自用户/干系人，不是开发者的自嗨。
- 以为需求只在项目开头做一次：需求会演化，工程里往往需要持续澄清和变更管理。
2.2 需求分类：功能需求与非功能需求 ⭐
功能需求管"做什么"，非功能需求管"做到什么标准"
功能需求（functional requirement）描述系统必须提供的功能，也就是"输入什么、输出什么"的行为。它可以用"当……时，系统应该……"来描述：
- 系统应能根据用户名和密码登录。
- 系统应支持按课程名称模糊搜索。
- 购物车应能计算商品总价并生成订单。
非功能需求（non-functional requirement）描述系统的质量属性和约束，也就是"做成什么样算好"。常见类别 ⭐：
| 类别 | 关注点 | 例子 |
|---|---|---|
| 性能 | 快不快、能扛多少 | 页面响应时间 < 2 秒；支持 1 万并发 |
| 可用性 | 好不好用、易上手 | 新用户无需培训即可完成下单 |
| 可靠性 | 稳不稳、不丢数据 | 系统全年可用率 ≥ 99.9% |
| 安全性 | 数据是否保密、权限是否可控 | 密码加密存储；越权访问被拒绝 |
| 可维护性 | 改起来是否容易 | 模块解耦，修改一处不牵连全局 |
| 可移植性 | 能不能换环境跑 | 支持 Windows 与 Linux 部署 |
两者的关键区别：功能需求回答"能不能做"，非功能需求回答"做到什么程度"。
现实中的高频误区：把"响应要快"当功能需求、把"能登录"当非功能需求。判据很简单——能不能用"是/否"直接测试这个行为，能测行为的是功能需求，测标准/约束的是非功能需求。
⚠️ 常见错误
- 漏掉非功能需求：只写"系统能搜索"，不写"3 秒内出结果"，做出来的系统没人愿意用。
- 功能/非功能分类判断错误：记牢判据——功能 = 行为动作（做什么），非功能 = 质量标准与约束（多好）。
2.3 需求获取：怎么把"说不清"变成"说清"
用户往往说不清自己要什么，需要方法去"撬"出来
需求获取（elicitation）是需求工程的第一道工序。用户常说"我就要一个简单的系统"，但"简单"的定义千差万别。常用方法 ⭐：
| 方法 | 做法 | 适用/特点 |
|---|---|---|
| 访谈 | 一对一/一对多，提开放问题 | 最直接，但可能只听得到少数人意见 |
| 问卷调查 | 设计问卷批量收集 | 覆盖面广，适合用户多、需求大同小异 |
| 观察/见习 | 到现场看用户怎么干活 | 能发现用户"说不出来"的真实流程 |
| 原型法 | 先做个可点击的草稿给用户试 | 让用户"看到"再提意见，需求更容易清晰 |
| 头脑风暴 | 相关方一起发散讨论 | 收集创意，但需收敛环节 |
| 文档分析 | 研究现有系统、报表、制度 | 适合已有系统需要升级改造 |
有效访谈的要点：多问"为什么"挖掘动机；不预设答案；区分"用户想要的"和"用户实际需要的"。
⚠️ 常见错误
- 只听一个"负责人"的意见：不同角色（管理员、普通用户、财务）需求会冲突，只问一个人是需求埋雷。
- 把原型当成品：原型只是沟通工具，用户看着原型点头不等于需求冻结，边界场景要追问清楚。
2.4 需求分析：把需求"理清楚、定下来"
从零散需求到规范文档
需求分析（analysis）是对获取到的原始需求进行分类、建模、排优先级、消除冲突的过程。它的核心产出是软件需求规格说明书（SRS, Software Requirements Specification）。
需求分析的主要任务 ⭐：
- 建模：用用例图、类图、状态图等模型把需求表达清楚（见 2.5）。
- 排优先级：区分"必须有"、"可以有"、"可推迟"，保证关键功能先行。
- 发现并解决冲突：不同干系人的需求互相矛盾时，要协商出折中方案。
- 可行性检查：技术、经济、进度上能否实现。
需求验证（validation）是分析阶段的"质检"：对照 SRS 逐条检查——需求是否完整、一致、无歧义、可测试、可追踪。一条需求必须能被测试验证，否则它就是模糊的。
一份好的 SRS 应该是测试的输入：测试人员拿到 SRS，就能设计出验证每条需求的测试用例。这也是"需求可追踪性"的意义——从需求到设计、到代码、到测试用例，全程能追溯到源头。
排优先级的具体方法：MoSCoW
需求一多就要排队。实践中常用 MoSCoW 法则给每条需求打标签：
| 标签 | 含义 | 例子 |
|---|---|---|
| Must have | 必须要有，没有就不能上线 | 登录、基本增删改查 |
| Should have | 应该要有，条件允许就做 | 批量导入、高级筛选 |
| Could have | 可以有，锦上添花 | 主题换肤、数据导出 |
| Won't have | 本轮不做，明确排除 | 移动端 App、多语言 |
明确"不做"也很重要：把 W 级别的需求写清楚，能防止项目范围（scope）无限膨胀——这正是范围蔓延（scope creep）的源头之一。
⚠️ 常见错误
- 需求写得太模糊："系统要友好"无法测试，必须量化成"3 步内完成注册"。
- 忽略冲突与优先级：所有需求都标"紧急"，等于没有优先级，开发无从下手。
- 不做需求验证就进设计：SRS 没评审就开工，等于带着没校准的图纸盖楼。
2.5 用例图建模：用"故事"描述系统 ⭐
用例图 = 一幅"谁，用系统干什么"的剧情图
UML 用例图（use case diagram）是描述系统功能的经典视图。它把需求讲成一个个"用户故事"：谁（参与者）为了达到什么目的，和系统发生怎样的交互。比干巴巴的功能列表直观得多。
用例图的三大组成元素 ⭐：
| 元素 | 画法 | 含义 | 例子 |
|---|---|---|---|
| 参与者 Actor | 小人图标 | 与系统交互的外部角色（人或系统） | 学生、教师、管理员、支付系统 |
| 用例 Use Case | 椭圆 | 一个完整的系统功能 | "提交作业"、"发布成绩" |
| 关系 | 实线/箭头 | 参与者与用例之间、用例之间的关联 | 学生——提交作业 |
两类关键关系：
- 关联（association）：参与者与用例之间用实线连接，表示"这个角色能发起这个功能"。
- 用例间关系：
include（包含，虚线箭头带<<include>>）表示公共步骤被复用，如"下单"包含"登录校验"；extend（扩展，虚线箭头带<<extend>>）表示可选的补充流程，如"正常下单"扩展出"优惠券核销"；泛化（generalization）表示父子用例/参与者继承关系。
怎么画用例图：先找参与者 → 再找每个参与者的目标功能 → 判断功能间的包含/扩展关系 → 连线。一张好的用例图，是把系统边界外的人/系统与边界内的功能画清楚。
用例也需要文字描述：光有椭圆不够，每个用例通常配一段"用例描述"，写清楚前置条件、主流程、异常分支、后置条件。以"提交作业"为例：
用例：提交作业
参与者：学生
前置条件：学生已登录，且课程处于作业开放期内
主流程：
1. 学生选择课程下的作业
2. 系统显示作业要求与截止时间
3. 学生上传文件并点击提交
4. 系统校验文件格式与大小，保存并提示成功
异常分支：3a. 文件格式不支持 → 系统提示错误并要求重新选择
后置条件：作业记录已入库，学生可查看提交状态
这种"带流程的用例描述"是需求分析的常用产出，也是后续设计交互流程的依据。
注意：用例图描述"做什么"，不描述"怎么做"——不要在里面画流程图、时序细节，那是设计阶段的活。
⚠️ 常见错误
- 把非功能需求画进用例图："系统响应快"不是用例，用例必须是可交互的功能行为。
- 混淆 include 与 extend：include 是"每次都会执行的公共步骤"（必须包含），extend 是"可选触发的补充流程"（条件扩展）。记法：include = 必有公共步骤，extend = 可选增强。
- 把内部处理画成参与者：参与者一定在系统外部，数据库、内部模块不是参与者。
📌 双语术语表（本讲）
| 中文 | English | 记忆点 |
|---|---|---|
| 需求 | requirement | 用户要什么 |
| 需求工程 | requirements engineering | 获取→分析→验证 |
| 功能需求 | functional requirement | 系统做什么 |
| 非功能需求 | non-functional requirement | 做到什么标准 |
| 需求获取 | elicitation | 访谈/问卷/原型 |
| 需求分析 | requirements analysis | 建模+排优先级 |
| 软件需求规格说明书 | SRS | 需求的正式文档 |
| 需求验证 | requirements validation | 检查一致性/可测试性 |
| 参与者 | actor | 外部角色，小人图标 |
| 用例 | use case | 椭圆，一个完整功能 |
| 包含关系 | include | 公共步骤必含 |
| 扩展关系 | extend | 可选补充流程 |
| 用例图 | use case diagram | 谁+做什么 |
⭐ 本讲考点清单
- 需求错误的修改成本最高，是"错误的源头"。
- 功能需求 vs 非功能需求：功能 = 行为动作（做什么），非功能 = 质量与约束（做多好）；非功能含性能/可用性/可靠性/安全/可维护/可移植。
- 需求获取常用方法：访谈、问卷、观察、原型法、头脑风暴、文档分析。
- 需求分析任务：建模、排优先级、解决冲突、可行性检查；产出 SRS。
- 需求必须可测试、可追踪——SRS 是测试用例的输入。
- 用例图三要素：参与者、用例、关系；include 必有公共步骤、extend 可选补充、泛化是继承。
- 用例图描述"做什么"，不描述"怎么做"。