软件架构基本功:如何去分析业务需求

按:在软件架构的基本功中,需求分析与建模是第一关。但大部分人都不根本不懂...orz....还有小部分人懂、却不用....orz.....本文虽长、但却较系统的介绍了下需求分析相关知识,要耐下心来多琢磨的。这也是专业和业务选手的根本区别。本文来自简书昆仑怒道的分享。

 

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

1.1.1 需求分析到底做什么

需求分析的任务不是分析系统如何实现用户的需要,而是对业务分析,形成一个体系完整,内容清晰的业务框架,以指导后续的设计开发工作。

需求分析就是先分解,再提炼,在这个过程中消除矛盾。

1.1.1.1 分解

现代需求工程理论更建议采用业务导向分解,而非传统的系统导向分解。

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

软件架构基本功:如何去分析业务需求_第1张图片

这种结构是以业务流程为主线索,对于联机事务处理系统,管理信息系统而言都是非常适用的方法。

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

软件架构基本功:如何去分析业务需求_第2张图片

这种分解结构过早的进入了程序结构,割裂了与问题域之间的联系,从医导致对问题研究不足的情况,从而降低需求质量,增加变更风险。这种结构适用于问题不复杂,系统与问题关联性不强的情况,例如工具软件,面向设备的系统等。

》基于场景的分解结构

软件架构基本功:如何去分析业务需求_第3张图片

对于决策支持系统,面向用户的嵌入式系统,就比较适合使用场景作为线索。这些场景向上可以总结成一系列关注点或功能域,向下可以分解成具体的决策步骤。

》基于数据的分解结构

软件架构基本功:如何去分析业务需求_第4张图片

 

》小结

选择了合适的分解结构之后,就可以按其线索把需求规格说明书大纲确定下来了,就知道应该捕获什么信息了,信息捕获回来之后就将其填充到大纲里,并不断验证。

1.1.1.2 提炼

分解是一种自顶向下的方法,按任何一种线索分解,都会破坏其他线索的完整性。所以还需要自底向上的方法进行提炼,抽取出共性的部分,建立针对全局的领域模型。

1.1.1.3 消除矛盾

1.1.2 建模的目标和要点

建模的过程比结果重要。

建模是需求分析的主要手段。但如果为了建模而建模,它就会变成一个问题,导致华而不实,造成沟通障碍。

1.1.2.1 建模的目的

建模的好处在于更好地理解正在开发的系统。建模的目的在于帮助我们按照需要的样式对系统进行可视化,提供一种详细说明系统的结构或行为的方法,给出一个指导系统构造的模板,对我们所做出的决策进行文档化。

1.1.2.3 建模的要点与原则

要点:设计要文档化;用可视化的模型表达架构;不要为了建模而建模,如果模型不能对系统的构建起到帮助作用,那么就是一种人力资源的浪费。

模型是用来沟通的,因此仅当需要的时候才构建模型。

1.1.3 选择建模工具的要点

1.1.3.1 正确认识建模方法论

软件架构基本功:如何去分析业务需求_第5张图片

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

 

1.1.3.2 正确认识UML

》UML的发展历史

》UML的准确理解

》为什么要用UML建模

》如何选择UML图

软件架构基本功:如何去分析业务需求_第6张图片

软件架构基本功:如何去分析业务需求_第7张图片

1.2 周期一:理清框架与脉络

任务:理清需求的结构框架(领域类图),行为脉络(流程图和用例图)。

输入:需求定义阶段产生的业务时间列表和报表列表。

输出:领域模型和用例模型。

该任务对应于RUP中细化阶段的第一次迭代,该阶段的结束标志是标识除了绝大部分用例,生成了领域模型。

1.2.1 业务流程分析

软件架构基本功:如何去分析业务需求_第8张图片

每个业务事件都是流程的触发,因此针对每个事件都应该继续做流程分析。不过根据流程的复杂度作出裁剪,简单的流程可以只用文本描述,复杂的流程可以通过流程图表示。

1.2.1.1 业务流程分析任务概述

业务流程分析,具体来说就是识别,分析现有业务活动,确定活动之间的关系,了解活动需要接受哪些信息,产生哪些数据,确定数据传输路线,标识出活动是由哪些部门,岗位负责。

分析过程中,要注意抓住核心业务和主要活动点,部门之间的衔接,工作中繁琐,反复,成本高,效率低,时间长,转手多的活动。

1.2.1.2 业务流程分析与流程管理理论的关系

业务流程是对信息系统进行庖丁解牛的核心线索。

》流程的六大特性:目标性,内在性,整体性,动态性,层次性,结构性。

》工作流实现的本质

》流程设计(BPD)的原则

1 流程应该以产出为中心,而非任务为中心。

