CN116719510B - 用于软件开发中需求建模的产品建模系统 - Google Patents

Abstract

本发明提供了一种用于软件开发中需求建模的产品建模系统，所述产品建模系统包括：产品信息收集模块，收集企业各产品的产品信息；产品分类结构设定模块，对行业实践的产品目录按产品线、产品组、基础产品、可售产品四层结构进行分类；产品特征定义模块，对各可售产品的特征进行定义；产品组件定义模块，对产品特征进行合并或拆分，并将特征转换为产品组件，对产品组件进行定义；产品实例化模块，对每个可售产品进行实例化。本发明的方案从产品的业务处理流程方面，同时参考同业经验，对收集的专业类信息进行聚类分析，对每个可售产品进行实例化。可以校验产品组件、产品条件和条件取值等的完整性，也是未来产品工厂建设中实际数据的重要来源。

Description

用于软件开发中需求建模的产品建模系统

技术领域

本发明涉及软件开发技术领域，特别是一种用于软件开发中需求建模的产品建模系统。

背景技术

随着金融科技的高速发展，银行的数字化转型，银行的客户细分市场出现了巨大的变化，客户呈现爆发式的增长，而且未来银行的核心竞争力关键在于数字化场景金融服务的能力，任何一个场景生态的建设，最终都需要依托银行产品来实现对客户的价值交付。个性化、差异化、定制化产品和服务开发能力，是银行业未来发展的重要目标之一。

在过去，开发新产品是由产品经理将产品形态、服务流程、价格等要素特征进行描述，由IT部门开发后进行投产。但这种模式未能考虑到不同产品的条款，定价方式、服务流程等产品特征所具有的相似性，必然导致IT部门开发的重复投入。因此，如果将产品进行标准化，就能将一系列相似的产品功能在未来开发时进行高程度的复用，大量减少IT开发的成本，通过少量的参数配置即可快速上线新产品，是产品工厂快速灵活装配的运行模式和主要目标。而且原有的产品创新模式多以管理条线部门为单位，缺乏企业级的组织管理与调度机制。

目前产品创新呈现出周期短、组合性、场景化、定制化等特点，而目前的模式难以满足，主要表现为：

1、缺乏企业级创新组织管理：传统银行的产品创新模式往往是以单一条线或部门为单位的累进型创新，关注客户单一表象需求，缺乏对深层次需求的整合与洞察。难以实现以客户为中心的产品创新。而且缺乏企业级的资源集中调度和评估机制、导致跨部门的相似产品的复用度考量不足而重复开发建设。

2、创新周期长：由于基于部门视角考虑创新，已经具备的创新能力难以跨部门利用，重新开发一个可售产品从创新发现、研发到面市，通常需要经历数月以上的周期，难以快速推向和占领市场。

3、需求评估难，开发不合理：在推出新产品时，缺乏产品价值和未来效益的度量标准，更难有特色有价值的竞争力评估，导致新产品被重复开发、不合理开发，许多新产品在面市后产生的收益与开发成本相比，未能实现收益最大化。

4、缺乏完整的产品创新工艺流程、以及统一模型和语言：业务人员和技术人员的衔接没有完整可承接、易操作的全套工艺流程，也不能基于形象的模型交流、语言不统一，双方缺乏能快速理解并达成共识的一种工作方式，这就使得需求提出和需求实现出现较大偏差。

发明内容

鉴于上述问题，本发明提出一种克服上述问题或者至少部分地解决上述问题的用于软件开发中需求建模的产品建模系统。

本发明的一种用于软件开发中需求建模的产品建模系统，所述产品建模系统包括：

产品信息收集模块，收集企业各产品的产品信息，具体包括收集可售产品清单、收集产品相关文件、收集产品基本信息、确认产品核算信息、收集产品专业信息、识别产品特征；

产品分类结构设定模块，对行业实践的产品目录按产品线、产品组、基础产品、可售产品四层结构进行分类；

产品特征定义模块，对各可售产品的特征进行定义；

