3. 需求分析与建模：功能需求与非功能需求、需求优先级排序、需求建模语言（SysML/UML）基础
好，我们进入第三章。这一章可以说是整个课程的分水岭。前面我们讲了需求获取，那是收集原材料。现在我们要做的，是把这些原材料加工成可用的产品——也就是需求模型。
我个人习惯把需求分析比作「剥洋葱」。你一层层剥开，每一层都有新的发现，有时候还会辣得你流眼泪。但剥到最后，你会看到一个清晰的核心。这个核心，就是我们要交付的系统。
3.1 功能需求与非功能需求：硬币的两面
很多刚入行的朋友容易犯一个错误：只盯着功能需求看。觉得系统能做什么才是关键。其实不然。你想想看，一个能跑但跑不快的车，你会买吗？一个能存数据但动不动就丢数据的数据库，你敢用吗？
这就是功能需求和非功能需求的关系。它们就像硬币的两面，缺一不可。
功能需求：系统「做什么」
功能需求描述的是系统对外提供的服务或行为。说白了，就是用户能用系统完成什么任务。
举个例子：
- 用户登录系统
- 系统生成月度报表
- 系统发送邮件通知
这些都是功能需求。它们通常可以用「系统应能够...」这样的句式来描述。我在项目中遇到过最典型的案例是某电商平台的需求文档，光登录功能就写了十几条——什么密码登录、短信登录、扫码登录、第三方登录...功能是够全了，但性能呢？没人提。
非功能需求：系统「做得怎么样」
非功能需求描述的是系统在运行时的质量属性或约束条件。它们不直接回答「系统做什么」，而是回答「系统做得好不好」。
常见的非功能需求包括：
- 性能：响应时间不超过2秒
- 可用性：系统全年可用率99.9%
- 安全性：用户密码必须加密存储
- 可维护性：代码模块化，便于后续扩展
- 可移植性：支持跨平台部署
重要提醒：非功能需求往往比功能需求更难定义，也更容易被忽视。但系统上线后的成败，往往取决于非功能需求是否被满足。
我记得有一次做某银行的核心系统改造，客户把所有功能需求都列得清清楚楚，唯独对性能只字未提。结果上线第一天，并发量一上来，系统直接挂了。后来我们花了整整两周做性能调优，才勉强达到可用水平。从那以后，我每次做需求分析，都会专门留出时间跟客户聊非功能需求。
3.2 需求优先级排序：别什么都想要
需求是无限的，但资源和时间是有限的。这是一个残酷的现实。你不可能把所有需求都塞进第一个版本。所以，排序就成了必修课。
我个人比较喜欢用 MoSCoW 方法。这个方法简单粗暴，但非常实用。
| 优先级 | 含义 | 说明 |
|---|---|---|
| M (Must have) | 必须有 | 没有这个功能，系统无法交付或无法运行 |
| S (Should have) | 应该有 | 很重要，但可以找到临时替代方案 |
| C (Could have) | 可以有 | 锦上添花，没有也不影响核心功能 |
| W (Won't have) | 这次不做 | 明确排除在当前版本之外 |
你可能会问：怎么判断一个需求是 Must 还是 Should？我的经验是，问三个问题：
- 没有这个功能，用户能完成核心任务吗？
- 这个功能如果延期，会造成业务损失吗？
- 这个功能是否影响其他 Must 需求的实现？
如果三个问题的答案都是「是」，那它就是 Must。否则，降级处理。
小技巧：排序的时候，别忘了把非功能需求也排进去。我曾经见过一个项目，把所有功能需求都排成了 Must，结果非功能需求全被挤到了 Won't have 里。上线后，系统慢得像蜗牛，用户骂声一片。
3.3 需求建模语言基础：SysML 与 UML
好，接下来我们聊聊建模语言。为什么要建模？因为文字描述有天然的局限性。你写一千字描述一个流程，不如画一张图来得直观。而且，图比文字更容易发现逻辑漏洞。
UML（统一建模语言）和 SysML（系统建模语言）是目前最主流的两种建模语言。UML 偏向软件系统，SysML 则是在 UML 基础上扩展，支持更复杂的系统——比如软硬件混合系统、嵌入式系统等。
UML 的核心图
UML 有 14 种图，但常用的其实就几种：
- 用例图：描述系统与外部角色之间的交互。说白了，就是谁用系统做什么。
- 类图：描述系统的静态结构。包括类、属性、方法以及类之间的关系。
- 序列图：描述对象之间的交互顺序。特别适合展示一个用例的完整流程。
- 活动图：描述业务流程或工作流。有点像流程图，但更规范。
举个例子，一个简单的登录用例，用序列图表示：
用户 -> 登录界面: 输入用户名和密码
登录界面 -> 认证服务: 提交认证请求
认证服务 -> 数据库: 查询用户信息
数据库 --> 认证服务: 返回用户信息
认证服务 --> 登录界面: 认证结果
登录界面 --> 用户: 显示登录成功/失败你看，这样一画，整个流程就清晰了。谁先谁后，谁依赖谁，一目了然。
SysML 的扩展
SysML 在 UML 的基础上增加了几个重要的图：
- 需求图：专门用来建模需求之间的关系。比如需求之间的派生、细化、验证等。
- 块定义图：类似于 UML 的类图，但更强调系统的层次结构和物理组成。
- 内部块图：描述块内部的连接和交互。
- 参数图：描述系统参数之间的约束关系。比如速度、加速度、时间之间的关系。
我记得有一次做某航天项目的需求建模，客户要求用 SysML 的需求图来管理上千条需求。刚开始我觉得有点小题大做，但真正用起来才发现，需求图能自动追踪需求之间的派生关系，还能标记哪些需求已经被验证、哪些还没验证。这比用 Excel 管理需求强太多了。
避坑指南：我曾经见过一个团队，把 UML 和 SysML 的所有图都用上了，结果模型比代码还复杂。记住，建模的目的是简化沟通，不是增加复杂度。能用一张图说清楚的事，绝不用两张。
3.4 建模的实践建议
最后，我给大家几个实践中的小建议：
- 先画草图，再画正式图。我习惯在白板上先画，跟团队讨论确认后再用工具画正式的。
- 保持图的一致性。同一个概念在不同图中要保持名称一致。否则会引发混乱。
- 不要追求完美。模型是沟通的工具，不是艺术品。够用就好。
- 版本控制。模型文件也要纳入版本管理，跟代码一样。
嗯，这一章的内容就到这里。下一章我们会深入讲解 SysML 的需求图，以及如何用它来管理复杂的需求结构。到时候我会分享一个真实的项目案例，保证让你大开眼界。