1.3概念分析
我们已经捕获了需求，然而这些需求还处在“原料”阶段。捕获需求后可以直向后扔给设计人员。但是信息在传递的时候难免发生失真。设计人员可能误解甚至丢失需求中的重要信息，导致设计重心偏差。
一种好的方法是将需求向后传递的过程之前进行一些需求分析工作。这些工作又需求人员和设计负责系统设计或者架构设计的人员一起来完成。在进行需求分析可能要完成的工作包括建立概念模型、建立业务架构和开发系统原型。
1.3.1 建立概念模型
1.3.1.1 定义
概念用例模型位于先启阶段，有时也在精化阶段，是业务用例建模的一个子集。在实际工作中，尤其系统规模较大时，业务用例的粒度也相应的较大，通常一个业务用例所鞥描述的业务和粗略。二系统用例由于必须适应软件开发的需要，其粒度需要较小。从粗粒度到很细的粒度显然比较困难。而如果视图缩小业务用例粒度，则有会导致业务用例数据激增。
这时，我们可以采用一种方法来“分解”那些较大的业务用例，从总找到关键和核心的工作单元，针对这些工作单元建立模型来简化业务。这中“分解”行动所产生的结果就是概念用例。用例是“原子”性的，所以“分解”其实是抽象出概念用例通过包含、泛华、扩展关系连接到基本业务用例。
概念用例的选择条件：关键业务用例，核心业务用例或者是粒度比较粗的业务用例。
注意点：概念模型是针对需求中的关键业务，或者说是业务核心来建立的，所以前提是需求人员已经把握了需求，并能从复杂的需求中找出支撑起整个业务的那条主线。并且，概念模型贵于精准而非全面。
概念用例模型
1.3.1.2 获取概念用例
在业务用例中我们分析出了好多的业务用例，全部扔过来，是否无从下手？但是，需求人员应该告诉你：尽管这么多的业务用例，但是，仓储管理最核心的业务是管理指令，根据指令配货，发货、送货和收货收取费用。这是仓储的业务主线，这是我们可以根据业务主线分析，挑选出一些关键业务用例：
关键业务用例
上述挑选出来的业务用例就是我们接下来要进行分析的输入。
1.3.1.3 分析概念用例
当概念用例被确定出来后，接下来就是对概念用例进行分析。分析过程与业务用例的建模过程别无二致，仍然是绘制概念用例的场景图（活动图，时序图），然后从中找到关键的对象，最后为这些关键对象绘制一些协作图说明这些对象之间的关系和交互场景。
此时我们的视角需要从系统给的角度或者说抽象的角度来分析概念用例模型，因为我呢的目的是要搭起从业务到系统的桥梁。
1.3.1.4 概念用例场景
在分析概念用例的时候，我们得到业务用例–下达入库指令是由：生成入库指令、月台预约、月台收货、拆零质检和上架构成的。我们可以对这些小用例绘制场景图。每个都需要绘制场景图。例如：生成入库指令。
生成入库指令场景