之前的工作是确定需求范围，也就是就有世界有哪些东西；而现在的工作时确定系统范围，即新世界有哪些东西。需求范围≠系统范围。不是所有需求都要在系统中实现，也不是所有系统功能都是从需求中来。
首先分析业务用例场景，从业务用例场景中抽象出可以在计算机当中实现的单元来，业务用例场景中被描述为XX做什么、XX又做什么……XX做什么就是系统用例的来源，看做备选用例。对业务用例来说，它应当包含一个完整的业务目标；对于系统用例来说则应当包含一个完整的事件。
接下来就是判断备选用例是否应当被纳入系统的基本方法：
- 映射
映射是最简单的办法，备选用例可以不经任何修改直接被采纳为系统用例。 - 抽象
当备选用例不能被直接映射时，我们可能需要进行一些抽象，找到该备选案例在计算机中真正要做的事情。例如办理登记手续时，核对身份实际上要做的是查询机票预订信息以及身份证信息。 - 合并
当备选用例不具有独立性时，它必然是其他某个事件的组成部分。例如，打印登机牌就被合并到值机人员手续这个备选案例中。 - 拆分
有时备选案例粒度很大，是几个事件的集合，就需要进行拆分。因为系统用例至描述一次完整的计算机交互过程。 - 演绎
有时候业务用例场景中找不到备选案例，或者备选案例并不适合用计算机实现，但是我们能预见某个可能的系统用例潜伏在备选案例中，这时我们可以用演绎的方法将它找出来。
通过上面的方法找到系统用例后，接下来就是描述系统用例，方法与业务建模类似。与业务用例场景相比，在系统用例场景当中出现了计算机这样一个泳道。这个场景描述的内容实际上是一个人机交互过程，即业务员如何操作、计算机如何动作的过程。所谓系统建模，就是引入计算机系统后，业务如何通过计算机得以实现的过程。