产品组件定义模块，对产品特征进行合并或拆分，并将特征转换为产品组件，对产品组件进行定义；

产品实例化模块，对每个可售产品进行实例化。

可选地，所述产品信息收集模块收集可售产品清单包括：

确定企业各业务对应的业务线条，基于各线条业务收集对应的第一可售产品；

导出数据库表的产品目录中存储的第二可售产品；

核对第一可售产品和第二可售产品，生成可售产品清单。

可选地，所述产品信息收集模块收集的产品相关文件包括：收集可售产品清单中各可售产品关联的产品说明书、产品模板、产品协议模板、产品需求规格说明书。

可选地，所述产品信息收集模块收集的产品基本信息包括：产品描述信息、产品关系人信息、产品市场信息、产品分类信息、产品经营条件信息。

可选地，所述产品信息收集模块收集产品专业信息包括：根据每条业务线的专业特点，从业务特征、业务条件、计息要求及收费条件三方面，对专业信息进行收集。

可选地，所述产品特征定义模块具体用于：

提炼产品特征，将初步识别的特征，按划分的产品组进行归纳提炼；

识别备选条件，在特征下识别可能存在的产品条件，作为产品条件的备选；

确认产品条件，对识别的备选产品条件进行确认，同时对产品属性和产品关系信息进行确认；

检查完整性，检查产品条件，确认产品条件的完整性。

可选地，所述产品特征定义模块提炼产品特征包括：

根据识别产品特征中的特征与可售产品关系以及产品分类结构，将产品特征按产品组进行归纳；

对归纳后的产品特征，按基础产品作为一级，可售产品作为二级的形式，重新与特征建立关联关系。

本发明主要应用于金融科技领域的需求分析阶段的产品创新环节，企业为了快速响应客户需求，实现价值交付，必须依托于企业的产品及服务创新，随着金融科技的发展，客户对品类全、推荐准、服务好、效率高的产品及服务诉求也越来越强烈。那么企业具备个性化、差异化、定制化产品及服务能力的重要性就体现出来了，为此，本发明以企业级工艺方法为指导，梳理产品结构，最终得到产品模型，在本发明中被称为产品建模，来实现产品的灵活配置以及快速交付。

本发明通过产品建模，从企业整体视角形成产品分类结构、产品组件和产品条件。产品工厂对产品的各种条件、规则等信息预先进行参数化定义，并按照其功能或者特定服务进行组件化封装的基础上，根据客户需求进行配置的一种创新。

本发明中的产品建模是一个以企业级工艺方法论为指导，对产品进行梳理，最终得到产品模型的过程，其梳理的产品分类结构（包括产品线、产品组、基础产品和可售产品在内的产品目录）有利于定位和初分产品需求，产品组件、产品条件、产品条件取值有利于展示和甄别不同产品的具体差异。对于大部分产品创新需求而言，业务人员以基础产品为创新模版，通过确定要选择的产品条件和条件取值，就可以快速装配一个新的可售产品，在IT方面不需开发，仅需测试和配置。只有少量的需求才需要开发装配新的组件、条件及其参数。产品工厂对产品创新提供端对端、一体化的解决方案，产品参数进行分类管理和统一维护。