2 让需要得到流程产出的人自己执行流程。一方面现在流程设计经常引入自助的概念;第二个方面是任务应该由谁来执行可以参照这一原则。

3 将决策权放到更低的管理职位上,这样会得到更高的效率。在需求分析时,如果发现流程的决策点在较高的管理岗位上,就应该注意它经常会带来执行上的瓶颈,也就会影响系统的正常运作。

4 流程多样化。因为场景不同,同一个业务事件可能会执行不同的流程,在系统开发时,应该充分考虑到。

5 单点接触客户。这一点充分体现了流程对外部客户满意度的关注,也是未来流程变化的一个常见趋势。

》流程改进(BPR)的ESIA策略

ESIA就是清除低效环节(E),简化瓶颈点(S),整合资源(I),繁琐任务自动化(A)。

软件架构基本功:如何去分析业务需求_第9张图片

这些因素就是导致流程发生变化的主要原因。

1.2.1.3 业务流程分析的要点与产物

在进行业务流程分析时,有几个关键点:

》流程是有层次的

软件架构基本功:如何去分析业务需求_第10张图片

部门级是需求分析的主线索,岗位级是需求细节填充时的工作内容,组织级是对部门级流程的抽象概括。

》流程是有类型的

主要类型包括:

生产性流程:是流程中最重要的部分,通常也最容易标识。

管理型流程:是对生产性流程的管控,对质量效率进度等进行控制的流程,容易忽略。

支撑性流程:是对生产性流程的补充,通常是协作部门,本部门员工执行,也是容易丢失的部分。

》流程分析的产物

应该尽可能地使用模型来描述流程。最常使用的有三种:跨职责流程图,活动图和数据流图。

跨职责流程图:强调业务背景。Visio是最佳工具。

活动图:强调对软件开发的指导。Rose,Together都是最佳工具之一。

数据流图:强调数据的流通加工和处理。Visio是最佳工具。

1.2.1.4 跨职责流程图应用基础与要点

软件架构基本功:如何去分析业务需求_第11张图片

》元素

流程名称,职责带区,流程阶段,流程元素。

》绘制要点

要保障绘制出来的流程图是真实有效的,就必须要强化用户参与。

要善于,敢于抛弃细节,不要过早钻研到业务活动的具体步骤中。

要抛弃一次成型的思路,使用迭代的方式,画草搞,谈问题,改草搞,再讨论,再修正,直到达成共识。

所有职责带区上的活动都细化到具体的岗位。

每个活动之间的关系都已经没有疑问,都达成共识。

1.2.1.5 活动图应用基础与要点

软件架构基本功:如何去分析业务需求_第12张图片

活动图就是可以支持并行行为的流程图。

在完成活动图或跨职责流程图之后,还需要注意:

》进行瓶颈分析。

》进行利益分析。

当流程图绘制完成之后,花些时间进行瓶颈和利益分析,会有意想不到的收获。

1.2.1.1 数据流图应用基础

对于数据流为主线索的处理过程非常合适。

》主要元素

软件架构基本功:如何去分析业务需求_第13张图片

》分层的数据流图

软件架构基本功:如何去分析业务需求_第14张图片

1.2.2 业务实体分析

具体来说,就是要了解这个问题域中有哪些业务实体,它们之间存在什么样的逻辑关系,数量关系,以及有什么相应的结构规则。

1.2.2.1 业务实体分析任务概述

在领域建模过程中,更多地采用自底向上的方法,针对每一个业务事件或报表,分析类图片段,然后再将这些片段抽象,提炼,合并,形成全局的领域模型。

实体分析的产物有两种可选模型:类图,ER图。推荐使用类图。

1.2.2.2 类图应用基础与要点

》面向对象思想

》类的表示方法

软件架构基本功:如何去分析业务需求_第15张图片

》类之间的关系:关联,泛化,组合。

软件架构基本功:如何去分析业务需求_第16张图片

》确定类的主要职责:属性和方法。

领域模型(类图),是自底向上合并出来的。

领域模型应该遵循:拒绝实现细节,大类不拆分,子类不合并,同类不抽象。

软件架构基本功:如何去分析业务需求_第17张图片

领域模型:以面向对象的视角看待现实世界,通过类图来描述事物之间的关系。因此主要工作是找出相关的类,以及他们之间的关系。

分析模型:分析模型是针对软件系统分析,领域模型则偏重对业务分析。分析模型主要用到实体类,控制类,边界类。

设计模型:设计模型将直接对编码予以指导。

1.2.2.3 ER图应用基础

ER图的优势在于更好地跟数据库设计结合,缺点在于语义较类图更弱一些。

》数据建模过程

软件架构基本功:如何去分析业务需求_第18张图片

