软件需求分析之流程分析和识别

发表于:2021-4-20 09:25

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

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

分享:
  流程分析时,需要注意流程的目标性、内在性、整体性、动态性、层次性、结构性这六大特性,以及流程设计的几大原则,具体可参考流程设计的专业书籍。
  流程是需求分析的重要内容,流程图对于和用户确认需求以及向开发团队传递需求都是非常重要的。可以选择使用UML规范中的活动图或商业建模标准中所推荐的跨职能流程图对流程建模。
  在绘制流程图时,需要特别注意流程的层次性,在需求分析的早期阶段最好以业务活动作为流程图中的活动,不要过早地进入业务步骤等细节的分析。
  这是SERU框架推荐的主要方法,通过对主题域进行分析并绘制上下文关系图后,即可得到主题域中所包含的业务事件,通过对业务事件所触发的各角色的反应形成业务流程,识别过程如下图所示。
  以下是另一个通过业务事件识别流程例子,例子所属的业务领域为手机交易。在这个领域中,可能的业务事件有客户下单,而为了应对这个业务事件,对应的流程就是企业的销售流程。
  除了上面提到的方法外,还可以对目标系统的主要客户以及目标系统的业务生命周期进行研究,从而得到一些业务流程。
  拿一个销售管理系统为例,分析客户的生命周期就可以知道存在知道、愿意、购买、接收、付款等阶段,那么对应这些阶段,可能的流程就有市场推广、市场调查、订单管理、配送、收款等流程,具体如下图。
  报表分析
  通过流程分析,可以得到流程中的活动,这些活动未来将被转换成为用例。然而,如果只进行流程分析并基于流程中的活动来转换用例,将会遗漏一部分需求,这就是报表类的需求,因为报表类的需求一般不会体现在业务流程中。
  报表类的需求是一个广义的概念,包含查询、统计、度量、报表等,主要特征就是它们是数据的消费者,要么是对业务活动的支持,要么是对业务活动的管理,但一般不会出现在业务流程中。
  在对高层进行调研时可以得到管理类的报表需求,而在对业务事件进行流程分析时,出于逻辑上的完整也可以识别到支持类的报表需求,如查询,没有这类需求,业务活动会难以进行。
  以参考案例为例,在对高层访谈时,可能会得到这样的信息:希望能定期对体检业务进行统计分析,这就是一个管理类的报表需求:体检业务周期统计报表;
  在对体检者申请体检这个业务流程进行分析时,其中有一个业务活动“返还客户”,即客户人员将体检报告返回给体检者,服务人员在返还体检报告时,需要对体检者的体检报告进行查询并确认是否已经返还,这就是一个支持性的报表需求:查询体检报告返还情况。
  用例分析
  在传统的需求分析过程中,用例抽取主要依靠需求分析人员的经验,没有统一的方法及手段,这是目前需求分析中存在主要问题之一。
  在SERU框架下,经过将目标系统分解为主题域再分解为流程,流程中清晰地表达了角色所要执行的业务活动,这正是用例的内容,用例即用户使用系统完成业务活动的场景。
  除了业务活动可以转换成为用例外,前面所进行的报表类需求也可以比较明显地转换成为用例。
  在将业务活动及报表转换为用例后,使用UML中的用例图对用例建模,用例图不但可以表达出用户是如何使用系统的,还可以表达出用户与用户之间的关系,用例与用例之间的关系。
  从流程图转换用例
  可以从流程图中转换用例,从流程图转换用例就将流程图中业务活动转换为用例。比如体检者申请体检流程中的业务活动“出具报告”就可以对应转换为一个用例,其执行者是综合科医生,表达的是综合科医生将使用系统为体检者出具体检报告。
  从流程图中转换用例时,先基于流程图分析流程图中的哪一些是不直接使用系统,将其排除,将余下的职能带区(泳道)转为角色,将流程图中的业务活动及判断转换为用例,决定活动是否要转换为用例的标准是它是否属于系统范畴,而决定判断是否要转换为用例的标准是它是否独立。转换过程如下图所示。
  而对于报表类需求,转换为用例的过程是比较明显的,一个具体的报表项可以转换为一个用例。
  用例转换实例
  通过体检者申请体检的业务流程转换用例的步骤如下:
  确定边界:经过分析,体检者不会直接使用系统,去除其对应的职责带区。其它角色均要直接使用系统,保留。
  确定角色:确定4个actor,分别为服务人员、收费人员、体检医生及综合科医生。
  确定用例:按照流程图中的职责带区及业务活动及判断进行分析,“服务人员”有两个个业务活动“开单”及“返回客户”,“开单”要在系统中进行记录,“返回客户”要在系统中记录并打印,均属于系统范畴,转换为用例;“收费人员”只有一个业务活动“收费”,“收费”时需要在系统中操作,属于系统范畴,转换为用例;“体检医生”只有一个业务活动“体检并记录结果”,其中体检与系统无关,而记录结果需要在系统中记录,属于系统范畴,转换为用例;“综合科医生”对应一个业务活动“出具报告”及一个判断“体检已完成?”,“出具报告”时需要在系统中记录结果,属于系统范畴,转换为用例,而判断则不是独立的活动,从属于业务活动“出具报告”,不转换为用例。
  绘制用例图:用例确定后,可使用rose工具绘制出用例图
  业务实体分析
  通过SERU框架层层分解后,可以得到目标系统的业务流程以及基于业务流程的用例片段,系统的脉络已经清晰。
  但正如前面所讲,单一的模型是不充分的,用例模型只是对用户如何使用系统的业务场景进行建模,如果要构建系统,还需要对系统的框架进行建模,即要弄清楚目标系统所要管理的“物”:业务实体,并弄清楚这些业务实体间的关系。
  在对业务实体建模时,一般是使用“名词动词法”识别出业务实体。
  对业务实体建模选择使用UML规范中的类图或实体图作为模型,类图/实体图中的一个类/实体表达一个业务实体,类/实体的属性用于对业实体的属性建模,而它们之间的关系则可以用来对业务实体间的关联关系建模。
  对于比较复杂的业务实体,还可以采用UML规范中的状态图对其建模,可以表达出业务实体的状态切换与触发事件的关系。
  同样的,在对业务实体建模时,也需要注意建模的本质:仅是手段,目标是用于理清系统框架及用于沟通,所以不要在模型中加入过多元素及过早考虑细节,不要为了建模而建模。对于业务实体模型来说,实体本身以及业务实体间的关联关系,包括关联关系中的多重性比较重要,而实体属性则相对显得比较细节。
  识别业务实体一般采用“名词动词法”,即将需求描述及分析过程中的名词作为备选类,然后过滤掉与系统无关的或过小的备选类后得到候选类,最后绘成业务实体模型。识别业务实体的过程如下图示意。
  不过,因为使用面向对象思想进行系统分析,业务实体的识别对于需求分析人员来讲相对比较容易,大家可能意识不到这个过程。
  还是以上面的体检业务流程来举例,我们进行业务实体分析后形成的业务实体和类图可以通过UML建模做如下呈现。
  最后-自底向上提炼
  自底向上的过程包含两方面的内容,一方面是对于用例模型及业务实体模型的组织,另一方面则将各种片段抽象并在抽象过程中消除矛盾。
  基于SERU框架分解后,所得到的都是基于流程的用例模型片段以及领域模型片段,这些片段需要组织,组织用例模型、领域模型主要是使用“包”。
  在基于流程分析用例及业务实体时,因为分析的上下文局限于流程范围内,所以不同流程之间的用例及业务实体片段之间可能会存在一些重复、冲突等矛盾。另一方面,即使同一个流程中用例及业务实体,也可能需要向上抽象,从而得到更益于管理及更益于构建的用例模型以及领域模型。

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

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号