本发明中，采用“工艺方法论+工艺工具”的方式来解决背景技术问题，工艺包括需求建模（R）、分析建模（A）、设计建模（D）、实现建模（C）四个阶段，简称雷达客（RADC）工艺，在需求建模阶段，设计梳理业务架构，标准化描述业务需求。产品建模可以基于业务架构开展，以企业级方法论为指导，梳理产品结构，最终得到产品模型，工具承接RADC工艺方法论，进一步将其思想使用工具进行体现，命名为RADC工艺平台-产品建模。本发明的业务架构可以包括业务领域、业务组件、干系人、业务对象。业务领域：关于服务客户，从业务服务流程视角来实现客户诉求、创造价值和收入来源；需要利用业务组件的内部能力。业务组件：关注于内部能力，从降本增效的视角来考量提高复用度、创新能力、办理效率，以节省成本；需要服务于业务领域，同时集成整合一组业务对象的所提供的更小粒度的能力。业务对象：是较小粒度的、具有相似性的一组业务资源的集合，通常被业务组件的一组流程所串接形成可交付给客户的能力，在发明实施例中，业务对象是更小粒度的行为能力、被包含与业务组件中。业务领域是满足客户诉求的一种外部能力体现，而业务组件是企业具备的内部能力，业务对象反应业务本质，是业务的核心资源，其三者直接的关系是业务领域利用业务组件，业务组件负责业务对象。可选地，所述业务对象是企业业务的核心资源，是资源的结构化体现，用于指导应用系统落地时，用户执行用例相关操作时，所创建、存取和更新、删除等的一组业务概念；所述业务组件为关联各所述业务对象的功能组件；所述业务领域为所述目标企业为客户和企业内部提供的需求服务，体现企业的高阶价值需求以及整体价值创造过程。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明的产品建模系统示意图；

图2为本发明的产品信息架构示意图；

图3为本发明的产品分类结构示意图；

图4为本发明中的收集可售产品清单的界面示意图；

图5为本发明中的收集可售产品清单交付物示例的示意图；

图6为本发明中的收集产品相关文件的界面示意图；

图7为本发明中的收集产品相关文件交付物的示意图；

图8为本发明中的收集基本信息的界面示意图；

图9为本发明中的收集基本信息交付物的示意图；

图10为本发明中的确认核算信息的界面示意图；

图11为本发明中的确认核算信息交付物的示意图；

图12为本发明中的收集专业类信息的界面示意图；

图13为本发明中的收集专业类信息交付物的示意图；

图14为本发明中的识别产品特征的界面示意图；

图15为本发明中的识别产品特征交付物的示意图；

图16为本发明中的预设产品分类结构的界面示意图；

图17为本发明中的预设产品分类结构交付物的示意图；

图18为本发明中的定义产品特征/条件的界面示意图；

图19为本发明中的定义产品特征/条件交付物的示意图；

图20为本发明中的识别备选条件的界面示意图；

图21为本发明中的识别备选条件交付物的示意图；

图22为本发明中的确认产品条件的界面示意图；

图23为本发明中的确认产品条件交付物的示意图；

图24为本发明中的检查完整性的界面示意图；

图25为本发明中的检查完整性交付物的示意图；

图26为本发明中的优化产品特征的界面示意图；

图27为本发明中的优化产品特征交付物的示意图；

图28为本发明中的定义产品组件的示意图；

图29为本发明中的定义产品组件交付物的示意图；

图30为本发明中的产品组件与基础产品映射的界面示意图；

图31为本发明中的产品组件与基础产品映射交付物的示意图；

图32为本发明中的产品实例化的界面示意图；

图33为本发明中的产品实例化交付物的示意图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

产品模型是基于特定的要求约束，以结构化、抽象化的方式展现企业产品的一种业务模型，它包含清晰的产品结构，标准化的模型结构以及全面的产品信息。本发明实施例提供了一种用于软件开发中需求建模的产品建模系统，结合图1，本实施例的产品建模系统包括：产品信息收集模块、产品分类结构设定模块、产品特征定义模块、产品组件定义模块和产品实例化模块。产品，可以理解为企业（如银行）向客户提供的商品，包括有形的物品和无形的服务，其中伴随着数据信息的产生、存储。

产品信息收集模块，收集企业各产品的产品信息，具体包括收集可售产品清单、收集产品相关文件、收集产品基本信息、确认产品核算信息、收集产品专业信息、识别产品特征。全面的产品信息是按照标准化、结构化的方式，描述产品的组成要素及其取值，确保产品数据的质量。如图2所示，产品信息包含：产品条件、产品属性、产品关系。产品条件：为了确定不同产品的业务规则和限制。产品条件应该具有可协商性、是一种限制、制约和限定、具备完善的可以用于描述产品特征的取值。产品属性：表示产品本身的固有属性，例如产品名称、产品描述、产品生命周期、产品分类等。产品关系：产品关系是维持产品模型可正常运转必须与之交互的、须依赖于外部事先配置的参数、模型等，如产品与费用的关系、产品与利率的关系等。

