首页  思维导图  详情

SERU-需求分析与建模

2021-04-26 14:57:38   40  举报





AI智能生成

需求分析是需求工程中最为核心的工作，而需求建模则是需求分析的主要手段

模板活动合辑

需求分析

需求建模

读书笔记

学习笔记

作者其他创作

大纲/内容

三、需求分析与建模

很多需求分析师直接跳过分析，将需求捕获的结果整理到软件需求规格说明书中

需求分析是需求过程中最为核心的工作，需求建模是需求分析的主要手段

需求分析到底做什么？

误区

需求分析是分析系统应该实现用户的需要

正确理解

需求分析本质上是业务分析，也就是选择一种业务导向的线索将零散的需求串联起来，形成一个体系完整、内容清晰的框架，以便指导后续的设计、开发工作

需求分析的任务

分解

分解是一种自上向下、按照一种线索分解的过程

分解结构

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

适用于OLTP联机事务处理系统、MIS管理信息系统（SERU结构）

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

适用于问题域不复杂或系统与问题域关联性不强的情况，比如：工具软件

基于场景的分解结构

适用于决策支持系统、面向用户的嵌入式系统

基于数据的分解结构

适用于数据仓库之类的数据类项目

提炼

提炼是一种自下而上的方法，用于对分解后相互交叠的类或对象进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型

消除矛盾

在分解与提炼的过程中，就会发现有些需求是相互矛盾、相互冲突的

需求建模到底如何做？

定义

需求建模是需求分析的主要手段，通过简化、强调来帮助需求分析人员理清思路，达成共识，更好的理解正在开发的系统

目的

帮助需求分析师按照实际情况或者按照需要的样式进行可视化，提供一种详细说明系统结果或行为的方法

给出一个指导系统构造的模板

对需求分析师所做出的的决策进行文档化

要点

根据要完成的任务选择合适的建模工具

UML建模

Unified Modeling Language理解

UML是一种语言，是一种表示方法，并不是一种方法论

UML是建模语言，不仅仅包含软件建模，也可以进行业务建模、流程建模等多种应用领域

UML是统一的、标准化的建模语言，是社会企业认可的

为什么使用UML？

是一种统一的、标准的且不局限于某一种应用领域的建模语言，应用面广泛且为参与软件设计和开发的人员提供了一种公共语言

如何选择UML图

活动图

说明业务流程，以及业务流程活动的步骤，关注“事”

类图

说明业务实体之间关系，体现结构规则，关注“物”

用例图

说明角色与使用场景之间的关系，关注“人”

构件图

说明主题域划分以及他们之间的服务接口，关注“接口”

部署图

描述系统的部署环境，体现设计约束，关注“设计约束”

需求分析周期一：理清框架和脉络

任务

理清需求的结构框架（领域类图）和行为脉络（流程图、用例图）

输入

需求定义阶段产生的业务事件列表和报表列表

针对每个业务事件进行业务流程分析（事）、业务实体分析（物）和用例分析（人）

针对每类报表进行业务实体分析（物）和用例分析（人）

输出

流程图、类图、用例模型

结束标志

标识出绝大部分的用例，生成了领域模型

方法

业务流程分析

业务事件是业务流程的触发，沿着对业务事件的响应序列，找到所有相关的业务活动级业务活动之间的关系

信息的主要来源是负责该业务的中层管理人员

针对每一个业务事件，了解业务活动需要接收那些信息，将产生哪些数据（表单），确定数据传送的路线；
标识出业务活动的具体执行角色或岗位

分析过程中，注意抓核心业务与主要活动点、部门内及部门间的衔接；
工作中烦琐及反复的环节；
成本高、效率低、时间长及转手次数较多的环节

如何设计一个好的流程？

流程的6大特性

目标性

流程是针对要达到的目标而设计的。流程是一个整体，或许对一个局部来说是低效的，但目标hi整个流程的高效

内在性

流程本身就是一个高内聚的整体，是一个很好的分离业务耦合点的线索

整体性

流程通常是由多个业务活动组成的，分析的要点在于理清业务活动之间的关系

动态性

流程是行为流，不是一个静态的快照，而是一个顺序的行为流

层次性

组成流程的活动本身也可以是一个流程，要点在于理清流程的层次，通过逐层嵌套的形式理清脉络

结构性

流程之间的关系包括串联、并联和反馈三种

流程设计的原则

流程应该以产出为中心，而非任务为中心：流程是否合理，关键是从整体上评价，仅对一个业务活动进行分析是片面的

