系统全局分析，分析粒度保持在模块管理，目的是获得系统的全局认识

系统全局分析

系统全局分析，分析粒度保持在模块管理，目的是获得系统的全局认识。

第一节是从业务的角度获取需求和用例，第二节是从系统的角度获取需求和用例，我称这个粒度为一级用例，第三节和第四节是在前两节的用例基础上分析主流程和对象。

1. 业务用例

在软件项目里，业务范围和系统范围是不同的。

业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都是客观存在的。

系统范围是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集，但是一些系统功能则会超出业务范围，例如操作日志，有没有操作日志并不影响业务目标的达成，客户也不一定会提出这个要求，但从系统角度出发，操作日志会使得系统更加健壮。

——来自《大象Thinking in UML》

在引入计算机系统之前，业务也一直跑得很顺畅，因此在初始阶段，不引入系统的角度，纯粹站在业务的角度，分析业务的主流程场景，获取业务用例。

获取业务用例需要分析出业务主角和用例，业务主角即参与到业务流程中的角色，例如项目经理、产品经理等。

用例即业务主角需要在业务流程中完成的事情，这里需要注意用例的粒度。我经过思考，系统全局分析阶段，建议使用管理一类事物的粒度，例如需求管理，这个粒度仅供参考。

开始获取业务用例，以下是一段项目实施过程的场景。

某一天，领导分配给项目经理一个新项目，于是，项目经理召集产品组长、设计组长、开发组长、测试组长简单同步一下项目信息，表示要启动该项目。

会后项目经理创建一个群聊，把项目成员拉到群聊中，同步项目信息。

开工前，项目经理简单制定了计划：产品经理收集需求，产品组长评估需求的优先级，并规划成多个迭代实施，确定迭代范围后，产品组长、设计组长、开发组长、测试组长分别进行人员安排。

确定迭代的需求范围后，接下来就是需求的流转，产品经理完成需求设计，UI设计师完成UI设计，开发工程师完成编码，测试工程师完成需求测试，最后产品经理验证需求并关闭需求。

测试工程师在测试的过程中会提出bug单，交由开发工程师进行修复。项目经理对每个迭代负责，在迭代过程中，每天组织晨会，使用需求看板同步进度。

在进度方面，项目经理会查看需求报表和bug报表跟进进度，并且每周会整理项目报告向上级汇报。最后保证迭代需求全部完成，即可结束本次迭代，然后开启下一次迭代。

基于以上场景，获取业务主角和提炼一级用例，如图1。

• 项目经理是项目的启动者，由他管理项目；在项目实施中对每个迭代负责，由他管理迭代；定期在需求看板上同步进度，由他管理需求看板；定期查看报表了解迭代数据，他需要查看报表；定期整理项目报告进行汇报，他需要管理项目报告。
• 产品经理是需求的提出者，且会进行需求设计，由他管理需求。
• 设计师是需求的设计者，参与需求的UI设计工作，属于需求中的一个步骤。
• 开发工程师是需求的代码实现者，参与需求的代码编码工作；当系统出现bug的时候，他需要参与bug的修复工作。