产品分类结构设定模块，对行业实践的产品目录按产品线、产品组、基础产品、可售产品四层结构进行分类。如图3所示，产品分类结构主要包括四个层级，即产品线、产品组、基础产品、可售产品。在未来的业务构架中，产品是通过产品服务流程销售，提供给客户的，其中伴随着数据信息的产生、存储，因此，产品分类结构要与流程、数据的分类对应一致。预设产品分类结构可以实现对高阶产品目录进行自上而下地（从产品线到可售产品）优化；可以基于分类结构中的基础产品更快地实现新产品创新。本实施例产品分类结构均分为四个层级，即产品线、产品组、基础产品、可售产品。产品线：独立于组织结构、客户细分或某一具体渠道，对于产品大类的划分。产品组：在产品线下按产品功能或特征进行分类，通常按应用对产品进行分组，便于管理与维护；一个产品线可以包含多个产品组，但每个产品组在产品目录中都是唯一的，不存在交集。基础产品：基础产品是一种抽象化、用于支持创新的产品，由一组具有相似功能和业务处理逻辑规则的可售产品聚类而成。可售产品：银行独立对外进行销售和经营的产品，通常也独立进行管理。

而本实施例中，基础产品可理解为基础产品模板，而可售产品即传统产品分类结构中的基础产品，在产品实例化时，会对一些具有代表性的产品进行实例化，以验证产品条件的取值正确性，在本发明中，该阶段主要做产品结构的梳理，以产生基础产品，同步至产品工厂，进行产品的装备，即对产品进行参数化配置，最终在销售工厂上架对外销售。

产品特征定义模块，对各可售产品的特征进行定义。产品特征：可以支持产品相关业务运营，可以满足外部客户、内部管理及外部监管要求。产品特征应从外部视角进行提炼，从外部视角审视可售产品所提供的范围；产品特征必须至少有一个产品条件存在。

产品组件定义模块，对产品特征进行合并或拆分，并将特征转换为产品组件，对产品组件进行定义。实现更加轻松地定义和配置新产品，并生成新产品手册以供客户进行比较和选择。产品组件：由企业提供给客户的无法单独销售、需被包含在可售产品里一起进行销售，产品组件是由一组产品条件组成。

在传统的产品建模方式中，产品组件往往是由产品经理根据经验去定义的，而在本发明中注重推导过程，逐步推导出产品组件，那么推导的过程是，基于收集的可售产品，从产品的业务处理流程方面，同时参考同业经验，对收集的专业类信息进行聚类分析，识别出产品全生命周期中为满足客户诉求而需要的功能，即产品特征，然后，根据已识别的产品特征清单，结合现有资料，按产品组提炼和归纳产品特征。并且基于既定的原则对产品特征进行优化，识别出备选产品组件，最终在充分理解与决策考虑事项，对产品特征进行最后优化后，定义为产品组件。

产品实例化模块，对每个可售产品进行实例化。不仅可以校验产品组件、产品条件和条件取值等的完整性，也是未来产品工厂建设中实际数据的重要来源。下面分别对产品建模系统各模块执行工艺流程进行详细说明。

一、收集产品信息

基于业务制度、产品说明书以及同业务部门多方沟通等输入，收集各产品的通用类、专业类信息，在各产品线下聚类各产品特征，为后续识别产品条件提供基础。通过产品属性的收集，可达三个目的：1）获取全面的可售产品有关信息要素，识别备选产品特征；2）通过产品特征初步识别，进一步优化基础产品；3）为可售产品的定义提供证据。

工序1.1：收集可售产品清单

（1）工艺方法

将本次范围内的所有可售产品收集在一起，形成一个覆盖所有可售产品的可售产品清单。操作方法如下：