让那些需要得到产出的人自己执行流程：关键流程产出的人能够更自动自发的执行工作流

消除瓶颈：将决策权尽量下放到更低的管理职位上，会得到更高的效率

单点接触客户：提升用户体验，将“多窗口、多点接触用户”的现象转成“单点接触用户”的模式

要点与产物

要点

理解流程的层次性

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

了解流程的类型

流程有生产性流程、管理性流程与支撑性流程三种类型：
生产性流程是最重要的部分，是企业/组织价值体现的核心，最容易被识别；
管理性流程是由管理层发现的、对一些质量、效率进行监督的控制性流程，是容易忽略的部分；
支撑性流程是对生产性流程的一种补充，通常是部门间协作、本部门员工执行的工作，是最容易丢失的部分

掌握以业务事件识别、寻找流程的技巧

产物

跨职责流程图

当产物需要在企业管理中复用，或者参与的人员有更强的业务背景时，比较适合，是商业建模的标准工具

对开发的语义支持不足

要点（应该有的意识）

应尽可能的在访谈的过程中及时绘制出流程图并及时进行验证

要善于、敢于抛弃细节，不要过早地钻研到业务活动的具体活动中去

抛弃一次性成型的思路，不要精雕细琢，而是出草稿、谈问题、修正草稿、再讨论、再修正.....最终达成共识的过程

在流程绘制完成后，要花些时间去进行瓶颈分析与利益分析

活动图

强调图对软件开发的指导，且非技术背景的用户也能够比较好的理解

要点

在绘制活动图时，只需要将关注的、需要描述的对象进行描述即可，不需要将所有的对象流都罗列出来

数据流图 DFD

DFD是结构化分析与设计方法推荐的一种图，强调数据的流转、加工和处理，适用于数据流比行为流更强的领域

无法有效的表示出每类加工的执行者

绘制思路

通过业务事件完成从顶层图到0层图的分解

再通过将业务事件分解成业务活动实现0层图到1层图的细化

然后通过将业务活动分解为业务步骤实现1层图到2层图的分解

绘制步骤

标识出外部实体（通常是系统的直接用户）

标识出每个业务实体可能主动发起的业务事件，形成业务事件列表

分析针对每个业务事件，系统会做出的响应动作（一个业务事件可能引起多个系统响应动作）

逐一建立外部实体与系统响应动作（用过程符号表示）、数据文件的关系，生成DFD片段

将DFD片段进行整合，进行比较、合并，得到DFD 0层图

如有必要，对0层图中包含的系统响应动作继续逐步细化，分解到底，得到1层图

注意点

在DFD绘制时，要注意一个系统动作完成后，是否有后续响应、数据流的目的地是哪，因为这可能会引发另外一个系统动作

原则：父图与子图之间应保持“平衡关系”，通俗来说就是生层图与下层图应该有同样多的输入数据流与输出数据流

业务实体分析

思路

更多的应该采用“自下向上”的方法，针对每一个业务事件、每一类报表创建局部的领域类图片段，当完成这些建模工作后，再对其进行抽象、提炼，形成全局的领域模型

步骤

识别出业务实体

确定业务实体之间的逻辑关系、数量关系

定义业务实体的属性

产物

类图

定义

面向对象分析与设计方法引入的，是UML规范的一部分，在语义上要比E-R模型更强，更适合领域建模

主要元素

类

先看清有哪些类

关系

分析类之间存在的关系

多重性

分析两个类之间的数量关系

两个类之间出现多对多的关系时，一般需要用“关联类”，将不容易归类的属性归类到关联类中

部分业务规则约束

技巧

无论是读图还是画图，都从最复杂的类开始或者将最复杂的类放在图的中间

领域模型都是自底向上合并出来的，具体来说就是先绘制出领域类（业务事件）的片段，然后再抽象、提炼、汇聚成全局领域模型

常见建模误区

领域类和关系型数据库表之间建立一对一的映射：领域建模的视图是“需求视图”，数据库表是“DBA视图”，它们的关注点是不同的，领域建模是数据库表设计的基础，但不应过早地进行映射

过早的将子类合并：比如客户分为个人客户和公司客户，会过早将个人客户和公司客户合并为客户的一个属性：客户类型，这样对建模来说是不正确的
一：没有有效地将客户包括哪些类型传达给开发团队；
二是过早地决定可能会产生问题，例如个人客户信息和公司客户信息很可能是不同的

