一种基于场景的需求建模系统及方法、信息数据处理终端与流程

本发明属于用于执行专门程序的装置技术领域，尤其涉及一种基于场景的需求建模系统及方法、信息数据处理终端。

背景技术：

目前，业内常用的现有技术是这样的：划分系统模块，按照模块进行调研及建模，建模过程更过站在程序实现的角度，而缺乏对用户业务的理解过程，不能够及时和有效的发现需求中存在的重大问题，不能引导客户建立起业务的全体视角和场景；以结构化的建模过程为主，主要使用组织结构图、业务流程图、数据流图等形式表达建模过程；以阶段划分清晰的过程割裂软件建模的一体化，造成前后关联不一致，需求与后期的设计开发不能有效统一。

综上所述，现有技术存在的问题是：以系统最终实现的功能模块为导向；采用了系统流程图、功能模块图等描述需求业务；开发过程贯穿了前后台技术；测试过程缺乏自动化，智能化脚本实现较少；开发过程阶段区分较为明显，但关联性又不强。

解决上述技术问题的难度和意义：以“功能模块为中心”的调研过程：需求调研不完善、业务了解不全面；业务贯穿能力差，较难形成闭环；以开发人员视角描述的需求过程：不能很好的站在客户角度想问题；以结构化建模为主的分析过程：忽略了业务的完整性，造成需求不完全不完善；以纵向结构为主的开发过程：要求开发人员水平高，从前台页面到后台逻辑以及数据库等方面全面贯通；以开发人员为主的测试过程：浪费人力，效率地下；以集中式部署为主的运维过程：出错影响大，升版只能停机，修改不能很好回滚；以阶段区分软件开发的整体过程：阶段割裂，前后不连贯，不能很好贯穿整个软件开发过程，没有形成统一的整体，不能很好的收集和反馈问题。

技术实现要素：

针对现有技术存在的问题，本发明提供了一种基于场景的需求建模系统及方法、信息数据处理终端。

本发明是这样实现的，一种基于场景的需求建模系统所述基于场景的需求建模系统包括：需求准备功能、业务建模功能、系统建模功能。

进一步，所述需求准备功能包括业务目标分解功能和涉众视图绘制功能以及涉众期望编制功能。

进一步，所述业务建模功能包括业务边界视图关联功能，业务用例绘制功能，业务情景分解功能，业务角色拆分功能、业务场景汇交功能、业务实体关联功能。

进一步，所述系统建模功能包括建立系统用例功能、关联系统情景功能、用户视图自动统计汇总功能、系统模块汇交功能、界面原型生成功能、概要视图汇集功能、概念实体关联功能、系统用户获取功能。

本发明的另一目的在于提供一种应用所述基于场景的需求建模系统的基于场景的需求建模方法，所述基于场景的计算机需求建模过程主要包括：

步骤一，执行业务目标初始化，形成分层的业务目标列表；

步骤二，依据每个业务目标分别生成业务边界视图；

步骤三，针对业务边界持续建立反映当前边界的业务用例；

步骤四，汇总所有业务用例，汇交向上形成关于业务的场景流程；

步骤五，针对单个业务用例，关联并建立动态执行过程的泳道图及其配套执行说明；

步骤六，针对每个活动图的活动，执行分解程序，对比约束规则生成系统用例；

步骤七，针对单个系统用例，分解形成系统执行过程的活动图，并生成前台页面初始化文件；

步骤八，针对生成的每个初始化前台页面文件，关联构件库，进行初步的服务装配制作建立页面布局原型界面。

本发明的另一目的在于提供一种实现所述基于场景的需求建模系统的计算机程序。

本发明的另一目的在于提供一种实现所述基于场景的需求建模系统的信息数据处理终端。

本发明的另一目的在于提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行所述的基于场景的需求建模系统。

综上所述，本发明的优点及积极效果为：本发明具有业务单据和报表转换为业务实体的过程，业务实体通过分析形成具有关联关系的概念实体的一条推导线索；涉众分析按照业务场景到业务角色的推导转换，业务角色在计算机执行角度推导出系统用户的演化线路；从业务现状描述(业务用例视图)逐步过渡到计算机化描述(系统用例视图)的推导演化过程，步步有依据，有推导，有演进。