a、根据目前业务条线分工，每个业务条线从业务上收集自己负责的可售产品，作为第一可售产品；

b、通过技术手段，导出数据库表中保存的可售产品，作为第二可售产品；

c、核对分别从技术和业务收集的第一可售产品和第二可售产品，保证可售产品完整。

原则：a、所有的可售产品都要覆盖，包括在售的、已停售的、待售的等；b、各业务条线收集自己的可售产品，对应科技条线收集对应技术的可售产品；

（2）工艺工具

基于现有产品目录和当前生产数据，以及各业务部门收集的可售产品，多方输入形成本次项目范围的所有可售产品的清单，为后续收集产品信息提供基础。如图4所示。

（3）交付物示例，如图5所示。

工序1.2：收集产品相关文件

（1）工艺方法

将可售产品清单中，所有可售产品涉及的产品说明书、产品模板、产品协议模板、产品需求规格说明书，以及相关规章制度、法律法规等，所有关联文件收集在一起。

操作方法：a、参考产品生命周期中,所有涉及的相关产品说明书、产品模板、产品协议等与客户相关的文件；b、行内对产品的相关管理条例、规则制度、合规文件等；c、行内对该产品的市场规划、营销策略、营销宣传等；d、外部监管机构对相关产品的法律法规、政策制度及相关规定等；e、内部会计部门对相应产品的会计核算等。

原则：产品相关文件的收集，应遵循尽可能全的原则，将所有涉及该产品线产品的文件，都进行收集；

（2）工艺工具

根据已形成的可售产品清单作为当前信息收集的范围，汇集产品相关文件，如产品宣传手册、产品使用手册、产品设计手册、产品规章制度、产品合约模板、产品监管文件等。如图6所示。

（3）交付物示例，如图7所示。

工序1.3：收集基本信息

（1）工艺方法

将可售产品清单中，所有可售产品涉及的产品描述信息、产品关系人信息、产品市场信息、产品分类信息、产品经营条件信息等，以结构化的方式进行收集。

操作方法：a、收集产品描述、产品关系人信息；b、收集产品市场、产品分类信息；c、收集产品经营条件信息。

原则：a、基本信息是通用的，所有产品线都需要收集；b、原则上每项信息都要填写，除非实际情况不涉及。

（2）工艺工具

根据已形成的可售产品清单及汇集的产品相关文件，按照产品线提取潜在的产品基本信息，主要包括产品描述信息、产品关系信息、产品市场信息、产品分类信息和产品经营条件等。如图8所示。

（3）交付物示例，如图9所示。

工序1.4：确认核算信息

（1）工艺方法

将可售产品清单中，所有可售产品涉及的产品核算信息进行收集和确认。

操作方法：a、确认本行是否将会计核算分离；b、确认产品核算信息（会计核算分离的情况下）；c、确认产品会计信息。

原则：a、确认产品核算信息主要针对产品本金的核算；

（2）工艺工具

根据已提取的产品信息（主要是产品收入模式信息），确认产品核算信息。如图10所示。

（3）交付物示例，如图11所示。

工序1.5：收集专业类信息

（1）工艺方法

根据每条业务线的专业特点，从业务特征、业务条件、计息要求及收费条件三方面，对专业信息进行收集。

操作方法：a、先针对每个产品线的特点，从业务特征、业务条件、计息要求及收费条件三方面考虑，每个方面有哪些专业的关键点，能表达出该产品线专业特点；b、对相关信息项每一点信息进行收集。比如存款产品线，业务特征包括存款资金来源、存款资金用途、存款性质，业务条件包括产品操作介质、产品支付限制、存入方式、支取方式等，产品计息要求及收费条件包括是否计息、计息金额模式、产品利率类型等信息，然后再逐一收集其信息，如，存款资金来源有营收所得等，产品操作介质有存折、银行卡、票据等，计息金额模式有账户余额、平均余额、明细余额等，根据收集的详细信息，进行填写。

原则：a、原则上每条业务线都有自己专业特点，需要针对每条产品线制定需要收集的信息项；b、专业信息的颗粒度不易太细，到关键信息即可。