1.2.3 角色与使用场景分析

用例分析技术,能更好地以用户的角度,将系统当作一个黑盒子,了解并梳理需求,解释如何使用系统(场景)。

1.2.3.1 用例分析技术概述

用例分析技术,包含两个部分:用例图,用例描述。用例图是目录,用例描述是封装所有需求的形式。

1.2.3.2 参与者与用例

参与者是一种角色,可以是人,可以是其他系统,可以是硬件设备,也可以是时钟,但一定要是在系统之外。

参与者是直接使用系统的最终用户,任何间接与系统相关的人员是StakeHolder,不是参与者。

1.2.3.3 用例图

千万不要为了使用扩展,包含关系而使用他们。扩展用例建模通常都是优先级较低的事件。面向客户的用例图通常都不应该出现包含关系,这些事情应该是在面向开发团队时才进行填充和归纳的细节。

1.2.3.4 用例的来源

如何从需求中归纳出用例呢?通常可以采用两种方法:自顶向下导出法,自底向上合并法。

》自顶向下导出法

就是从流程图中派生出用例图。而流程图是通过划分主题域,再从主题域标识业务事件,然后通过业务事件绘制出来流程图。

拿到流程图后,我们首先可以跟客户进行边界确定和角色确定,以得出表示系统边界的用例图。

1 边界确定。首先排除掉不直接使用系统的岗位。

2 确定角色。对剩下的职责带区进行角色化。

3 确定用例。用例是从职责带区中的业务活动中派生出来的。

4 绘制用例图。有了以上分析,我们得到了角色,参与者,用例,就可以绘制出用例图了。

》自底向上合并法

对于一些中小项目而言,流程并非泾渭分明,从流程开始梳理会比较困难,就适合采用自底向上合并法,从需求捕获阶段得到的需求列表着手,合并出需要的用例。

1 收集原始需求。

2 确定参与者。

3 合并用例。

4 绘制用例图。

用例的注意事项:

1 用例图的颗粒度取决于业务价值。

2 用业务动词命名用例十分重要,不要在用新增xx,修改xx,删除xx,查询xx了。

3 采用先事后人的方式分析,而非先人后事。

 

1.3 周期二:确定需求细节

这一阶段的任务,是对上一阶段产出的用例模型和领域模型进行细节填充。对于行为需求的用例,我们要填充事件流,包括:相关需求或功能点,界面原型,用例规则与约束。对于数据需求的领域类,我们要填充字段与格式,包括字段信息,字段格式与规则,计算规则,结构规则。

1.3.1 确定行为需求的细节

行为需求对应的是“人,事,物,接口”四大需求主线中的“事”,这也是软件功能需求的主体内容。

1.3.1.1 用例的灵活运用

行为需求可以分为四个类型:业务功能,报表功能,接口,技术支持。

软件架构基本功:如何去分析业务需求_第19张图片

1.3.1.2 用例描述模板

对于行为用例来说,需要整理的内容有事件流,相关需求或功能点,界面原型,规则或约束四个方面。

软件架构基本功:如何去分析业务需求_第20张图片

事件流分析:场景和用例的关系,类似对象与类之间的关系,一个用例是对一组类似场景的抽象。而一个用例通常是一组事件流所构成。

1.3.1.3 业务用例与系统用例

业务用例描述的是所有业务操作,系统用例则只描述与系统相关的业务步骤。要警惕将系统用例写成界面操作。

下面是机场checkin的业务用例与系统用例示范:

软件架构基本功:如何去分析业务需求_第21张图片

业务用例

很明显,2,3,1,9都是跟系统无关的步骤,将他们去除后,就从业务用例得到了系统用例。

软件架构基本功:如何去分析业务需求_第22张图片

系统用例

》创建业务用例的好处:避免开发层面断章取义,而使系统步骤融入到业务场景中;提供业务优化的可能性;更好设置未来的拓展点。

》事件流描述中,应该保留主语。可以使用表格或者文字的方式。

软件架构基本功:如何去分析业务需求_第23张图片

软件架构基本功:如何去分析业务需求_第24张图片

避免在用例事件流描述中出现实现细节,分支结构,循环结构。特别是不能出现多路分支结构。

1.3.1.5 界面原型

》要点:软件需求规格里的用户界面原型,是约束,建议,而非解决方案。需求分析人员也只能给用户界面设计提供依据,而非设计。

》不要忽略交互。可以采取动态原型的方式,也可以用状态图表示界面的流转。

》别让界面掩盖本质。

1.3.1.6 规则与约束

规则是在实现时应该考虑的东西,约束是对技术选择时的限制条件。

》规则的类型:业务规则,数据规则,界面规则。

