CN103530368A - 一种需求数据的分解方法及系统 - Google Patents

Abstract

本发明提供了一种需求数据的分解方法及系统；方法包括：从待分解的需求数据中提取出该条需求数据的需求信息，所述需求信息包括：需求标识、应用人员；根据所述需求标识在预定的系统边界域中提取与该条需求数据相关的一个或多个区域，记录为该条需求数据对应的所属域；将所述应用人员分别与预设的各所属域的使用人员集合进行匹配，将匹配成功的应用人员记录为相应的所属域的应用人员；根据预设的第一对应关系，分别为各所属域的应用人员增加对应于该需求数据的操作。本发明能够对需求数据进行自动高效地分解，并保证分解的准确性和一致性。

Description

一种需求数据的分解方法及系统

技术领域

本发明涉及软件领域，尤其涉及一种需求数据的分解方法及系统。

背景技术

随着大型软件项目的更为复杂化、规模化的现状，目前对软件实现的质量和时间都有了更高要求。但是目前对软件实现的源头——需求分析管理还停留在理论阶段，没有从用户到软件的角度定义映射分解的关系，没有量化需求范围，也没有定义需求分解规则，不利于对系统开发过程进行量化管理，量化评估的原则。目前的需求分解主要依靠软件项目中的相关人员根据自己的理解进行，在较小的项目中这不失为一种切实可行的需求分解方案，但对于庞大的大型企业融合系统，由于需求数据庞大，涉及的区域、人员非常多，按照现有方式进行需求分解的效率将会比较低；而且由于软件项目中相关人员对于需求的理解不一致，有可能导致分解结果差异很大，甚至其中有些分解结果不够准确，无法满足用户需求，以至于要对根据分解结果设计出来的系统进行全面变更，这会造成极大的成本浪费。

发明内容

本发明要解决的技术问题是如何对需求数据进行自动高效地分解，并保证分解的准确性和一致性。

为了解决上述问题，本发明提供了一种需求数据的分解方法，包括：

从待分解的需求数据中提取出该条需求数据的需求信息，所述需求信息包括：需求标识、应用人员；

根据所述需求标识在预定的系统边界域中提取与该条需求数据相关的一个或多个区域，记录为该条需求数据对应的所属域；

将所述应用人员分别与预设的各所属域的使用人员集合进行匹配，将匹配成功的应用人员记录为相应的所属域的应用人员；

根据预设的第一对应关系，分别为各所属域的应用人员增加对应于该需求数据的操作。

可选地，所述的方法还包括：

根据预设的第二对应关系，分别将各应用人员的各操作分解为数据属性元素，所述数据属性元素包括一个或多个数据实体，及各数据实体对应的元素；

进行量化，分别将各操作分解出的数据实体所对应的元素的个数相加，得到该条需求数据对应的操作的功能点的个数。

可选地，所述进行量化的步骤前还包括：

分别将该条需求数据对应的所属域的应用人员对应的操作按照数据实体记录为不同的需求分解项；

合并相同的需求分解项。

可选地，所述系统边界域包括：

各级别的区域；所述级别包括：系统、接口、模块、人机交互等；系统级别的区域作为第一级子节点；模块级别的区域作为相应系统系别的区域下的子节点。

可选地，所述操作的类型包括：

单数据查询、新增、修改、删除、报表查询。

本发明还提供了一种需求数据的分解系统，包括：

提取模块，用于从待分解的需求数据中提取出该条需求数据的需求信息，所述需求信息包括：需求标识、应用人员；

边界划分模块，用于根据所述需求标识在预定的系统边界域中提取与该条需求数据相关的一个或多个区域，记录为该条需求数据对应的所属域；

人员划分模块，用于将所述应用人员分别与预设的各所属域的使用人员集合进行匹配，将匹配成功的应用人员记录为相应的所属域的应用人员；

功能划分模块，用于根据预设的第一对应关系，分别为各所属域的应用人员增加对应于该需求数据的操作。

