需求建模与分析篇
需求分析基本遵循三个方向，依次是：流程，对象以及关系，用例（操作容器）；
流程对应的是跨职能流程图以及活动图，对于活动图，实在是没有感到有什么优势可言；但是对于流程图究竟要细化到什么程度？只要是不影响泳道的变更就可以作为一个节点处理，这个还有待考证；
对象以及关系，作者首先推荐的是类图，但是对于类图其实使用在设计阶段，作为需求分析阶段拿了一张类图给客户看，给客户讲解你所识别出来的类？如果是给架构师以及开发团队来看还是有点意义，但是对于国内项目很多时候时间很紧急，你搞出这一套花活是在玩儿吗？
用例，则是通过用例图来进行得，用例图首先通过框线"限定了"系统的范围，系统就是定义这些操作；其次用例图将角色和操作联系了起来（谁将会做什么事），这一点关系是在流程（流程图的粒度比较粗，不影响泳道的节点会被合并为一个节点）以及对象关系中无法体现出来的。用例图中的扩展（extend）意思是该"子流程"是可选的；包含（include）意思是对某一个用例的一部分抽出来作为一个"用例片"之所以要这样做是为了描述多个用例共享一个用例片，注意，extend以及include的内容都不是用例；都是从属于用例，用来对用例进行补充和说明的。在用例图中国，每一个椭圆都是一个用例（而不是一个操作）。用例的角色也有继承的价值，可以避免线条的重叠，继承者同时也继承了和用例的关系。
用例完成后，周期一的内容就结束了，周期一的职责就是在宏观上面把握需求，接下来就是周期二，周期二的职责及时来系统周期一的成果物；
细化，就需要使用原型来进行落地，有一点作者强调：就是原型的本质是解释需求内容。
数据窗口：对于数据的所属进行划分，字段属于库存类，发货类…共同类；这样可以保证在未来需求变更进行修改的时候能够考虑影响范围；我想到的，是不是把每一个字段都应用在那些业务中进行描述跟踪（比如在数据库设计文档中的"备注"一列进行说明）；
数据字典：对于数据类型以及内容（规则）进行描述；
决策树：决策树是形式，对于多分支的需求逻辑，使用决策树可以更加清晰、形象地描述；
事件流的分析，这个基本和中广核的早期的需求文档是一致的，包括基本的事件流（前置条件，后置条件，注意前置和后置两者可验证的，而且，并不是总有的），备选事件流（用例图中的"extend"部分），异常处理。
接口，描述清楚"使用者"，"内容格式"，"约束"。
书看到这里我一直在想一个问题：需求分析的本质是什么？工具的纷繁很容易让人陷入"需求模式"，需求分析过程的本质就是获知需求，并且和客户进行确认，进行需求重构；一切的工具的目标都是如此；这里强调一下需求重构，一个需求分析人员最大的价值在于梳理需求，并且进行重构改善，能够利用工具将需求间关系、缺陷、漏洞发现，并进行改善重组。