将相对比较大的类进行分拆，例如将客户类分拆为：客户基本信息、客户联系信息……等，会阻碍与客户的交流与验证

立即给关联指定多重性，确保每个关联都具有明确的数量关系

对名词和动词过度的分析，而背离初衷（过度使用名词动词法）

不对用例和时序图进行分析研究，就将操作分配给类：类图不体现“行为需求”，应该是在流程图、用例描述中体现的

对象和类的通用程度越高，在其他项目中重用它们的可能性就越大

对于每个“整体/部分”关系，就使用聚合还是组合表示而争论不休

未对问题空间进行建模之前，就假定一种具体的实现策略或思考技术实现

将类命名为难以理解的名称，而不是直观的名称

什么是类？

定义

类是一组具有相同属性、操作、关系和语义的对象的描述，关键的特性是属性（成员变量）和操作（成员方法）

类之间的关系

关联

表示两个类之间采用存在某种语义上的联系，关联关系提供了通信的路径，是最通用的，语义最弱的

表示方法：实线

泛化

表示一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系，父类是子类的泛化
通俗说法就是：“...分为几类，包括...”、“...是...的一类”

表示方法：空心箭头的实线，箭头指向父类

继承

继承关系是泛化关系的反关系，子类是从父类中继承的

聚合

表示类之间的关系，是整体与部分的关系。聚合关系的含义是“聚”在一起的含义，“部分”可以独立于“整体”而存在

表示方法：带空心菱形的实线，菱形指向代表“整体”的类

组合

表示类之间的关系，是整体与部分的关系。表示“部分”完全是依赖“整体”而存在的

表示方法：带实心菱形的实线，菱形指向代表“整体”的类

E-R图

定义

也叫实体关系图，与数据库结合的更加紧密，但在领域建模阶段语义不够丰富

使用时间

主要应用于数据库设计阶段，由于需求分析阶段不涉及数据库设计工作，因此不建议在需求阶段使用E-R图

角色与使用场景分析（用例分析）

用例分析技术的关键

从用户的角度出发，将系统看做一个黑盒子
1. 发现使用系统的角色（参与者）
2 .了解并梳理这些角色将如何使用系统（场景）

主要要素

参与者（角色）

定义

参与者是用户相对系统而言所演的角色

判断要点

是不是系统行为的触发者

参与者范围

参与者不仅有人承担，还可以是其他系统、设备甚至是时钟（定时器）

用例

定义

用例是对一类相关行为的抽象（类比一个类是对一类对象的抽象）

一个用例定义了一组用例实例【场景】（用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果）

用例图

为什么要用用例分析技术？

用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现

用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素

关系

用例与用例之间的关系

包含关系

是指基用例在它内部说明的某一个位置显式的合并了另一个用例的行为

表示方法

带箭头的实线，由基用例指向被包含用例，直线上标注《include》或《包含》

被包含用例是不能独立存在的，它仅作为基用例的一部分出现

使用场景

包含关系建模的通常是多个用例所包含的公共子事件流

扩展关系

是指基用例在由【扩展用例间接说明】的一个位置上，隐式的合并了【扩展用例】的行为

表示方法

带箭头的实线，由扩展用例指向基用例，直线上标明《extend》或《扩展》

基用例可以独立于扩展用例存在，只有在特定的条件下，它的行为才会被另一个用例的行为所扩展

使用场景

扩展用例建模的通常是优先级较低的扩展事件流

泛化关系

表示子用例集成了父用例的行为和含义，子用例可以增加或覆盖父用例的行为；子用例可以出现在任何父用例出现的地方

表示方法

带空心箭头的实线，由子用例指向父用例

使用场景

泛化用例建模通常是开发团队对用例的共性进行抽取

参与者与用例之间的关系

一个参与者和用例之间的关联关系表示两者之间将进行通信，任何一方都可以发送和接收消息

参与者与参与者之间的关系

两者之间只有泛化的关系

表示方法

带空心箭头的实线，由子参与者指向父参与者

使用场景

为了避免用例图之间的连线交叉，方便阅读

如何从需求中归纳出用例？

自顶向下导出法

适用场景

适用于业务流程易于梳理，业务事件清晰的项目

思路

从跨职能流程中派生出用例图（跨职能流程图是通过系统分解为主题域，主题域划分为业务事件，业务事件绘制得到的流程图）

流程图中的岗位信息（即跨职能流程图中的职责帯区、活动图中的泳道）是参与者的候选者