可选地，所述的系统还包括：

分解模块，用于根据预设的第二对应关系，分别将各应用人员的各操作分解为数据属性元素，所述数据属性元素包括一个或多个数据实体，及各数据实体对应的元素；

量化模块，用于进行量化，分别将各操作分解出的数据实体所对应的元素的个数相加，得到该条需求数据对应的操作的功能点的个数。

可选地，所述量化模块还用于在进行量化前，分别将该条需求数据对应的所属域的应用人员对应的操作按照数据实体记录为不同的需求分解项；合并相同的需求分解项。

可选地，所述系统边界域包括：

各级别的区域；所述级别包括：系统、接口、模块、人机交互等；系统级别的区域作为第一级子节点；模块级别的区域作为相应系统系别的区域下的子节点。

可选地，所述操作的类型包括：

单数据查询、新增、修改、删除、报表查询。

本发明的至少一个实施例形成了统一的需求分解方案，有助于形成标准、规范的软件需求规格数据，可以对需求数据进行自动分解，大大提高了需求分解的效率；并且可以保证需求数据分解的准确性和一致性，能避免软件项目中相关人员因为对于需求理解不一致而造成的成本浪费；本发明的又一个实施例进一步分解出数据实体及元素，结合分解出的操作过程，可围绕两者进行由顶至下横纵分解的过程；另外将分解后的操作转换为具体的功能点个数，从而计算出需求的规模，达到量化的目的。。

附图说明

图1为实施例一的需求数据的分解方法的流程示意图；

图2为实施例一中系统边界域的示意图；

图3为实施例一的例子中的系统边界域的示意图。

具体实施方式

下面将结合附图及实施例对本发明的技术方案进行更详细的说明。

需要说明的是，如果不冲突，本发明实施例以及实施例中的各个特征可以相互结合，均在本发明的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例一、一种需求数据的分解方法，如图1所示，包括：

S101、从待分解的需求数据中提取出各条需求数据的需求信息，所述需求信息包括：需求标识、应用人员；

S102、根据所述需求标识在预定的系统边界域中提取与该条需求数据相关的一个或多个区域，记录为该条需求数据对应的所属域；

S103、将所述应用人员分别与预设的各所属域的使用人员集合进行匹配，将匹配成功的应用人员记录为相应的所属域的应用人员；

S104、根据预设的第一对应关系，分别为各所属域的应用人员增加对应于所述需求标识的操作。

本实施例中，可以但不限于通过TFS（Team Foundation Server，工作流协作引擎）等初步需求获取工具进行需求信息的提取。如果需求数据有多条，则分别对每一条进行上述步骤S101～S104。

本实施例中，各区域是指整个融合系统中的各级系统边界，包括系统级、模块级、接口级等，各区域的集合构成所述系统边界域。各区域的使用人员集合是可能或有权使用本区域的人员，假设区域D11的使用人员集合包括营业员、客服人员、系统管理员，区域D12的使用人员集合包括营业员、营业员班长。如果所属域包括区域D11和D12，拆分得到的需求信息中，应用人员包括营业员、营业员班长、客服人员，则与区域D11匹配成功的是营业员和客服人员，记录为区域D11的应用人员；与区域D12匹配成功的是营业员和营业员班长，记录为区域D12的应用人员。

所述第一对应关系为各区域中各应用人员对应于所述需求标识的操作；比如所属域包括区域D11和D12，则第一对应关系中可包括：

D11中，营业员对应于需求标识A的操作包括单数据查询和新增，客服人员对应于需求标识A的操作包括报表查询；

D12中，营业员对应于需求标识A的操作包括新增；营业员班长对应于需求标识A的操作包括单数据查询。

通过第一对应关系，就可以得到各所属域的应用人员对应于该条需求数据的操作。

本实施例可以将需求数据分解成该需求所涉及的各区域，以及这些区域中与该需求有关的应用人员及他们需要进行的操作。由于采用了统一的系统边界域、使用人员集合及第一对应关系，可保证需求数据分解的效率和质量，使系统分析全面，并且可以统一需求分析标准。

