管理信息系统案例分析_7.软件需求最佳实践笔记 | 需求分析与建模（一）

一、需求分析与建模的要点与误区

• 需求分析到底做什么

需求分析的任务并不是分析系统如何实现用户的需要，这是对需求分析最常见的误解。需求分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起米，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。需求分析就是先分解，再提炼，在这个过程中消除矛盾。

①分解

分解是人类控制复杂性，认知复杂事物的最佳实践，不管是采用结构化分析方法还是面向对象分析方法，分解是必然的手段。现代需求工程理论更建议采用业务导向的分解，而非传统的系统导向的分解。

以业务流程为主线索的分解结构

就是按“事”的角度进行分解。它对于联机事务处理系统、管理信息系统而言都是非常适用的方法。目标系统->主题域的分解依据的是“目标决定范围”，从主题域->业务事件、报表类型所做的是理清脉络，从业务事件->业务活动、报表类型->报表所做的是填充细节。

程序结构为主线索的分解结构

这种分解结构在需求分析过程中最常用的，但它过早进入了程序结构，割裂了与问题域之间的联系，容易导致对问题域研究的不足，降低了需求的质量。这种方法适用于问题域不复杂，或者系统与问题域关联性不强的情况下，例如工具软件、面向设备的嵌入式系统等。

②提炼

分解会破坏其他线索的完整性。如果以“事”为线索，会发现数据需求分解后就会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。因此，需要采用自底向上的方法进行提炼。如将每个业务事件中的类进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型。

注：领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。

③消除矛盾

在这样的分析过程中，会发现有些需求是相互矛盾、相互冲突的。由于是把收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面。这样，就可以很快地找到相应的人员，通过进一步的需求捕获来消除矛盾。

• 建模的目标与要点

①建模的目的

模型有效地帮助人们更好地认识、应用、设计复杂事物。建模是需求分析的主要手段，它通过简化、强调来帮助需求分析人员理清思路，达成共识。因此，需求建模的过程远比建模的结果更重要。主要目的是提供一种详细说明系统结构或行为的方法。

注：原先，由于计算机应用还不普及，软件系统的规模和复杂度都相对较小，应用“数据结构+算法=程序”的模式就可以解决大部分问题。随着计算机应用的不断普及，业务模式、数据量都在迅速变化之中，软件涉及的问题也越来越广，早已经超出人们可以处理的复杂度。

②正确认识建模方法论

建模方法论的时代背景与要点

结构化分析与设计方法和结构化分解是两个概念，不过结构化分析与设计方法充分应用了结构化分解的理念。结构化分解实际上是人类认识复杂事物的最佳实践，在很多领域都有应用，如生物分类、项目管理中的工作任务分解结构、公司管理（组织结构分解）等。

③正确认识UML

UML是一种统一的、标准化的建模语言，不是方法论。它能为参与软件设计和开发的人提供一种公共“语言”，使他们能够基于共同的“模型”来理解业务、需求，理解软件和架构如何构造。

UML的各种图见下表:

在需求阶段使用的UML图：

下面正式进入需求分析与建模部分。

二、周期一：理清框架与脉络

本阶段的任务是理清需求的结构框架（领域类图）和行为脉络（流程图和用例图），该工作的输入是需求定义阶段产生的业务事件列表和报表列表，输出的是领域模型和用例模型。该阶段的结束标志是标识出了绝大部分的用例，生成了领域模型。

在整个过程中对每个业务事件做业务流程分析、业务实体分析和用例分析；针对报表进行业务实体分析和用例分析。

1、业务流程分析

针对每一个业务事件，分析并识别现有业务活动，确定业务活动之间的关系；了解这些业务活动需要接收哪些信息，将产生哪些信息，确定信息传送的路线；同时标识出业务活动的部门、岗位等信息。

业务流程分析的三个关键点：一是理解流程的层次性；二是了解流程的类型；三是掌握业务事件识别、寻找流程的技巧。

流程是有层次的：

流程有组织级、部门级、岗位级三个层次，其中部门级是需求分析的主线索，岗位级是需求细节填充时的工作内容，组织级是对部门级流程的抽象概括。

流程是有类型的：

注：拿软件开发过程来说，需求分析、软件设计、软件编码、软件测试都是生产性流程；项目管理、质量保证就属于管理性流程了；支持性流程包括配置、文档控制等。

流程分析的产物：

在软件开发过程中，最常使用的模型有三种：跨职责流程图、活动图和数据流图。

①跨职责流程图

跨职责流程图主要由流程名称、职责带区、流程阶段、业务活动、判断/审批等组成。

下面是一个示例：

跨职责流程图完成的标准：一是所有的职责带区上的命名都将细化到具体的岗位；二是每类活动之间的关系已经没有疑问。还有一点是需要特别注意的是不应该对业务活动进行细化。

②活动图

下图是一个常见的活动图：

常规活动图

带泳道的活动图：

每个活动节点、分支是必须只属于一个泳道，而转换、分岔与汇合是可以跨泳道的。通过泳道，我们不仅体现了整个活动控制流，还体现出了每个活动的实施者。

带对象流的活动图：

通过带对象流的活动图表示数据、文档的流转，可以修改对象的状态，还可以显示对象的角色、状态和属性值的变化。

复杂的活动图—辅助活动图：

如果一个活动图过于复杂，或者活动图中某一组活动与主控制流关联不大，那么就可以借助辅助活动图来描述它。