（2）工艺工具

在收集通用产品信息的基础上，根据业务领域不同的专业性和该产品的卖点，以及提供给客户的功能等，收集该领域专业的产品信息，主要包括产品业务特征、产品业务条件、产品计息及收费条件等。如图12所示。

（3）交付物示例，如图13所示。

工序1.6：识别产品特征

（1）工艺方法

对每条产品线具备的特征进行初步识别。

操作方法：a、根据产品线初步识别该产品线下具备哪些特征；如可以从产品的卖点、专业性以及功能上，对产品特征进行初步识别。即从产品的外部表现，如外观不一致、可以定制卡面；内部功能，如具备签约、存入、支取功能；内部监管需要，如法院查冻扣等。b、在产品线下，对每个可售产品进行分析，分别涉及哪些特征。

原则：a、每个特征最少有一个可售产品进行关联；b、不考虑颗粒度问题；c、不考虑是否有对应代码实现问题；

（2）工艺工具

从产品的业务处理流程方面，同时参考同业经验，对收集的专业类信息进行聚类分析，识别出产品全生命周期中为满足客户诉求而需要的功能，即产品特征。如图14所示。

（3）交付物示例，如图15所示。

二、2.预设产品分类结构

工序2.1：预设产品分类结构

（1）工艺方法

对行内的产品目录，按产品线、产品组、基础产品、可售产品四层结构，进行分类。

操作方法：a、从高阶上对产品线划分产品组；b、对产品组划分基础产品；c、将可售产品规到对应的基础产品。

原则：a、需要将所有产品按产品线、产品组、基础产品、可售产品的四层结构进行划分；b、在每层结构内，每个产品目录层级名称都是唯一的，不存在交集。

（2）工艺工具

基于行业实践、现状的产品目录、业务条线及业务领域划分参考、可售产品聚类分析，进行产品分类结构预设。并参考业务制度，使用业务术语从目的、定义、范围三个方面对各分类结构加以描述。预设分类结构时，需考虑现有产品管理分工，满足业绩考核、风险管控、资产负债管理、综合统计的要求。如图16所示。

（3）交付物示例，如图17所示。

三、3.定义产品特征/条件

工序3.1：提炼产品特征

（1）工艺方法

将初步识别的特征，按划分的产品组进行归纳提炼。

操作方法：a、根据识别产品特征中，特征与可售产品关系以及产品分类结构，将产品特征按产品组进行归纳；b、对归纳后的产品特征，按基础产品作为一级，可售产品作为二级的形式，重新与特征建立关联关系；

具体操作过程：1）根据可售产品识别出产品特征，并选择该可售产品具备的产品特征；2）在提炼产品特征工序中，将产品特征按产品组进行归纳；3）在预设产品分类结构工序中，在产品组下选择基础产品，将可售产品归纳至基础产品；

原则：a、不考虑产品特征的颗粒度；b、如果同一个特征，在不同产品组都涉及，则需要在不同产品组中都体现该特征。

（2）工艺工具

根据已识别的产品特征清单，结合现有资料，按产品组提炼和归纳产品特征。提炼归纳时，需遵循以下原则：1)、产品特征应从外部视角进行提炼，从外部视角审视可售产品所提供的服务范围；2)、产品特征应至少要有一个产品条件。如图18所示。

（3）交付物示例，如图19所示。

工序3.2：识别备选条件

（1）工艺方法

在特征下识别可能存在的产品条件，作为产品条件的备选。

操作方法：a、分别对每个产品特征下的业务规则，判断是否是引起变化的可变要素，作为产品条件的备选；b、备选条件识别后，反向检查之前识别的特征是否准确。

原则：a、备选条件可以支持和解释产品特征具备的功能和业务目的；b、引起业务规则变化的可变要素，都可以作为备选条件；c、尽可能全的识别备选产品条件。

（2）工艺工具