本实施例中，所述使用人员集合可以但不限于为列表形式；所述系统边界域可以但不限于为树形结构。

本实施例中，所述需求信息还可以包括：需求名称、需求内容描述等。

本实施例的一种实施方式中，所述方法还可以包括：

S105、根据预设的第二对应关系，分别将各应用人员的各操作分解为数据属性元素，所述数据属性元素包括一个或多个数据实体，及各数据实体对应的元素；

S106、进行量化，分别将各操作分解出的各数据实体所对应的元素的个数相加，得到该条需求数据对应的各操作的功能点的个数。

所述第二对应关系为各区域中各应用人员的各操作所对应的数据属性元素；比如区域D11中，营业员的新增操作对应于数据属性元素a和b，单数据查询也对应于数据属性元素a和b，客服人员的报表查询操作对应于数据属性元素a；区域D12中，营业员的新增操作则对应于数据属性元素c和d，营业员班长的单数据查询对应于数据属性元素a和d。可见，同一操作，在不同区域中、或对应于不同应用人员时，该操作对应的数据属性元素有可能不同。

本实施例的一种实施方式中，所述系统边界域可以包括：各级别的区域；所述级别包括：系统、接口、模块、人机交互等；系统级别的区域作为第一级子节点；模块级别的区域作为相应系统系别的区域下的子节点。

一个系统边界域D的树形结构如图2所示，系统边界域D{dij，i=0...n,j=0...m}中包括系统D1，系统D2，......，系统Dn等，再识别出系统D1下的模块D11、模块D12、模块D13，系统D2下的模块D21、模块D22、D23模块，......，系统Dn下的模块Dn1、模块Dn2、模块Dn3等，如此建立整个融合系统的边界域。

按照该方法，识别出的边界域可明确具体需求工作明确数据的访问和维护边界，为数据识别和划分提供标准。边界类型可根据需求分析要求，增加界面类别。

本实施例的一种实施方式中，所述各区域的使用人员集合可以预先建立，将实际系统主要业务的使用人员保存在该区域的PepoleList列表中。该列表中还可以划分级别，比如第一级的使用人员包括系统管理员和营业部，营业部中还包括营业员、客服人员等。

本实施例的一种实施方式中，所述操作的类型包括单数据查询、新增、修改、删除、报表查询。在实际应用中还可以根据需要自行增加操作的类型。

单数据查询：识别该需求中需要查询一条数据的功能。

新增：识别该需求中需要在数据库中新增的数据功能。

修改：识别该需求中可以修改数据库中数据的功能。

删除：识别该需求中可以删除数据库中数据的功能。

报表查询：识别该需求中需批量查询的数据功能，该操作需要识别出系统计算不计入数据库中的统计数据的属性值。

本实施例中，建立所述第一对应关系的原则可以包括：

A、对用户有意义，需要站在用户需求的角度上对应需求管理。B、该基本过程属于查询、增加、修改、删除、输出（统计报表类）。C、自包含，数据处理唯一性，不可重复分解。D、使应用的业务保持持续状态，该基本过程属于在系统内持续使用的基本功能。

本实施例的一种实施方式中，所述进行量化的步骤前还可以包括：

分别将该条需求数据对应的所属域的应用人员对应的操作按照数据实体记录为不同的需求分解项；

合并相同的需求分解项。

本实施例中，还可以为每一条需求分解项添加唯一标识，一条需求分解项包含需求标识、区域、应用人员、操作、数据实体、元素。

本实施例的一种实施方式中，所述将各操作分解为数据属性元素的步骤具体可以包括：

针对每一个操作，首先识别出系统范围内所有逻辑相关且用户可识别的数据实体；判断所识别出的各数据实体在系统域内本系统度量维护的元素和本系统引用其他系统维护的元素。

本实施例中，当升级系统时，如果是数据新增功能，则与已有的元素进行对比，对于新增字段的要按照新增后的元素的个数进行计算。