附图说明

图1是本发明实施例提供的基于场景的需求建模系统结构示意图；

图中：1、需求准备模块；2、业务建模模块；3、系统建模模块。

图2是本发明实施例提供的基于场景的需求建模方法流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

下面结合附图对本发明的应用原理作详细的描述。

如图1所示，本发明实施例提供的基于场景的需求建模系统包括：需求准备模块1、业务建模模块2、系统建模模块3。

需求准备模块1包括业务目标分析模块、涉众分析模块。

业务建模模块2包括业务边界模块，业务用例模块，业务情景模块，业务角色模块、业务场景模块、业务实体模块。

系统建模模块3包括系统用例模块、系统情景模块、用户视图模块、系统模块、界面原型模块、概要视图模块、概念实体模块、系统用户模块。

如图2所示，本发明实施例提供的基于场景的需求建模方法包括以下步骤：

s201：建立业务目标，形成分层的业务目标列表；

s202：根据业务目标，分别建立并关联针对某业务目标的业务边界；

s203：针对业务边界，映射建立业务用例；

s204：针对所有的业务用例，汇交向上形成关于业务的场景流程；

s205：针对单个业务用例，分解并建立其动态执行过程的泳道图及其配套执行说明；

s206：针对泳道图中的活动，根据系统能够实现分别执行映射为系统用例；

s207：针对单个系统用例，分解形成系统执行的泳道图，并生成前台页面初始化文件；

s208：针对生成的每个初始化前台页面文件，使用构件服务分别建立页面布局原型界面。

本发明实施例提供的基于场景的需求建模方法具体包括：

项目准备：从以功能模块为中心，转变为以“用户为中心”；

进行涉众分析：从业务用户角度深入了解问题域，全面分析各涉众(干系人)期望，形成涉众分析报告，并在整个软件过程中全程维护；

规范业务范围：从项目已有条件(涉众期望、项目周期、成本、可行性分析等因素)调节业务范围，确定项目可以容纳的业务范围，这里的范围需要注意的是并非系统建设范围，而是需要调研应当被局限在哪些部分。范围的规划可从业务目标、涉众期望开始，衡量标准是争得涉众认可；

确定调研优先级：将涉众划分出调研的优先级，同时也将期望按重要程度划分出优先级，最重要的涉众当由最有经验的系统分析员负责调研，相应精力也应加大投入；

制定需求调研计划：按照三个阶段制定需求调研计划。(1)业务架构：围绕业务背景、业务目标、业务目标人员、业务参与人员、组织结构、岗位设置等展开。结果：业务用例模型的业务用例视图被建立起来。(2)业务流程：针对每个业务目标，将参与这个业务目标的业务目标人员、业务参与人员、组织结构和岗位设置组织起来，描述业务流程的运转过程以及每一个参与元素在运转过程中的贡献和期望。结果：包括业务用例实现、用例场景、分析场景在内的完整的业务用例模型被建立起来。(3)工作细节：针对每一个参与上述流程的参与者展开，描述他的工作细节，做什么、怎么做、有哪些规则、结果是什么。结果：系统用例模型、初步的分析模型和初步的软件架构被建立起来；

需求调研中的沟通：如何能快速准确的获取需求，需要对相关调研人员进行培训，并从不同的调研过程中总结经验，不断反馈调节。

进一步，所述业务建模模块包括业务边界模块，业务用例模块，业务情景模块，业务角色模块、业务场景模块、业务实体模块。

主要以反映业务实际运行现状作为目标。

需求调研:按照需求调研计划执行

定义边界：以业务目标推导边界

发现主角：识别主要参与者，区分业务主角和业务工人

建立业务用例视图：以业务目标为指导，完整建立针对某目标的uml业务用例，反映现实业务问题，从实际业务角度出发，不关心计算机实现问题；

