7.4.3 需求的分类
本课核心知识点整理
第一种分类：按抽象层次分
需求可以按“从业务目标到系统实现”的层次来分：
| 类型 | 视角 | 含义 | 例子 |
|---|---|---|---|
| 业务需求 | 组织/业务全局 | 为什么要做这个系统，解决什么业务目标 | 降低人工处理成本，提高财务处理效率 |
| 用户需求 | 用户视角 | 用户希望用系统完成什么任务 | 财务人员希望快速查询工资发放记录 |
| 系统需求 | 系统视角 | 系统必须提供哪些功能、性能和约束 | 系统应支持工资发放、工资查询、权限控制 |
用户需求可能冲突。不同用户角色站在不同利益和工作流程上提出要求，需求分析要把这些冲突分析综合，形成最终可实现的系统需求。
系统需求再细分
| 系统需求类型 | 含义 | 关键词 |
|---|---|---|
| 功能需求 | 系统必须完成的功能 | 查询、录入、审批、统计、发放 |
| 非功能需求 | 系统质量和性能要求 | 响应时间、并发、容量、可靠性、安全性 |
| 设计约束 | 开发和运行必须遵守的限制 | 操作系统、数据库、法规、规章制度、行业规则 |
软件设计师考试更常考这一层，尤其是功能需求与性能/非功能需求的区别。
第二种分类：按用户满意度分
课堂还提到另一种分类：基本需求、期望需求、兴奋需求。
| 类型 | 是否明说 | 是否应该做 | 解释 |
|---|---|---|---|
| 基本需求 | 明确提出 | 必须做 | 用户明示的常规要求 |
| 期望需求 | 可能没明说 | 应该做 | 用户默认你会提供的合理能力 |
| 兴奋需求 | 用户未要求 | 通常不应额外做 | 超出范围，可能增加成本和进度风险 |
例如做数据登记系统，用户可能没明确说“要报表”，但这通常是期望需求；而开发团队擅自做大量炫酷但无业务价值的功能，就可能变成兴奋需求带来的范围膨胀。
为什么“兴奋需求”不要随便做
兴奋需求听起来是“惊喜”，但项目管理上要谨慎：
| 风险 | 说明 |
|---|---|
| 增加成本 | 多做功能会消耗开发、测试和维护资源 |
| 延误进度 | 非必要功能可能挤占核心需求时间 |
| 引入缺陷 | 每个新功能都可能带来新 bug |
| 用户未必买单 | 用户不会因为你私自多做功能就一定提高付款 |
所以需求分析要控制范围，而不是无限满足想象中的需求。
例题
“通过建设系统降低人工处理成本”属于：
“系统应支持工资查询、工资发放和权限控制”属于：
用户没有明说，但按业务常识应该提供的合理能力，更接近：
自查要点
- 业务需求、用户需求、系统需求各站在哪个视角？
- 为什么用户需求可能存在冲突？
- 系统需求可以细分为哪三类？
- 基本需求和期望需求的区别是什么？
- 为什么兴奋需求不应随意加入范围？