如果是数据新增处理功能，比如对已有的功能模块新增功能，包括新的流程或者新的功能，则先把该新增的功能和操作类、查询类、统计类建立映射关系。分别计算该基本过程的穿越定义界面的元素个数，进行计数，维护了基本元素数据表的个数和访问接口的个数。

作为升级项目，如果没有新增数据元素，则无数据新增，反之，按照新建项目规则进行需求数据功能分析。事务新增按修改后维护的数据元素与原有功能进行对比。

本实施例可适用于一切企业管理系统，包含单一系统、升级系统、融合系统。下面以融合系统中开户需求数据的分解为例进一步说明本实施例。该例子中，需求数据的分解包括步骤S201～S207。

S201：通过TFS（工作流协作的引擎）获取开户需求的初始信息集Ur，其中包括多条需求数据，每条需求数据包括：需求标识（本例子中为X101）、需求名称（本例子中为用户开户）、需求内容描述（本例子中为在电子化销售服务管理系统中实现对公众客户的用户号码开户，主要包括用户选号、新建用户属性、产品查询、用户选产品等）、应用人员（本例子中为营业员、客服人员）。

S202：构建系统边界域。大型系统由于信息交互、处理、维护等需求，需要划分多个模块、多个接口，同时需要获取已建立的系统信息，并且融合多个系统；对于融合系统，需要构建系统边界。

本例子中划分出各级别的区域：

系统级：包括ESS（电子化销售服务管理系统）、BSS（业务支撑系统）、B-SDM系统（统一用户数据管理平台）、集中采集系统、维挽系统等；

模块级：包括营业受理、积分管理、缴费管理、用户管理、客户管理等；

接口级：包括ESS与BSS的接口、ESS与IOM（集成定单管理系统）的接口等。

根据以上区域建立如图3所示的系统边界树：以融合系统D为根节点，电子销售服务系统、营帐系统、统一用户数据管理系统、集中采集系统、维挽系统作为该根节点的子节点，营业受理模块、积分管理模块、缴费管理模块、用户管理模块、客户管理模块作为电子销售服务系统分支下的子节点；其它各系统下属的模块也作为相应系统的子节点，这里不再赘述。

S203：构建各区域的使用人员集合（PeopleList），根据系统的使用人员构建基础信息PeopleList队列。如PeopleList（系统管理员、市场部、信息化部、电子渠道管理部、法律与风险部、客服中心、数据中心），在PeopleList部门级下逐一构建使用人员序列（比如本例子中是在市场部下构建使用人员序列：营业员、营业班长、营业经理）。

S204：构建系统操作属性信息：该例子中划分为五种操作类型，包括：查询、新增、修改、删除、报表查询。

该操作在技术实现上采用灵活地增量增加，便于根据实际情况增加操作类型。

S205：对初始信息集Ur中的需求数据逐条分解，将分解结果保存进分解域L中；具体包括步骤A～F。

步骤A：将初始信息集Ur中的一条需求数据输入到分解域L中，该条需求数据如下表所示。

表1、需求数据

步骤B：对该条需求数据，首先遍历系统边界树，对于每条系统分支，遍历到该分支的末端子节点，提取与该条需求数据相关的子节点对应的区域，将提取出的区域增加到分解域L中该条需求数据对应的记录中，作为该条需求数据所属的域；该条需求数据对应的区域如下表所示。

表2、需求数据对应的区域

需求标识	需求名称	所属域
			X101	用户开户	D11
X101	用户开户	D12
			X101	用户开户	D2

步骤C：将分解域L中记录的该条需求数据中的应用人员与PeopleList中的使用人员进行匹配，将匹配成功的应用人员记录到分解域L中该条需求数据对应的记录中。若在PeopleList中未能查到可匹配成功的应用人员，则报提示，从而更新PeopleList。该条需求数据对应的应用人员如下表所示。

表3、需求数据对应的应用人员