业务规则:与业务逻辑相关的规则。

数据规则:数据结构层面上的规则。比如长度,类型等。

界面规则:用户界面相关的规则。比如什么颜色的数据显示不同的等级。

》规则的层次

数据与界面规则通常都是微观规则,而业务规则却通常涉及宏观微观等多种不同层次,因此在组织时需要注意其中的差别。

软件架构基本功:如何去分析业务需求_第25张图片

总之,对于规则与约束,有一个核心原则,就是“只写针对本用例的内容”。

1.3.1.7 基于stakeholder利益分析的需求挖掘

软件架构基本功:如何去分析业务需求_第26张图片

1.3.2 确定结构需求细节

如果说行为需求从用例模型中得出,结构需求就是从领域模型中得出。我们将从基本内容和常见盲区两个角度来说明结构需求的细节填充。

1.3.2.1 基本内容

》领域模型的组织

从领域模型的组织角度来说,通常会首先按照主题域进行第一次分解,一个主题域对应一个领域模型,然后根据需要将各个主题域共性的领域类抽取出来,形成全局公共领域类模型。对于每个主题域内的领域模型而言,涉及的领域类可能还是很多,就可以根据逻辑关系划分为不同的包,每个包就是一个逻辑相关的领域类图的片段。接着对每个片段进行概述。就得到以下层次:

软件架构基本功:如何去分析业务需求_第27张图片

在xx类中,我们就可以对每个领域类做进一步描述了。通常都是从“数据窗口分析”,“数据组成与格式”,“派生数据的计算方法”三个角度进行描述。

》数据窗口分析

系统中的公共数据经常成为工作交叉和冲突的地方,对于这种情况,建议采用数据窗口的方式处理,即将公共属性变成公共的,个性属性仍然压在各个模块中。

软件架构基本功:如何去分析业务需求_第28张图片

》数据组成与格式

数据组成与格式包括:数据类型,如int,char,boolean等;长度精度等信息。组成格式,如2位字母,6位数字等。

》派生数据的计算方法

领域类中,还可能涉及一些并非直接输入的属性,他们的值是通过计算得出的,例如订单的总金额等。因此我们还需要为这些属性生成规则。通常通过决策表或决策树的形式来描述他们。

软件架构基本功:如何去分析业务需求_第29张图片

1.3.2.2 常见盲区

与结构需求相关的,还有一些相关的盲区。

》数据结构的特点

对于一个领域类而言,不同的属性它们的重要性,稳定性,周期性都会影响到具体的开发决策,例如:主要字段与次要字段,稳定字段和不稳定字段,即时记录与历史记录。

》数据使用特点

》非功能要求

1.3.3 周期二的产物

完整的用例描述,完整的领域类细节,界面流转图,页面原型。

 

1.4 其他需求分析

其他需求包括:接口需求,全局性的非功能需求和全局性的设计约束。

1.4.1 接口需求

哪里有分解,哪里就有接口。当标识出接口之后,千万不要谈及接口的设计和实现,从需求的角度来说,接口的重点应该从使用者,内容与格式,设计约束与要求三个方面展开。

1.4.1.1 使用者

在描述接口使用者时,可以从以下角度进行说明:

》使用者名称,罗列出该接口的外部使用者。

》业务目的,说明使用者通过该接口实现什么样的业务。

》使用时机,说明使用者将在什么场景中使用该接口。

》使用频率,描述各类使用者调用该接口的频率。

1.4.1.2 内容与格式

1.4.1.3 设计约束

对接口实现时必须考虑的约束条件或设计要求,内容比较广泛,例如协议格式要求,性能要求,环境限制等。

1.4.2 非功能需求的追踪

1.4.2.1 质量特性分析

在组织非功能需求类型时,可以参考相关的质量特性标准,其中最常用的有ISO/IEC 9126软件质量模型 和 McCall软件质量模型。也可以根据自己项目的特点,关注重心来确定。接下来我们将介绍ISO/IEC 9126定义的6类21项质量属性进行简要分析。

》功能性

》可靠性

》易用性

》效率

》可维护性

》可移植性

软件架构基本功:如何去分析业务需求_第30张图片

软件架构基本功:如何去分析业务需求_第31张图片

1.5 小结

SERU方法的核心,就是从“事,物,人,接口”四个主线着手,沿着业务脉络(业务主题域-业务事件/流程-业务活动-业务步骤)进行分解,构建(构件-流程图-用例-事件流),实现需求分析。

 


=>更多文章请参考:《中国互联网业务研发体系架构指南》

=>更多TOP权威案例及行业标准资料请关注微信公众号:

公众号:关注更多实时动态 更多内容关注公众号:软件真理与光

你可能感兴趣的:(业务技术,架构,后端)