考察提炼产品特征时所应用的可变要素、业务规则、以及当时的某些考虑因素，将满足这类要求的可变要素识别为备选条件。如图20所示。

（3）交付物示例，如图21所示。

工序3.3：确认产品条件

（1）工艺方法

对识别的备选产品条件进行确认，同时对产品属性和产品关系信息进行确认。

操作方法：a、根据产品条件的定义对每个产品条件进行确认；b、对收集的信息识别产品属性；c、对本来属于产品条件,但相关内容独立形成模型或参数的,识别为关系。

原则：a、需要针对产品条件的定义一一进行确认；b、只有固有信息,不引起逻辑规则判断变化的,才作为属性；c、产品关系是一种特殊的产品条件，只是将相关的业务规则独立形成模型或参数。

（2）工艺工具

对备选条件进行分析，如果符合产品特征，且满足产品条件既定原则，则可确认为产品条件。确认产品条件的既定原则如下：1）可协商：从业务现状及未来可扩展性考虑，可以协商不同取值；2）某种约束、限制和规则：影响业务逻辑分支；3）具备有意义的取值。如图22所示。

（3）交付物示例，如图23所示。

工序3.4：检查完整性

（1）工艺方法

检查产品条件，确认产品条件的完整性。

操作方法：a、对产品条件的目的进行检查，是否明确；b、对产品条件的命名进行检查，是否清晰；c、对产品特征内产品条件间的交叉性进行检查，是否互相有交叉；d、对产品特征间产品条件是否存在多个特征共用进行检查，是否存在共用；e、对条件是否对产品的依赖进行检查，是否存在依赖。

原则：a、从多个维度检查产品条件，确保产品条件的准确、清晰、完整；

（2）工艺工具

通过以下几个方面对产品条件进行检查和优化：1）澄清目的：对于标志、方法和类型等条件，通过澄清其业务目的、获取条件对应值的标准等，识别出缺失的标准。找出所有条件取值信息。2）去除重复：在不同特征下具有的同名条件，如果确认内容一样，则可以统一定义为新特征。3）去除冗余：识别冗余条件，并进行删除。4）命名清晰：命名使用名词、名词词组或者动名词结构，每个条件都应包括描述。5）依赖产品：条件必须与产品相关。如图24所示。

（3）交付物示例，如图25所示。

四、4.定义产品组件

工序4.1：优化产品特征

（1）工艺方法

对特征进行优化，主要是为了方便后续转换成产品组件。

操作方法：a、从产品特征的目的性是否唯一，考虑特征的合并或拆分；b、从扩展性上，如果一个特征的条件过多，则考虑拆分；

原则：a、不能单纯的为了拆分而拆分，重点从业务目的上考虑；b、如果某些特征只有部分产品使用，可以独立存在，不必为了合并而进行合并。

（2）工艺工具

基于既定的原则对产品特征进行优化，以识别备选产品组件。审查各产品组项下的所有产品特征及其定义，基于以下标准考虑合并与拆分产品特征：1)、从功能视角，如果产品特征的目的不够清晰，则考虑与其他产品特征合并；如果同一个产品特征拥有多于一种的功能，则考虑拆分。2)、从可扩展性视角，如果产品特征具有大于15个产品条件，则考虑拆分。如图26所示。

（3）交付物示例，如图27所示。

工序4.2：定义产品组件

（1）工艺方法

将特征转换为产品组件，并对组件进行定义。

操作方法：a、将特征转换为产品组件，保证组件名称命名标准化；b、对每个组件的内容进行描述。

原则：a、产品组件的名称必须唯一，不允许重复；b、考虑业务配置方便，如果需要对产品组件进行拆分合并，需通过上一道工序进行处理；

（2）工艺工具

在充分理解与决策考虑事项，对产品特征进行最后优化后，将产品特征更名为产品组件。产品组件名称应该是清晰的、清楚地解释产品组件的功能，支持产品组件的唯一性，其命名规范为“前缀 + 功能或目的 + 后缀”：1)、前缀：如果产品组件名字已经能够清晰的表述，则前缀可以不需要，否则可以通过增加“产品组名称、基础产品名称”作为前缀来进行清晰表述；2)、功能或目的：可以清晰的解释产品组件的功能或目的；3)、后缀：以“组件”为后缀。如图28所示。

