6.1 需求分析建模的要点与误区
6.1.1 需求分析到底做什么
需求分析的任务不是分析系统如何实现用户的需要，而是对业务分析，形成一个体系完整，内容清晰的业务框架，以指导后续的设计开发工作。
需求分析就是先分解，再提炼，在这个过程中消除矛盾。
6.1.1.1 分解
现代需求工程理论更建议采用业务导向分解，而非传统的系统导向分解。
》业务流程为线索的分解结构
这种结构是以业务流程为主线索，对于联机事务处理系统，管理信息系统而言都是非常适用的方法。
》程序结构为线索的分解结构
这种分解结构过早的进入了程序结构，割裂了与问题域之间的联系，从医导致对问题研究不足的情况，从而降低需求质量，增加变更风险。这种结构适用于问题不复杂，系统与问题关联性不强的情况，例如工具软件，面向设备的系统等。
》基于场景的分解结构
对于决策支持系统，面向用户的嵌入式系统，就比较适合使用场景作为线索。这些场景向上可以总结成一系列关注点或功能域，向下可以分解成具体的决策步骤。
》基于数据的分解结构
》小结
选择了合适的分解结构之后，就可以按其线索把需求规格说明书大纲确定下来了，就知道应该捕获什么信息了，信息捕获回来之后就将其填充到大纲里，并不断验证。
6.1.1.2 提炼
分解是一种自顶向下的方法，按任何一种线索分解，都会破坏其他线索的完整性。所以还需要自底向上的方法进行提炼，抽取出共性的部分，建立针对全局的领域模型。
6.1.1.3 消除矛盾
6.1.2 建模的目标和要点
建模的过程比结果重要。
建模是需求分析的主要手段。但如果为了建模而建模，它就会变成一个问题，导致华而不实，造成沟通障碍。
6.1.2.1 建模的目的
建模的好处在于更好地理解正在开发的系统。建模的目的在于帮助我们按照需要的样式对系统进行可视化，提供一种详细说明系统的结构或行为的方法，给出一个指导系统构造的模板，对我们所做出的决策进行文档化。
6.1.2.3 建模的要点与原则
要点：设计要文档化；用可视化的模型表达架构；不要为了建模而建模，如果模型不能对系统的构建起到帮助作用，那么就是一种人力资源的浪费。
模型是用来沟通的，因此仅当需要的时候才构建模型。
6.1.3 选择建模工具的要点
6.1.3.1 正确认识建模方法论
建模的要点是根据要完成的任务，选择合适的建模工具。
6.1.3.2 正确认识UML
》UML的发展历史
》UML的准确理解
》为什么要用UML建模
》如何选择UML图
6.2 周期一：理清框架与脉络
任务：理清需求的结构框架(领域类图)，行为脉络(流程图和用例图)。
输入：需求定义阶段产生的业务时间列表和报表列表。
输出：领域模型和用例模型。
该任务对应于RUP中细化阶段的第一次迭代，该阶段的结束标志是标识除了绝大部分用例，生成了领域模型。
6.2.1 业务流程分析
每个业务事件都是流程的触发，因此针对每个事件都应该继续做流程分析。不过根据流程的复杂度作出裁剪，简单的流程可以只用文本描述，复杂的流程可以通过流程图表示。
6.2.1.1 业务流程分析任务概述
业务流程分析，具体来说就是识别，分析现有业务活动，确定活动之间的关系，了解活动需要接受哪些信息，产生哪些数据，确定数据传输路线，标识出活动是由哪些部门，岗位负责。
分析过程中，要注意抓住核心业务和主要活动点，部门之间的衔接，工作中繁琐，反复，成本高，效率低，时间长，转手多的活动。
6.2.1.2 业务流程分析与流程管理理论的关系
业务流程是对信息系统进行庖丁解牛的核心线索。
》流程的六大特性：目标性，内在性，整体性，动态性，层次性，结构性。
》工作流实现的本质
》流程设计（BPD）的原则
1 流程应该以产出为中心，而非任务为中心。
2 让需要得到流程产出的人自己执行流程。一方面现在流程设计经常引入自助的概念；第二个方面是任务应该由谁来执行可以参照这一原则。
3 将决策权放到更低的管理职位上，这样会得到更高的效率。在需求分析时，如果发现流程的决策点在较高的管理岗位上，就应该注意它经常会带来执行上的瓶颈，也就会影响系统的正常运作。
4 流程多样化。因为场景不同，同一个业务事件可能会执行不同的流程，在系统开发时，应该充分考虑到。
5 单点接触客户。这一点充分体现了流程对外部客户满意度的关注，也是未来流程变化的一个常见趋势。
》流程改进（BPR）的ESIA策略
ESIA就是清除低效环节（E），简化瓶颈点（S），整合资源（I），繁琐任务自动化（A）。
这些因素就是导致流程发生变化的主要原因。
6.2.1.3 业务流程分析的要点与产物
在进行业务流程分析时，有几个关键点：
》流程是有层次的
部门级是需求分析的主线索，岗位级是需求细节填充时的工作内容，组织级是对部门级流程的抽象概括。
》流程是有类型的
主要类型包括：
生产性流程：是流程中最重要的部分，通常也最容易标识。
管理型流程：是对生产性流程的管控，对质量效率进度等进行控制的流程，容易忽略。
支撑性流程：是对生产性流程的补充，通常是协作部门，本部门员工执行，也是容易丢失的部分。
》流程分析的产物
应该尽可能地使用模型来描述流程。最常使用的有三种：跨职责流程图，活动图和数据流图。
跨职责流程图：强调业务背景。Visio是最佳工具。
活动图：强调对软件开发的指导。Rose，Together都是最佳工具之一。
数据流图：强调数据的流通加工和处理。Visio是最佳工具。
6.2.1.4 跨职责流程图应用基础与要点
》元素
流程名称，职责带区，流程阶段，流程元素。
》绘制要点
要保障绘制出来的流程图是真实有效的，就必须要强化用户参与。
要善于，敢于抛弃细节，不要过早钻研到业务活动的具体步骤中。
要抛弃一次成型的思路，使用迭代的方式，画草搞，谈问题，改草搞，再讨论，再修正，直到达成共识。
所有职责带区上的活动都细化到具体的岗位。
每个活动之间的关系都已经没有疑问，都达成共识。
6.2.1.5 活动图应用基础与要点
活动图就是可以支持并行行为的流程图。
在完成活动图或跨职责流程图之后，还需要注意：
》进行瓶颈分析。
》进行利益分析。
当流程图绘制完成之后，花些时间进行瓶颈和利益分析，会有意想不到的收获。
6.2.1.6 数据流图应用基础
对于数据流为主线索的处理过程非常合适。
》主要元素
》分层的数据流图
6.2.2 业务实体分析
具体来说，就是要了解这个问题域中有哪些业务实体，它们之间存在什么样的逻辑关系，数量关系，以及有什么相应的结构规则。
6.2.2.1 业务实体分析任务概述
在领域建模过程中，更多地采用自底向上的方法，针对每一个业务事件或报表，分析类图片段，然后再将这些片段抽象，提炼，合并，形成全局的领域模型。
实体分析的产物有两种可选模型：类图，ER图。推荐使用类图。
6.2.2.2 类图应用基础与要点
》面向对象思想
》类的表示方法
》类之间的关系：关联，泛化，组合。
》确定类的主要职责：属性和方法。
领域模型(类图)，是自底向上合并出来的。
领域模型应该遵循：拒绝实现细节，大类不拆分，子类不合并，同类不抽象。
领域模型：以面向对象的视角看待现实世界，通过类图来描述事物之间的关系。因此主要工作是找出相关的类，以及他们之间的关系。
分析模型：分析模型是针对软件系统分析，领域模型则偏重对业务分析。分析模型主要用到实体类，控制类，边界类。
设计模型：设计模型将直接对编码予以指导。
6.2.2.3 ER图应用基础
ER图的优势在于更好地跟数据库设计结合，缺点在于语义较类图更弱一些。
》数据建模过程
6.2.3 角色与使用场景分析
用例分析技术，能更好地以用户的角度，将系统当作一个黑盒子，了解并梳理需求，解释如何使用系统(场景)。
6.2.3.1 用例分析技术概述
用例分析技术，包含两个部分：用例图，用例描述。用例图是目录，用例描述是封装所有需求的形式。
6.2.3.2 参与者与用例
参与者是一种角色，可以是人，可以是其他系统，可以是硬件设备，也可以是时钟，但一定要是在系统之外。
参与者是直接使用系统的最终用户，任何间接与系统相关的人员是StakeHolder，不是参与者。
6.2.3.3 用例图
千万不要为了使用扩展，包含关系而使用他们。扩展用例建模通常都是优先级较低的事件。面向客户的用例图通常都不应该出现包含关系，这些事情应该是在面向开发团队时才进行填充和归纳的细节。
6.2.3.4 用例的来源
如何从需求中归纳出用例呢?通常可以采用两种方法：自顶向下导出法，自底向上合并法。
》自顶向下导出法
就是从流程图中派生出用例图。而流程图是通过划分主题域，再从主题域标识业务事件，然后通过业务事件绘制出来流程图。
拿到流程图后，我们首先可以跟客户进行边界确定和角色确定，以得出表示系统边界的用例图。
1 边界确定。首先排除掉不直接使用系统的岗位。
2 确定角色。对剩下的职责带区进行角色化。
3 确定用例。用例是从职责带区中的业务活动中派生出来的。
4 绘制用例图。有了以上分析，我们得到了角色，参与者，用例，就可以绘制出用例图了。
》自底向上合并法
对于一些中小项目而言，流程并非泾渭分明，从流程开始梳理会比较困难，就适合采用自底向上合并法，从需求捕获阶段得到的需求列表着手，合并出需要的用例。
1 收集原始需求。
2 确定参与者。
3 合并用例。
4 绘制用例图。
用例的注意事项：
1 用例图的颗粒度取决于业务价值。
2 用业务动词命名用例十分重要，不要在用新增xx，修改xx，删除xx，查询xx了。
3 采用先事后人的方式分析，而非先人后事。
6.3 周期二：确定需求细节
这一阶段的任务，是对上一阶段产出的用例模型和领域模型进行细节填充。对于行为需求的用例，我们要填充事件流，包括：相关需求或功能点，界面原型，用例规则与约束。对于数据需求的领域类，我们要填充字段与格式，包括字段信息，字段格式与规则，计算规则，结构规则。
6.3.1 确定行为需求的细节
行为需求对应的是“人，事，物，接口”四大需求主线中的“事”，这也是软件功能需求的主体内容。
6.3.1.1 用例的灵活运用
行为需求可以分为四个类型：业务功能，报表功能，接口，技术支持。
6.3.1.2 用例描述模板
对于行为用例来说，需要整理的内容有事件流，相关需求或功能点，界面原型，规则或约束四个方面。
事件流分析：场景和用例的关系，类似对象与类之间的关系，一个用例是对一组类似场景的抽象。而一个用例通常是一组事件流所构成。
6.3.1.3 业务用例与系统用例
业务用例描述的是所有业务操作，系统用例则只描述与系统相关的业务步骤。要警惕将系统用例写成界面操作。
下面是机场checkin的业务用例与系统用例示范：
很明显，2，3，6，9都是跟系统无关的步骤，将他们去除后，就从业务用例得到了系统用例。
》创建业务用例的好处：避免开发层面断章取义，而使系统步骤融入到业务场景中；提供业务优化的可能性；更好设置未来的拓展点。
》事件流描述中，应该保留主语。可以使用表格或者文字的方式。
避免在用例事件流描述中出现实现细节，分支结构，循环结构。特别是不能出现多路分支结构。
6.3.1.5 界面原型
》要点：软件需求规格里的用户界面原型，是约束，建议，而非解决方案。需求分析人员也只能给用户界面设计提供依据，而非设计。
》不要忽略交互。可以采取动态原型的方式，也可以用状态图表示界面的流转。
》别让界面掩盖本质。
6.3.1.6 规则与约束
规则是在实现时应该考虑的东西，约束是对技术选择时的限制条件。
》规则的类型：业务规则，数据规则，界面规则。
业务规则：与业务逻辑相关的规则。
数据规则：数据结构层面上的规则。比如长度，类型等。
界面规则：用户界面相关的规则。比如什么颜色的数据显示不同的等级。
》规则的层次
数据与界面规则通常都是微观规则，而业务规则却通常涉及宏观微观等多种不同层次，因此在组织时需要注意其中的差别。
总之，对于规则与约束，有一个核心原则，就是“只写针对本用例的内容”。
6.3.1.7 基于stakeholder利益分析的需求挖掘
6.3.2 确定结构需求细节
如果说行为需求从用例模型中得出，结构需求就是从领域模型中得出。我们将从基本内容和常见盲区两个角度来说明结构需求的细节填充。
6.3.2.1 基本内容
》领域模型的组织
从领域模型的组织角度来说，通常会首先按照主题域进行第一次分解，一个主题域对应一个领域模型，然后根据需要将各个主题域共性的领域类抽取出来，形成全局公共领域类模型。对于每个主题域内的领域模型而言，涉及的领域类可能还是很多，就可以根据逻辑关系划分为不同的包，每个包就是一个逻辑相关的领域类图的片段。接着对每个片段进行概述。就得到以下层次：
在xx类中，我们就可以对每个领域类做进一步描述了。通常都是从“数据窗口分析”，“数据组成与格式”，“派生数据的计算方法”三个角度进行描述。
》数据窗口分析
系统中的公共数据经常成为工作交叉和冲突的地方，对于这种情况，建议采用数据窗口的方式处理，即将公共属性变成公共的，个性属性仍然压在各个模块中。
》数据组成与格式
数据组成与格式包括：数据类型，如int，char，boolean等；长度精度等信息。组成格式，如2位字母，6位数字等。
》派生数据的计算方法
领域类中，还可能涉及一些并非直接输入的属性，他们的值是通过计算得出的，例如订单的总金额等。因此我们还需要为这些属性生成规则。通常通过决策表或决策树的形式来描述他们。
6.3.2.2 常见盲区
与结构需求相关的，还有一些相关的盲区。
》数据结构的特点
对于一个领域类而言，不同的属性它们的重要性，稳定性，周期性都会影响到具体的开发决策，例如：主要字段与次要字段，稳定字段和不稳定字段，即时记录与历史记录。
》数据使用特点
》非功能要求
6.3.3 周期二的产物
完整的用例描述，完整的领域类细节，界面流转图，页面原型。
6.4 其他需求分析
其他需求包括：接口需求，全局性的非功能需求和全局性的设计约束。
6.4.1 接口需求
哪里有分解，哪里就有接口。当标识出接口之后，千万不要谈及接口的设计和实现，从需求的角度来说，接口的重点应该从使用者，内容与格式，设计约束与要求三个方面展开。
6.4.1.1 使用者
在描述接口使用者时，可以从以下角度进行说明：
》使用者名称，罗列出该接口的外部使用者。
》业务目的，说明使用者通过该接口实现什么样的业务。
》使用时机，说明使用者将在什么场景中使用该接口。
》使用频率，描述各类使用者调用该接口的频率。
6.4.1.2 内容与格式
6.4.1.3 设计约束
对接口实现时必须考虑的约束条件或设计要求，内容比较广泛，例如协议格式要求，性能要求，环境限制等。
6.4.2 非功能需求的追踪
6.4.2.1 质量特性分析
在组织非功能需求类型时，可以参考相关的质量特性标准，其中最常用的有ISO/IEC 9126软件质量模型 和 McCall软件质量模型。也可以根据自己项目的特点，关注重心来确定。接下来我们将介绍ISO/IEC 9126定义的6类21项质量属性进行简要分析。
》功能性
》可靠性
》易用性
》效率
》可维护性
》可移植性
6.5 小结
SERU方法的核心，就是从“事，物，人，接口”四个主线着手，沿着业务脉络(业务主题域-业务事件/流程-业务活动-业务步骤)进行分解，构建(构件-流程图-用例-事件流)，实现需求分析。