建立业务场景视图：针对业务用例，建立该用例的完整动态执行过程，配套使用业务用例规约，将该过程尽量描述清楚；

进一步，所述系统建模模块包括系统用例模块、系统情景模块、用户视图模块、系统模块、界面原型模块、概要视图模块、概念实体模块、系统用户模块。

进入系统建模部分，主要以反映计算机运行业务的情况为目标，并结合所服务行业标准，参考业务实际情况而制定功能设计过程。

推导系统用例：从用户角度出发，按照业务目标所构建的业务用例，使用逻辑推理方法(演绎、归纳、提取、抽象、分解等)逐项推导系统执行用例视图；

获取非功能性需求：从业务需求调研表中汇总分析相关要求，从业务建模过程中提取相关非功能性需求；

系统场景建设：依据系统用例视图，从计算机执行的角度逐个分析每个用例执行过程，描述业务、人员和计算机在具体业务执行过程中分别承担的工作；

核心实体提取：获取关于系统执行过程中的主要业务实体，这里是获取关键信息、关键字段等；

定义原型：通过原型界面建设，将系统的布局、页面关键元素、主要执行功能、页面间跳转等用户关心内容落实，并保持持续关注。

下面结合实施例对本发明作进一步描述；

本发明实施例提供的基本场景的需求建模过程方法包括：

步骤一：需求准备

根据项目之前的可行性分析报告、技术协议、调研记录(包括会议、访谈等)分析总结汇总形成具体可量化的业务目标，一般通过使用表格展示最终结果。

同时，根据项目利益相关方列表、单位组织结构、岗位职责和各种调研记录，将统计所有相关涉众信息，并使用uml用例图表达涉众间的依赖和继承关系，最后使用列表罗列每个涉众对当前业务系统的期望，并根据对实际项目的影响程度和重要程度对涉众的每个期望赋予优先级，作为后续设计和开发任务分派的基本依据。

步骤二：业务建模

根据已经量化的业务目标，针对每个业务目标分别结合与此相关的涉众进一步划分出来的业务角色建立业务边界。即，每个业务目标划分业务边界，对此业务有主观发起愿望的角色赋予业务主角，被动参与此业务目标的人员被称为业务工人。

针对每个业务边界，继续量化为使用uml的业务用例图建模，如实反映现实业务问题，形成反映具体某个业务场景的业务用例视图。作为对业务场景的静态展示视图。

针对业务用例视图中的每个业务用例，使用uml活动图(泳道图)继续细化和分解，结合业务主角和业务工人，将业务用例需要表达的业务执行过程动态展示出来，形成业务情景视图。另外，针对每个活动图无法表达的前置/后置条件(来自于业务用例)，涉及的业务实体等使用业务用例规约表显式表达出来。

同时，针对所有业务用例形成反映实际业务流程的业务场景视图(活动图)，业务场景视图中的活动全部由业务用例汇总形成。通过两者的结合达到检测业务场景是否满足业务需求，检测业务用例是否有超出范围或遗漏的情形出现。

针对业务实际中存在的单据、报表等信息，进行初步拆分和统计，形成业务实体。方便后续节点的演进和使用。

步骤三；系统建模

针对业务情景视图中的活动，遵循在计算机系统中执行的活动，通过直接关联、拆分、演绎等多种手段映射为系统用例。系统用例发起人员即为系统的用户。多个系统用例结合业务场景形成计算机化执行的系统用例场景视图。

针对每个系统用例向下分解形成反映具体计算机执行过程的系统情景视图(活动图)。

针对每个系统情景视图，通过原型界面工具，绘制反映计算机动态执行系统情景的原型页面，结合概念实体，原型界面主要为客户反映界面布局和展示的核心业务字段信息。若干个原型界面通过前台界面内部的form表单元素、界面按钮、数据列表等，后台的业务business处理逻辑方法以及最终关联处理的实体entity，形成结构化的表格表达形式，将系统原型界面执行过程形式化、规范化，方便后续设计的开展。

系统用例按照业务用例视图范围向上汇总即形成反映计算机系统执行业务过程的系统模块视图。

