7.4.2 需求分析的基本概念
本课核心知识点整理
需求分析的对象是“问题域”
问题域指用户业务中需要被系统解决的那部分现实问题。需求分析要做的是从现实问题出发，把业务语言、用户表达和约束条件整理成系统能理解的规格。
| 问题 | 需求分析中的含义 |
|---|---|
| 要解决什么业务问题？ | 问题域识别 |
| 谁会使用系统？ | 用户和外部实体识别 |
| 系统要提供什么服务？ | 功能需求 |
| 服务要达到什么质量？ | 非功能需求 |
| 实现时受什么限制？ | 设计约束 |
功能需求、非功能需求、设计约束
| 类型 | 回答的问题 | 例子 |
|---|---|---|
| 功能需求 | 系统要做什么 | 发放工资、打卡、查询订单、生成报表 |
| 非功能需求 | 系统做得怎样 | 响应时间不超过 3 秒、支持 100 用户并发、存储容量、计算速度 |
| 设计约束 | 系统必须在什么限制下实现 | 指定数据库、指定操作系统、符合财务规则、法律法规和规章制度 |
课堂给出一个非常实用的判断：非功能/性能需求常带明显数字化特征，例如响应时间、并发数、容量、速度、精度等。
功能需求和非功能需求的辨析
| 题干 | 类型 | 理由 |
|---|---|---|
| 每月特定时间发放员工工资 | 功能需求 | 描述系统要完成的业务功能 |
| 响应时间不超过 3 秒 | 非功能需求 | 性能指标，有数字约束 |
| 允许 100 个用户同时查询工资 | 非功能需求 | 并发能力，属于性能要求 |
| 计算精度符合财务规则 | 设计约束 | 受规则制度约束 |
非功能需求不是“不重要的需求”。相反，它经常影响架构设计。高并发、高可用、安全合规这些要求，会直接改变系统设计方案。
需求要能被验证
好的需求应尽量明确、可检查。比如：
| 不佳表达 | 更好的表达 |
|---|---|
| 系统要很快 | 95% 查询请求响应时间不超过 2 秒 |
| 系统要安全 | 所有管理员操作必须记录审计日志，日志保留不少于 180 天 |
| 系统要好用 | 新用户在 5 分钟内可完成首次订单录入 |
能够被测试和验收，是需求从“愿望”变成“规格”的关键。
例题
某财务系统需求中，属于功能需求的是：
下列属于非功能需求的是：
自查要点
- 需求分析为什么要从问题域开始？
- 功能需求和非功能需求分别回答什么问题？
- 为什么响应时间、并发数通常属于非功能需求？
- 设计约束和非功能需求有什么区别？
- 为什么需求要尽量写成可验证的形式？