5、需求工程：从 elicitation 到交付的全流程解析

需求工程：从 elicitation 到交付的全流程解析

1. 需求获取（Requirements Elicitation）

需求获取是在结构化会议中进行的，会议的目标是从专家那里提取领域知识，确定系统范围内和范围外的功能，并将这些功能记录到一个高度结构化和逻辑化的模型中。主要输出是功能级别的需求模型。在获取会议期间，重点是捕捉最重要的功能并构建模型结构，以便后续完善细节。因为模型会越来越复杂，所以整体结构至关重要，必要时可能需要重构和重新思考模型结构。提前规划需求的高层结构，从长远来看可以节省时间，因为结构不佳的模型会变得难以使用。

参与人员及职责 ：
| 头衔 | 职责 |
| ---- | ---- |
| 需求工程师 | 引出并将需求捕获到模型中 |
| 主持人 | 主持需求获取会议，确保会议的节奏和方向富有成效，同时记录问题、架构需求等 |
| 领域专家 | 代表用户视角，描述系统功能和使用细节 |
| 产品经理 | 确定范围，通常仅在确定高级功能时参与 |
| 架构师 | 代表架构团队参与需求工程活动，或者让部分需求工程团队成员同时属于架构团队 |

小贴士 ：让远程团队的负责人参与需求获取。这样可以更轻松地转移领域知识，有助于开发一个所有团队都能共享的项目上下文和语言，避免后续的混淆。

2. 需求建模（Modeling）

使用 UML 对需求进行建模。虽然对于 UML 存在不同观点，但考虑到工具支持、文本描述能力以及结构与灵活性的结合，它是一种有效的方法。将需求建模为一组分层分解的