概要视图是一种虚拟视图。由原型界面中的各个系统情景中的前台页面元素、业务处理逻辑和关联实体经过自动统计形成的，主要用于汇总和去重，以及为设计和开发做好前期准备。

用户视图也是一种虚拟视图。由系统用例场景视图转换角度后形成，用户视图主要通过最终用户的角度，检测当前角色用户在系统中功能是否缺失、是否超过等，用以再次确定业务需求的采集是否真实有效的反映用户期望。

本发明提供的基本场景的需求建模过程方法，总体遵循“正向可推导，反向可追溯”的原则，从需求阶段即采取有效的措施尽量将工作进行量化，从标准、阶段、方法等多个角度对需求过程进行建模，并通过一系列的方法和措施为软件工程后续阶段的量化和关联打下基础，从而实现软件开发全过程的有据可依，有法(原则、任务)可依。

下面结合具体实施例对本发明的应用原理作进一步的描述。

1.案例项目说明

薪酬管理案例，其实是一家公司整体信息化建设中oa系统的子系统，或者叫子模块(以下简称：模块)。该模块未纳入建设之前，该公司的人员薪酬都是电子表格excel手动计算，手动汇总信息，因此导致信息效率低下，同时出现了若干次遗漏及混淆错误，公司并为此付出了一定成本。正是基于此原因，公司决定实施开发本模块，以期望实现公司员工薪酬管理的信息化，因为薪酬管理又牵涉到考勤、员工定岗定薪等，公司高层也希望借此机会同时推动公司内部管理的规范化。就基于此背景，逐步展开对此模块的建模工作。

2.分析业务目标

从客户的回复及业务概况说明中就可以大致了解到了业务目标。最终，经过梳理和分析总结，得到了以下业务目标，见下表：

3.涉众分析

在本案例中，依据涉众的定义，参考涉众大类，经过关联性分析得出了如下图所示的涉众视图，以及涉众间的依赖代理关系，如：银行也是涉众之一，但是在案例中的公司，银行的工作实际上完全由财务部门代理。

针对每种类别的涉众，对其进行编号，并总结分析其主要期望，并根据此涉众在项目建设中的地位和其期望与项目建设的关联度，参与当前互联网流行的评分使用五级量化标准对涉众的每个期望进行量化。这里选取综合管理部的涉众期望作为示范，展示了期望的编写规范及形式，如下表；

新增期望删除期望上移下移

4.获取业务对象

在案例中，以原始的薪资表为基础，应用上述相关业务对象分解原则，得到初步分析的业务对象，如下表：

在上述业务对象的获取中，首先将薪酬表转换为业务对象，当然需求分析人员在获取原始表的同时，需要初步了解表内元素的基本含义，在转换为业务对象时，在相应的备注信息栏中予以说明。针对业务对象分析转换的几条原则的应用，在案例中的体现，可以通过以下说明查看其实施。例如，针对原始薪酬表，邮箱元素是方便向各员工发工资信息，实施信息化只需要登录系统查询即可，因此在业务对象中已经不需要出现；针对原始表中存在的关于级别的信息，每家单位都有类似的按照高中低，或1-10级的规定，因此这里可以衍生出关于岗位级别的基础信息业务对象。

5.划分业务边界

根据业务目标“实现薪酬管理业务信息化”，就可以很容易推导出边界。根据这个业务目标，可以方便得出哪些人对这个业务目标有期望，哪些涉众是被动参与到这个目标的。

6.分析业务角色

结合案例，根据对业务角色的说明，针对“实现薪酬管理业务信息化”的业务边界，得出业务角色视图。

业务角色可以是涉众的细化，例如，涉众财务部，在业务角色部分演化为财务部出纳、财务部主管；业务角色可以衍生，例如，薪酬审核员，就是因为在业务后续业务用例中工资表的审核需要经过多次审核，但是每次审核的内容基本一样，只是人员不一样，所以使用新建业务角色代理涉众中的财务主管、总经理和董事长等，薪酬审核员执行涉众期望。

