需求获取

1. 需求获取

2. 这是什么？我们如何割草？ • 首先找到功能，然后找工作对象 • 对于客户描述系统的各种行为，我们首先找到系统有什么功能，再考虑系统为什么有这些行为。

3. 需求 • 客户：我们需要这个软件，它。。。 • 开发者：。。。

4. 功能描述

5. 面临复杂问题 • 处理复杂性有三条道路 • 抽象 • 分解（技巧：拆开，然后征服它） • 架构（技巧：分层） 分解的两条路 • 面向对象，然后功能上做分解。 • 功能上的分解导致代码的不可维护。 • 根据系统的目的，各种对象是能够被找到的。

6. 什么是正确的途径？ • 从对功能的要求（用例模型）开始，进行寻找对象（对象模型）的活动。 • 需要哪些活动、哪些模型？ • 这一次将把我们带到软件生命周期。

7. 软件生命周期的定义 • 软件生命周期：支持软件系统开发的活动及其相互间的关系。 • 典型问题 • 为此软件项目选择哪些活动？ • 活动之间的依赖关系是什么？ • 怎么给活动做出时间安排？ • 活动的结果是什么？

8. 软件生命周期活动 需求获取 系统设计 对象设计 需求分析 实现 测试

9. RUP（统一）开发方法 工作流 业务建模 需求 分析与设计 实现 测试

10. 建立需求的第一步 • 系统的开发不只是对场景（应用域）拍照。 • 需要回答两个问题 • 怎么标识系统的目的？ • 关键是系统边界的定义：什么在系统里、什么在系统外？ 需求过程的两个活动 • 需求获取：以客户理解的术语描述系统的定义。（问题陈述） • 需求分析：以开者理解的术语描述系统的规范。（问题规范）

11. 需求过程的产品

12. 需求获取 • 需求获取是非常有挑战性的活动 • 需要具有不同背景的人们合作 • 具有应用域知识的用户 • 具有解决域知识（设计，实现）的开发者 • 用户与开发者之间的桥梁 • 场景：系统使用的示例 • 用例：可描述一类场景的抽象

13. 系统规范对比分析模型 • 两种模型都集中在从用户视角看的系统的需求 • 系统规范使用自然语言 • 分析模型使用形式或者半形式的记号语言（例如，UML之类的图形语言。） • 出发点是问题陈述

14. 问题陈述 • 问题陈述是客户开发的、系统所解决的问题的描述。 • 其他说法，工作陈述。 • 一个好的问题陈述描述了 • 当前情况 • 系统应当支持的功能 • 系统布署的环境 • 客户期望提交的工作产品 • 提交日期 • 接受标准

15. 问题陈述的成分 • 当前情况：待解决的问题。 • 一个或多个场景的描述。 • 需求 功能和非功能需求 约束（伪需求） 4. 项目时间表 有主要里程碑，包括与客户在截止日期交流的活动。

16. 5. 目标环境 6. 接收标准

17. 当前情况：待解决问题 • 当前情况下的问题，例如 • 玩跳棋时，响应时间太慢。 • 我要玩围棋，但是找不到在我这个水平的对手。 • 变化下的问题，例如 应用域中的变化：新功能（业务过程）引入了这个业务。 解决域中的变化：一个新技术出现了。

18. 场景 • 具体的、集中的、一个参与者使用系统时，单个特点（比如，正常使用）的非形式描述。

19. 场景：仓库着火 • 图4-6，P100

20. 如何找到场景 • 通过对话 • 你帮助客户把需求形式化。 • 客户帮助你理解需求。 • 需求在进化（逐步完善），当场景被开发时。

21. 启发式规则 • 问自己或客户如下问题 • 当系统需要运行时，它的主要任务是什么？ • 参与者将在系统中创建、保存、改变、移除、添加什么数据？ • 系统需要知道有什么外部的变化？ • 需要通知系统的参与者什么变化或事件？

22. 寻找用例 • 在场景中找用例，用例可确定所有的场景。 • 描述用例细节 • 参考者 • 入口条件 • 事件流 • 出口条件 • 异常情况 • 特别需求（非功能，约束）

23. 用例：报告紧急情况 • 图4-7，P102

24. 用例 • 系统的功能完全由用例集合决定。 • 例子，事件管理系统Friend(P98)的用例模型 现场工作人员 调度者 打开事件 报告紧急情况 分配资源

25. 形式化用例的步骤 • 命名 • 找参与者 泛化具体的名字，张三泛化为学生，约翰泛化为现场工作人员。 3. 写作事件流

26. 启发式规则 • 纵向+横向+原型 • 纵向：系统的纵向切片，即一个场景。 • 横向：系统的横向切片，即用许多场景定义系统的范围。 • 原型：讲解用的视觉模型，即界面和接口。

27. 用例写作指南 • 图4-8，P103

28. 写得不好的用例 • 图4-9，P103