1. 将功能需求整理成文档，定义系统需求 第5章 系统需求建模 定义系统需求，上一章是收集信息

2. 5.1建模 • 模型是系统某一方面的体现 不同类型模型在不同细节层次上表现系统 帮助分析员澄清和改良设计 模型的作用 描述系统的复杂性 便于交流

3. 建模的原因 了解信息系统 通过抽象降低复杂性 有助于回忆前面信息 开发小组之间的交流 用户及系统相关者交流 为维护和升级提供文档

4. 模型的类型 • 数学模型 • 描述模型 • 图形模型 一系列公式来表述 描述系统部分功能的备忘录、报表或者列表，记录信息 图表和系统某些方面的示意性表示

5. Models 用于分析的模型(Figure 5-4) 分析阶段是逻辑模型（侧重于定义需求），设计阶段模型是物理模型（使用具体技术实现）

6. 设计阶段的模型 (Figure 5-5) 分析阶段是逻辑模型（侧重于定义需求），设计阶段模型是物理模型（使用具体技术实现）

7. 5.2事件、活动和用例 时间分解 • 用例：系统执行的活动，响应用户的要求。 • EBP （基本业务流程）：一个人在特定的地点为响应交易事件所执行的一项任务。它增加可度量的业务价值，是的系统和数据保持在一直状态。 • 事件：可以描述、值得记录的在某一时间和地点发生的事情

8. 事件分解 • 集中于确定系统必须做出响应的事件然后决定系统如何响应的恶意中分析技术。

9. Events Affecting a Charge Account Processing System that Lead to Use Cases (Figure 5-7)

10. 事件的类型 • 外部事件：系统之外发生的事件，通常由外部实体或动作参与者触发。 • 临时事件：由于到达某一时刻所发生的事件。 • 状态事件：当系统内部发生了需要处理的情况所引发的事件。

11. 定义事件

12. Identifying Use Cases Based on User Goals (Figure 5-6)

13. Sequence of Actions that Lead Up to Only One Event Affecting the System (Figure 5-10)

14. Sequence of “Transactions” for One Specific Customer Resulting in Many Events (Figure 5-11)

15. Events Deferred Until the Design Phase (Figure 5-12)

16. Relationships Naturally Occur Between Things (Figure 5-19)