流程图中的业务活动就是用例的候选者

“是否在系统范围内”是评价是否是“参与者和用例”的要点

步骤

确定边界：排除掉不直接使用系统的岗位，因为它们不是系统涉及的范畴

确定角色：对排除后剩下的岗位（职责帯区）进行角色化，确定出与系统相关的参与者

确定用例：用例是从业务活动中派生出来的：
对于活动（矩形表示）：主要判断是否属于系统范畴内；
对于判断（菱形表示）：主要判断是属于某个业务活动还是属于一个独立的活动

绘制用例图：根据以上3步，就可以得到用例与参与者，就可以绘制出用例图

自下向上合并法

适用场景

适用于某些流程并不是那么泾渭分明的中小型项目，流程不易于梳理

步骤

收集原始需求：收集用户原始的需求，生成用户原始需求列表

确定参与者：通过原始需求列表，可以得到一部分候选者，通过系统边界进行排除

合并用例：第2步确定参与者后，按照参与者将原始需求列表进行分类，并对同一参与者下的相似或相近需求进行合并命名（起一个简短的名字）

绘制用例图：第3步将用例、用例与参与者的关系确定后，就能很直接的绘制出用例图了

用例分析技术的要点

用例的颗粒度

不能真正为用户或组织产生价值的结果都不是用例，比如：输入查询条件，没有用户输入查询条件就离开

常见误区

将被包含用例、扩展用例认作真正的用例（在面向用户的用例图中，包含和扩展都不应该出现）

“用例颗粒度”与系统的复杂度有关：真正影响用例的颗粒度的是业务流程和工作任务的分工

滥用“CURD原则”：将“新增XX、更新XX、删除XX、查询XX”之类的用例合并为“直接管理XX”这是不合理的，在很多系统中CURD操作实际上都不是由一个角色完成的，怎么能合并为一个用例呢？
CURD原则只有对于“系统创造的东西”才适用，例如：管理数字字典、管理权限等，不能

用例的命名

使用业务动词进行用例命名，尽量表述出业务场景性（不要滥用CURD原则）

用例分析顺序

采用先事后人的方式分析是要点：在分析过程中，应该将人（角色、参与者）和事（场景、用例）分开考虑，在确定它们关联时，要先事后人的思考：
1、先确定参与者
2、将“事（用例）”抽取出来
3、完成参与者与用例之间的连接
4、如果需要，通过泛化对有交叉情况进行改善（实际上就是按照参与者执行用例的多少进行泛化，有点类似于“包含”的意思）

周期一产物

目标（核心任务）

结合业务流程和报表的需求，梳理出结构框架（领域模型：跨职能流程图、类图）和行为脉络（流程图——>用例图）

业务事件分析

业务流程分析

跨职能流程图

业务实体分析

类图

角色-使用场景分析

用例图

报表分析

目标（Why）分析

明确使用对象：明确部门/职位

理解报表用途：说明报表的业务意图（目的）

了解非功能需求：了解相关场景与查询频率

内容（What）分析

相关业务实体分析：通过目标分析中的理解报表用途，分析得出报表关联的业务实体，用类图表示出来

报表项分析：在需求定义阶段或目标分析阶段得到的通常还是一类报表，不是具体的报表项，我们需要根据实际需要确定出具体的报表项，并将每一个报表项建模成一个用例（该阶段通常需要与客户进行交流并结合报表目的的分析）

数据项及计算方法分析：分析得到报表项后，就可以根据各类报表明确重要的数据项，并说明派生出来的数据项的计算方法

展现形式（How）分析

抽象和整理

通过以上分析，已经得到了很多用例图片段与领域类片段，
接下来就需要通过Rose/EA等工具对其进行抽象，创建政
整个主题域的用例模型与领域模型

抽象用例模型

将各个用例图片段按照参与者进行整理。具体来说，就是创建一个主题域的用例图，然后找出上面得到的参与者、用例拖到这张图中，并做适当的整理（如果用例太多，可以通过分包的形式处理）

抽象类模型

将各个领域类图片段中出现的所有类拖到一个新创建的主题域类图中进行适当的整理（如果类太多，可以通过分包的形式处理）

填充SRS

根据以上4步，就可以完成结构框架与行为脉络的填充，将其补充在SRS中

需求分析周期二：确定需求细节

任务

对用例模型、领域模型标识出用例、领域类的细节进行填充

对于行为需求的用例，要填充用例的事件流

事件流