用户需求标识	用户需求名称	所属域	应用人员
				X101	开户	D11	营业员
X101	开户	D11	客服人员
				X101	开户	D11	系统管理员
X101	开户	D12	营业员
				X101	开户	D12	营业员班长
X101	开户	D2	服务开通人员

步骤D：对该条需求数据遍历五个操作类型。根据预存的第一对应关系，得到各区域中各应用人员对应于该条需求数据的操作；将各区域中各应用人员对应于该条需求数据的操作加入分解域L中该条需求数据对应的记录里，得到下表。

表4、需求数据对应的操作

需求名称	所属域	应用人员	操作
				开户	D11	营业员	单数据查询
开户	D11	营业员	新增
				开户	D11	客服人员	报表查询
开户	D11	系统管理员	修改
				开户	D12	营业员	新增
开户	D12	营业员班长	单数据查询
				开户	D2	服务开通人员	新增
开户	D2	服务开通人员	修改

步骤E：针对分解域L中该条需求数据对应的每个操作进行分解，得到其数据属性元素，包括数据实体及各数据实体对应的元素，如下表所示。其中每一行作为一条需求分解项。对每条操作的数据属性元素循环识别，在分解域L中对元素的集合单独分配内存进行记录。最终并入分解域L中。

表5、需求数据对应的操作及其数据属性元素

步骤F：合并分解域L中相同的需求分解项，确定分解域L中没有重复的需求分解项，分解域L中每新增数据都要与已有数据比对，如果与其他数据相同，则剔除，以保留分解域L中需求分解项的唯一性，即，上表中每一行的各列内容不会与另外一行完全相同。

为分解域L中的每一条需求分解项分配唯一操作编码。最后形成的分解域L如下表所示。

表6、需求数据对应的操作及其数据属性元素

S206：量化需求分解域L中各需求分解项，将元素个数作为需求分解项的需求量化值；并将量化后的数值加入分解域L中各需求分解项对应的记录中，如下表所示（表7中的前6列以“......”表示，内容同表6）。

表7、加入量化数值后的分解域L

......	操作编码	需求量化值
			......	20000	5
......	20001	6
			......	20002	5
......	20003	6
			......	20004	5
......	20005	5
			......	20006	4
......	20007	4
			......	20008	5
......	20009	4
			......	20010	5
......	20011	3
			......	20012	3

还可以分别将各操作分解出的各数据实体所对应的元素的个数相加，得到该条需求数据对应的各操作的功能点的个数。

这里可看成是将系统内部访问维护的数据实体所对应的元素的个数，加上访问系统边界外的数据实体所对应的元素的个数，得到该条需求数据各操作的功能点个数。其中，需在该系统内维护的属于系统内部访问维护的数据实体，只被外界访问不维护的是系统边界外的数据实体，就是被其他系统所引用的；具体如何划分可以预先限定。

比如对于“新增”这个操作，就是将操作编码为20002、20003、20006、20007、20010、20011的需求分解项的元素个数相加，即：5+6+4+4+5+3=27；27就是该条需求数据中，“新增”操作的功能点个数。

实施例二、一种需求数据的分解系统，包括：

提取模块，用于从待分解的需求数据中提取出该条需求数据的需求信息，所述需求信息包括：需求标识、应用人员；

边界划分模块，用于根据所述需求标识在预定的系统边界域中提取与该条需求数据相关的一个或多个区域，记录为该条需求数据对应的所属域；

人员划分模块，用于将所述应用人员分别与预设的各所属域的使用人员集合进行匹配，将匹配成功的应用人员记录为相应的所属域的应用人员；

功能划分模块，用于根据预设的第一对应关系，分别为各所属域的应用人员增加对应于该需求数据的操作。

本实施例的一种实施方式中，所述系统还可以包括：

分解模块，用于根据预设的第二对应关系，分别将各应用人员的各操作分解为数据属性元素，所述数据属性元素包括一个或多个数据实体，及各数据实体对应的元素；

