软件需求分析和开发最佳实践:需求过程框架概述

发表于:2021-4-16 09:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:人月聊IT    来源:今日头条

分享:
  今天对于需求分析最佳实践,我基本会参考徐锋老师的《软件需求最佳实践》一书进行展开说明,对于该书也推荐给所有准备系统学习需求分析和开发方法的需求人员。
  SERU框架是《软件需求最佳实践》一书中所提倡的一套需求分析方法论,它讲述了一套将目标系统分解为主题域,再分解为流程,最后得到用例以及业务实体的方法,可作为需求分析的指南。
  首先对SERU模型的四个字母再做一个说明:
  · S:Subject Area,表示子问题域,其核心思想是要通过业务来分解系统
  · E:Event,表示业务事件,通过业务事件能够找到流程,通过流程能够找到不同场景和用例。
  · R:Report,表示报表,统一处理查询,分析和统计类需求。
  · U:Use Case,表示用例,需求组织的最小单位,到了需求分析阶段的重要活动和产出。
  SERU过程框架模型将需求过程分解为了三个阶段,第一个阶段是需求定义,重点是主题域划分和业务事件识别。第二个阶段是理清需求框架和脉络,重点是通过业务流程图转到具体的领域类图和用例图。到了第三个阶段重点就是填充需求细节,包括用例的详细编写,界面和交互设计等。
  在SERU框架中,先根据业务相关性以及所涉及组织的职责分区,将目标系统分解成不同的主题域,在这个过程中使用构件图对主题域划分结果建模,不但可以表达出系统的组织结构,还可以表达出不同组织域的协作关系;
  在每一个主题域中都包含一些业务事件,通过使用上下文关系图对主题域的范围进行建模,可以得到这些业务事件,从而得到流程;
  通过流程分析并使用活动图或跨职能流程图对流程建模,可以清晰地分析出流程中的业务活动及它们之间的关联关系。在对流程分析的过程中同时会发现一些报表,这些报表及流程中的业务活动将会成为用例;
  经过流程分析后,流程中的业务活动已非常清晰,剔除那些与目标系统无关的业务活动后,可以将余下的业务活动以及分析得到的报表直接转化成用例,从而得到用例图片段。而在对流程及报表分析过程中,可以提取出目标系统中的所要管理的业务实体,从而得到领域模型片段;
  简单总结来说就是整个需求过程框架包括了主题域,上下文,流程,报表,数据,实体六个关键阶段和内容,因此下面我将对上述各个阶段展开做下详细描述。
  主题域划分
  我们看一个传统模块划分的例子,如下。
  在上图的例子中,模块的划分是以“物”为中心的,比如说“文档管理”,这个模块的中心是对“文档”的管理,而系统中文档与公司所有的组织均有关系,这就意味着在调研这部分的需求时,要调研几乎所有的部门才不至于遗漏需求,而需求分析及确认时,则也几乎要与所有部门进行确认,一方面会导致需求分析人员进行需求确认的难度,另一方面也可能会导致需求的遗漏。
  另外,如上图例子中,是通过传统的框图来表达系统结构,在这样的框图中,只能表达出系统所包含的模块,却无法表达出模块之间的协作关系。
  那么,应该如何对目标系统进行第一层次的分解呢?
  为了解决上面的问题,在对目标系统进行分解时应以职责即“事”为线索进行。以职责划分角度出发将目标系统按所要处理的事务分解成不同的块,在SERU框架中将其称为主题域,即Subject。
  主题域划分方法与企业职责划分及组织架构吻合度高,用户可以只参与自己有关的主题域的需求调研,只针对与自己有关的主题域需求进行确认,有利于促进用户参与,也有利于保证业务流程的完整性,避免业务流程被人为割裂从而产生需求遗漏。
  实际在进行主题域划分时,可以从组织结构以及组织结构中的分管领导作为切入点,将职责相同或有紧密联系的组织放在一起成为职责块,再将职责块所负责的业务域作为独立的主题域。
  主题域划分完成后,使用UML规范中的构件图对其建模,构件图不仅能表达出目标系统间的结构:构件,也可以表达出不同部分之间的接口关系:构件之间的接口。
  总结一下,主题域划分的要点如下图。
  基于上面的分析我们再来看一个主题域划分的实例。
  见上图,参考案例中体检医院的组织结构中共有六个部门,而这六个部门可以按职责划分三块:销售、生产、后勤,其中销售区块负责体检业务的推销,生产区块则负责体检业务的开展,而后勤区块则负责支持体检医院的日常运行。
  有了上面的分析后,就可以按照上面的职责区块将待开发的目标系统划分为三个主题域,分别满足销售区块、生产区块以及后勤区块业务需求。
  销售区块所负责的业务主要是业务推销、客户管理等,需要纳入系统管理的主要是客户服务业务,所以对应的主题域叫做“客户管理子系统”;生产区块主要负责体检业务的开展,所以对应的主题域叫做“体检业务子系统”;而后勤区块包括物资管理及财务管理,因财务管理已经有专用系统,所以需要纳入系统管理的就是物资管理业务,所以对应的主题域叫做“物资管理子系统”。
  上图中不但使用构件表达出了主题域及系统的结构,还使用接口表达出了主题域间的接口。
  上下文-主题域范围分析
  主题域划分完成后,对于每个主题域而言,里面究竟包含多少业务流程呢?换句话讲,这个主题域的范围有多大呢?在分析主题域范围时,可以使用上下文关系图来建模,使用一个上下文关系图来表达一个主题域。
  在绘制上下文关系图时,将待分析的主题域当作黑盒子,找出所有相关的外部客户(Customer)及内部角色(Worker),再识别出所有外部客户及内部角色主动发起的所有业务事件,根据这些业务事件,按序标出各个角色的反应。
  在绘制上下文关系图时,需要注意的是要先识别外部客户主动触发的业务事件,然后再识别内部角色主动触发的业务事件。
  为什么要先识别外部客户主动触发的业务事件呢?因为外部客户所触发的业务事件更可能是业务流程的起点,大部分内部角色所采取的动作大部分是对外部客户所触发业务事件的反应。
  绘制上下文关系图是为了识别主题域中的业务事件,所以这个图最好是在和用户进行访谈时就绘制,在纸上绘制的草图就是非常好的方式;若主题域较小、比较简单或是其中的流程非常明显时,可以不需要绘制上下文关系图,不要为了画图而画图。
  参考案例中体检医院的管理系统被分解为三个主题域,其中“体检业务子系统”这个主题域主要的外部客户就是体检者,而内部工作人员包括服务人员、收费人员、体检科室以及综合科医生。
  在为这个主题域绘制上下文关系图时,先考虑外部客户主动发起的业务事件,体检者最主要的业务事件就是申请体检,也可能会在体检过程中要求修改,这就是外部客户主动发起的业务事件。

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号