（3）交付物示例，如图29所示。

工序4.3：产品组件与基础产品映射

（1）工艺方法

将产品组件与基础产品进行映射，检查分类结构中对基础产品和可售产品的划分的准确性，同时为后续产品实例化提供依据。

操作方法：对每个产品组下的基础产品，进行产品组件的映射。

原则：a、每个基础产品必须包含N个产品组件；b、一个产品组件可能被N个基础产品映射。

（2）工艺工具

通过将基础产品与产品组件进行映射，建立产品组件与基础产品之间的关系。如图30所示。

（3）交付物示例，如图31所示。

五、5.产品实例化

工序5.1：产品实例化

（1）工艺方法

对每个可售产品进行实例化，确保产品组件识别的准确性。

操作方法

对每个可售产品涉及的产品组件，每个条件进行确认取值；

原则

a、所有的可售产品需要进行实例化；

（2）工艺工具

根据产品政策文档、产品手册、产品信息收集表、产品组件和产品条件等各方面获取的信息，将实际参数取值映射到可售产品的条件参数表。通过填写“是否涉及”、“实例化取值”两列标注产品条件参数取值，其中“是否涉及”标注该可售产品是否涉及到此产品条件取值，“实例化取值”则是识别在产品层协商的产品条件取值。如图33所示。

（3）交付物示例，如图33所示。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：在本发明的精神和原则之内，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案脱离本发明的保护范围。

Claims (5)

1.一种用于软件开发中需求建模的产品建模系统，其特征在于，所述产品建模系统包括：

产品信息收集模块，收集企业各产品的产品信息，具体包括收集可售产品清单、收集产品相关文件、收集产品基本信息、确认产品核算信息、收集产品专业信息、识别产品特征；

产品分类结构设定模块，对行业实践的产品目录按产品线、产品组、基础产品、可售产品四层结构进行分类；

产品特征定义模块，对各可售产品的特征进行定义；

产品组件定义模块，对产品特征进行合并或拆分，并将特征转换为产品组件，对产品组件进行定义；

产品实例化模块，对每个可售产品进行实例化；

所述产品特征定义模块具体用于：

提炼产品特征，将初步识别的特征，按划分的产品组进行归纳提炼；

识别备选条件，在特征下识别可能存在的产品条件，作为产品条件的备选；

确认产品条件，对识别的备选产品条件进行确认，同时对产品属性和产品关系信息进行确认；

检查完整性，检查产品条件，确认产品条件的完整性；

所述产品特征定义模块提炼产品特征包括：

根据识别产品特征中的特征与可售产品关系以及产品分类结构，将产品特征按产品组进行归纳；

对归纳后的产品特征，按基础产品作为一级，可售产品作为二级的形式，重新与特征建立关联关系。

2.根据权利要求1所述的产品建模系统，其特征在于，所述产品信息收集模块收集可售产品清单包括：

确定企业各业务对应的业务线条，基于各线条业务收集对应的第一可售产品；

导出数据库表的产品目录中存储的第二可售产品；

核对第一可售产品和第二可售产品，生成可售产品清单。

3.根据权利要求2所述的产品建模系统，其特征在于，所述产品信息收集模块收集的产品相关文件包括：收集可售产品清单中各可售产品关联的产品说明书、产品模板、产品协议模板、产品需求规格说明书。

4.根据权利要求2所述的产品建模系统，其特征在于，所述产品信息收集模块收集的产品基本信息包括：产品描述信息、产品关系人信息、产品市场信息、产品分类信息、产品经营条件信息。

5.根据权利要求1所述的产品建模系统，其特征在于，所述产品信息收集模块收集产品专业信息包括：根据每条业务线的专业特点，从业务特征、业务条件、计息要求及收费条件三方面，对专业信息进行收集。