业务角色的分析和业务用例其实并无先后顺序，它们之间是相互补充、相互依存、相互协助、相互验证的关系，可以经过多次迭代逐步修改和完善。

7.获取业务用例

根据提及到的业务用例视图获取方法，可以得出所示的关于“实现薪酬管理业务信息化”的业务用例视图。

以上的业务用例完整的表达了薪酬管理信息化的主要过程，也反映了当前业务现状的实际情况。经过多次的实践和培训，发现针对建立业务用例视图最常见的错误就是把步骤当用例。例如，上图的处理考勤异常是得出的业务用例，但是初学者容易将其抽取为查看考勤表、填写申诉表等，这样抽取有问题吗？有什么问题？对照对分析业务用例的定义就明白，其实无论查看考勤表还是填写申诉表等只是处理考勤异常的步骤，而非目的，这两个所谓的“用例”经不起推敲和继续提问，当然如果你的目的就是简单的查看考勤信息，那么查看考勤表的用例就可以成立。

8业务场景呈现

主要针对的就是薪酬信息化管理，其中的另一个目标规范化主要起到配合和进行基础数据管理的作用。因此，将薪酬信息化业务用例汇总形成业务场景后得到活动图。可以看出处理异常考勤、制定薪资表、审核薪资、发工资以及处理异常薪资等都是业务用例视图中的业务用例，它们汇总后根据实际业务形成了反映薪酬信息化的具体执行流程。

9业务情景建模

针对案例，将业务用例的审核薪资进行业务情景建模，得到活动图，用以构建和说明审核薪资业务的具体流程。

10分析概念实体

在本案例中，依据上述对概念实体的描述，结合业务对象表格，形成了概念实体关系视图。

11关联系统用户

针对本案例中的用户，结合业务角色关系和对用户的说明，形成了系统用户视图。

12获取系统用例

针对案例上述业务情景的薪酬审核，结合对用例的说明，得到如下图所示的系统用例视图。

查看案例的业务情景活动图可知，其活动都是可以用信息化手段实现，即可以计算机化的，因此系统用例的获取就相对比较简单。而针对另外一个发工资的业务情景，其最后一步即为银行根据薪资表发放工资，简单分析就可知，银行是不会与当前这家公司的薪资系统集成，当分析系统用例时，就可以采用演绎的方法，将其更改为导出薪资表，当然这个薪资表是符合银行格式要求的表单。

13系统模块汇总

针对本案例的业务，形成了系统模块视图。

14系统情景模型

针对薪资管理案例，结合对系统用例的说明，还以薪资审核为例，可以分出三个系统情景：发送薪资表、审核薪资表和修改薪资表。这里就以审核薪资表为例，建立起系统情景模型示。在用户与计算机交互过程中，一般将计算机所要展示的页面、系统的功能按钮、操作的核心实体及其元素、页面校验规则、业务处理逻辑名称约束和规则、应用的业务规则等体现出来。

15构建原型界面

针对案例中，审核薪资的原型界面如下图所示。当然，系统用例并非与原型界面一一对应，一个系统用例可以关联一个或者多个原型界面，主要以完整表达系统活动图所描述的过程为目标。

同时配合原型界面的使用以及为设计人员提供关键元素的需要，每个原型界面都有对应的用例脚本展示，主要以边界类、业务类及实体类的划分为依据，按照mvc的主要思想将设计需的关键要素表达出来。在边界类中主要以固定的form元素、grid元素、button元素、页面验证元素等表现人机交互界面的信息；业务类主要表达busi元素，用于实现业务处理逻辑，业务控制逻辑的业务处理名称信息；实体类主要从概念实体获取和用例原型关联的操作使用到的实体信息等。

案例中审核薪资的用例脚本如所示。在接下来的概要视图中，可以完善信息，作为导入设计工程的基础。

至此，系统建模过程也已经完成，以业务模型为基础，逐步拆分和细化，

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用全部或部分地以计算机程序产品的形式实现，所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输)。所述计算机可读取存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。