量化模块，用于进行量化，分别将各操作分解出的数据实体所对应的元素的个数相加，得到该条需求数据对应的操作的功能点的个数。

本实施例的一种实施方式中，所述量化模块还可以用于在进行量化前，分别将该条需求数据对应的所属域的应用人员对应的操作按照数据实体记录为不同的需求分解项；合并相同的需求分解项。

本实施例的一种实施方式中，所述系统边界域具体可以包括：

各级别的区域；所述级别包括：系统、接口、模块、人机交互等；系统级别的区域作为第一级子节点；模块级别的区域作为相应系统系别的区域下的子节点。

本实施例的一种实施方式中，所述操作的类型具体可以包括：

单数据查询、新增、修改、删除、报表查询。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明的权利要求的保护范围。

Claims (10)

1.一种需求数据的分解方法，包括：

从待分解的需求数据中提取出该条需求数据的需求信息，所述需求信息包括：需求标识、应用人员；

根据所述需求标识在预定的系统边界域中提取与该条需求数据相关的一个或多个区域，记录为该条需求数据对应的所属域；

将所述应用人员分别与预设的各所属域的使用人员集合进行匹配，将匹配成功的应用人员记录为相应的所属域的应用人员；

根据预设的第一对应关系，分别为各所属域的应用人员增加对应于该需求数据的操作。

2.如权利要求1所述的方法，其特征在于，还包括：

根据预设的第二对应关系，分别将各应用人员的各操作分解为数据属性元素，所述数据属性元素包括一个或多个数据实体，及各数据实体对应的元素；

进行量化，分别将各操作分解出的数据实体所对应的元素的个数相加，得到该条需求数据对应的操作的功能点的个数。

3.如权利要求2所述的方法，其特征在于，所述进行量化的步骤前还包括：

分别将该条需求数据对应的所属域的应用人员对应的操作按照数据实体记录为不同的需求分解项；

合并相同的需求分解项。

4.如权利要求1所述的方法，其特征在于，所述系统边界域包括：

各级别的区域；所述级别包括：系统、接口、模块、人机交互等；系统级别的区域作为第一级子节点；模块级别的区域作为相应系统系别的区域下的子节点。

5.如权利要求1所述的方法，其特征在于，所述操作的类型包括：

单数据查询、新增、修改、删除、报表查询。

6.一种需求数据的分解系统，其特征在于，包括：

提取模块，用于从待分解的需求数据中提取出该条需求数据的需求信息，所述需求信息包括：需求标识、应用人员；

边界划分模块，用于根据所述需求标识在预定的系统边界域中提取与该条需求数据相关的一个或多个区域，记录为该条需求数据对应的所属域；

人员划分模块，用于将所述应用人员分别与预设的各所属域的使用人员集合进行匹配，将匹配成功的应用人员记录为相应的所属域的应用人员；

功能划分模块，用于根据预设的第一对应关系，分别为各所属域的应用人员增加对应于该需求数据的操作。

7.如权利要求6所述的系统，其特征在于，还包括：

分解模块，用于根据预设的第二对应关系，分别将各应用人员的各操作分解为数据属性元素，所述数据属性元素包括一个或多个数据实体，及各数据实体对应的元素；

量化模块，用于进行量化，分别将各操作分解出的数据实体所对应的元素的个数相加，得到该条需求数据对应的操作的功能点的个数。

8.如权利要求7所述的系统，其特征在于：

所述量化模块还用于在进行量化前，分别将该条需求数据对应的所属域的应用人员对应的操作按照数据实体记录为不同的需求分解项；合并相同的需求分解项。

9.如权利要求6所述的系统，其特征在于，所述系统边界域包括：

各级别的区域；所述级别包括：系统、接口、模块、人机交互等；系统级别的区域作为第一级子节点；模块级别的区域作为相应系统系别的区域下的子节点。

10.如权利要求6所述的系统，其特征在于，所述操作的类型包括：

单数据查询、新增、修改、删除、报表查询。

Images