CN108932118B - 一种基于卡牌的需求获取模型建立方法 - Google Patents

Abstract

本发明涉及一种基于卡牌的需求获取模型建立方法，属于需求获取技术领域，解决了现有技术中需求获取依赖业务分析师、获取效率和沟通成本较高的问题。步骤如下：以场景为单位，将软件的整体业务活动划分为若干类业务场景；根据所述每类业务场景，建立该类业务场景的基于卡牌的需求获取元模型；建立基于卡牌的需求获取元模型对应的需求缺陷检测模型，对根据所述需求获取元模型所获取得到的缺陷检测模型实例进行缺陷检测，根据该缺陷检测结果对所述的需求获取元模型进行优化；根据优化后的需求获取元模型，建立需求获取模型，进行可视化展示和仿真验证。该方法有效降低需求获取对业务分析师的依赖性，降低了沟通成本，提高了需求获取效率。

Description

一种基于卡牌的需求获取模型建立方法

技术领域

本发明涉及需求获取技术领域，尤其涉及一种基于卡牌的需求获取模型建立方法。

背景技术

需求描述了软件系统的行为、特性或属性，是用户和开发人员之间的桥梁。准确、完整的需求是指导系统后续建模、分析、开发和测试的根本依据，在需求工程中，需求获取是确保需求质量的重要的活动。

传统的需求获取有访谈、问卷调查、用例和场景法、工作坊、焦点小组、原型化法、文档分析等。业务分析师往往需要先了解业务需求和功能需求，然后依据个人经验确定功能需求和非功能需求，并最终通过各方干系人的评审与确认。需求获取过程中，往往存在以下常见风险：待研软件的直接用户没有充分参与、需求优先级设定不当、过度解读用户需求、需求二义性、干系人没有存在感等。这些风险需要在需求获取方法中提供必要的措施加以防范和避免。

传统的需求获取方法大部分是由业务分析师来主导使用，对业务分析师具有很强的依赖性。而作为需求相关信息主要来源的最终用户、客户等其他干系人，却往往只能被动地参与其中，缺乏协同和良好的流程控制。需求获取的质量取决于业务分析师对问题领域的熟知程度和对有效需求的敏感程度。面对日益复杂的软件系统，其获取效率和沟通成本较高。

发明内容

鉴于上述的分析，本发明旨在提供一种基于卡牌的需求获取模型建立方法，用以解决现有需求获取主要依赖业务分析师完成、获取效率和沟通成本较高的问题。

本发明的目的主要是通过以下技术方案实现的：

一种基于卡牌的需求获取模型建立方法，具体包括以下步骤：

步骤S1：以场景为单位，将软件的整体业务活动划分为若干类业务场景；

步骤S2：根据所述每类业务场景，建立该类业务场景的基于卡牌的需求获取元模型；

步骤S3：建立基于卡牌的需求获取元模型对应的需求缺陷检测模型，对根据所述需求获取元模型所获取得到的需求元模型进行缺陷检测，根据该缺陷检测结果对所述的需求获取元模型进行优化；

步骤S4：根据优化后的需求获取元模型，建立需求获取模型，进行可视化展示和仿真验证。

本发明有益效果如下：本实施例提供的基于卡牌的需求获取模型建立方法，充分利用卡牌的角色特点，用户通过在场景中担任相应的角色，协同输入业务场景和用例需求相关信息，提高了用户的参与度，使其能够更加积极地加入讨论，更容易提高大家的参与度，解决了现有需求获取主要依赖业务分析师完成、获取效率和沟通成本较高的问题。

在上述方案的基础上，本发明还做了如下改进：

进一步，所述每类业务场景的需求相关信息包含开始条件、结束条件、优先级和详细的业务流程描述；

分析每类业务场景包含的项目、领域、用户、数据、业务活动信息，根据每类业务场景的需求相关信息确定上述项目、领域、用户、数据、业务活动信息间的关联关系，建立该类业务场景的基于卡牌的需求获取元模型。

采用上述进一步方案的有益效果是：场景为需求描述提供上下文环境。需求描述是一种具体化的过程，在实践中需要提供尽可能多的实例和细节。需求的提供者需要置身于相应的上下文环境中，调动个人经验和想象能力，才能将业务活动或者所期望的软件需求尽可能描述准确。

进一步，基于卡牌的需求获取元模型模块包括项目模块、领域模块、用户模块、数据模块、业务场景模块、业务活动模块和用例模块；

其中，

所述项目模块中包含项目名称、项目简述、功能概述、用户类别字段信息；

所述领域模块包含领域名称、领域概述、领域特征字段信息；

所述用户模块包含职责、交互方式、权限级别、使用频率、使用的平台和语言字段信息；

所述数据模块包含数据项名称、数据项描述信息字段信息；

所述业务场景模块用于描述所有用户使用系统的活动场景，包含场景名称、场景描述、场景流程、相关依赖字段信息；

所述业务活动模块用于描述活动场景中的共性事件，包含活动名称、活动描述、优先级、前后置条件、活动流程字段信息；

所述用例模块包含用例名称、优先级、前后置条件、用例流程字段信息。

采用上述进一步方案的有益效果是：本申请通过梳理需求工程领域优秀实践中的获取方法和业务需求相关的愿景和范围文档、用户需求文档及功能需求相关的软件需求规范说明中涉及的内容和模块，归纳、总结出了一套基于卡牌的需求获取元模型模块，并对其各个模块进行了具体分析，相关工作人员利用本申请提供的基于卡牌的需求获取元模型及具体模块，可以简化需求获取设计过程，减少工作量，本申请对相关需求获取具有指导意义。

进一步，在基于卡牌的需求获取元模型中，

用户和领域属于多对多的关联关系，用户和项目属于多对多的关系。

用例用来描述一个用户在某种业务场景下的相关交互活动，一个业务场景由多个用例实现，一个用例完成多个业务场景中的共同部分。

采用上述进一步方案的有益效果是：一个用户能够创建多个领域领域，一个领域也常常包含多个用户。用户和领域之间属于多于多关联关系。用户能够创建项目担任管理员或者加入项目担任某角色实例，项目可以包含多个用户，用户和项目之间之间属于多对多关联关系。需求获取会涉及多个具体的业务场景，即使是同一个业务场景，也会包括多个具体的交互活动，需要多个用例来完成，通过分析用例和业务场景之间的关系，使得相关工作人员明确本申请提供的需求获取模型的使用规则，便于提高相关工作人员的工作效率。

进一步，通过每一类需求获取元模型所获得的需求元模型的实例，建立得到每类需求获取元模型的缺陷检测模型。

采用上述进一步方案的有益效果是：在需求获取早期使用卡牌模型获取需求相关信息的基础上对获取到的需求信息进行缺陷检测，从而支持需求获取过程中早期缺陷的发现，并引导需求相关方及时修订和充实需求相关信息。

进一步，所述缺陷检测模型为4层树形结构；第一层为缺陷检测模型层，节点唯一对应一个缺陷检测模型实例；第二层为交互活动规格层，代表了包含数据流和控制流信息的一个用例规约；第三层为交互活动层，代表了一个用例规约中的控制流或者数据流；第四层为节点层，代表了控制流或者数据流中的组成节点元素。

采用上述进一步方案的有益效果是：借助这种树形结构，在遍历缺陷检测模型实例时，只需要从根节点找到包含了控制流和数据流信息的缺陷检测规格，就可以找到所有与之关联的模型元素。缺陷检测模型能够找到所有的缺陷检测规格，而且缺陷检测规格的子元素都存储在该节点的属性下，所以都可以获取。除了缺陷检测模型，属性中不包含父层信息的模型元素都是没用的，所以保证了一定可以访问缺陷检测模型实例中的每一个模型元素。

进一步，缺陷检测采用自动化遍历检测方法，包括：

从根节点开始，找到包含控制流和数据流信息的缺陷检测规格集合；

通过广度优先遍历方法找到所有与需要检测的需求元模型关联的模型元素，访问得到缺陷检测模型中的每一个模型元素；

利用所访问得到的每一个模型元素对需求获取元模型进行检测，根据所述检测结果对得到该需求元模型的需求获取元模型进行优化。

采用上述进一步方案的有益效果是：通过自动化遍历检测方法，能够有效检测需求获取元模型，并根据检测结果对需求获取元模型进行优化。

进一步，所述步骤S4包括以下步骤：

步骤S401：根据优化后的需求获取元模型，结合具体领域和元模型模块对应的信息，建立需求获取模型，进行可视化展示；

步骤S402：利用CRAM支撑工具人机交互界面的仿真验证能力验证需求获取模型的完整性、一致性及逻辑可行性。

采用上述进一步方案的有益效果是：根据模型中元素的类别制定检测规则，CRAM基于规则完成需求获取模型的完整性、一致性及逻辑可行性检测。通过建立需求获取模型，并验证需求获取模型的完整性、一致性及逻辑可行性，使得本申请建立的需求获取模型功能更加完善，更具有指导意义。

进一步，所述CRAM支撑工具根据Web架构，具体分为展示层、控制层、服务层和持久层四个部分。

采用上述进一步方案的有益效果是：通过对CRAM支撑工具根据Web架构进行分层，保证需求获取模型的检测过程与实际在Web架构中的执行过程保持一致。

进一步，

所述展示层中，Tomcat负责对JSP和Servlet的容器提供支持，与Vue.JS编写的交互界面共同实现最终Web窗口和页面的展示；

所述控制层中，通过FilterDispatcher拦截机制获取页面的Action请求，控制JSP视图和需求获取模型间的数据交换，Vue.JS中调用的所有HttpServlet请求将直接由Tomcat容器支持；

所述服务层中，所有Action和Servlet统一调用逻辑层由JavaBeans实现的各种service服务接口；

所述持久层中，通过MyBatis提供的数据库的持久化技术，建立需求获取模型数据库表与内存间的映射关系，并将Service中的数据处理接口通过*Mapper.xml的配置，经由DAO实现对MySQL的增删改查操作。

采用上述进一步方案的有益效果是：本申请针对基于卡牌的需求获取模型，设计了相应的功能验证支撑工具，该支撑工具具有很强的仿真验证能力，能够验证需求获取模型的完整性、一致性及逻辑可行性。

本发明中，上述各技术方案之间还可以相互组合，以实现更多的优选组合方案。本发明的其他特征和优点将在随后的说明书中阐述，并且，部分优点可从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过说明书、权利要求书以及附图中所特别指出的内容中来实现和获得。

附图说明

附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。

图1为基于卡牌的需求获取模型建立方法示意图；

图2为基于卡牌的需求获取元模型示意图；

图3为CRAM支撑工具结构示意图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理，并非用于限定本发明的范围。

本发明的一个具体实施例，公开了一种基于卡牌的需求获取模型建立方法，如图1所示。

实施时，包括以下步骤：

步骤S1：以场景为单位，将软件的整体业务活动划分为若干类业务场景；

步骤S2：根据所述每类业务场景，建立该类业务场景的基于卡牌的需求获取元模型；

步骤S3：建立基于卡牌的需求获取元模型对应的需求缺陷检测模型，对根据所述需求获取元模型所获取得到的需求元模型进行缺陷检测，根据该缺陷检测结果对所述的需求获取元模型进行优化；

步骤S4：根据优化后的需求获取元模型，建立需求获取模型，进行可视化展示和仿真验证。

与现有技术相比，本实施例提供的基于卡牌的需求获取模型建立方法，充分利用卡牌的角色特点，用户通过在场景中担任相应的角色，协同输入业务场景和用例需求相关信息，提高了用户的参与度，使其能够更加积极地加入讨论，更容易提高大家的参与度，解决了现有需求获取主要依赖业务分析师完成、获取效率和沟通成本较高的问题。

所述每类业务场景的需求相关信息包含开始条件、结束条件、优先级和详细的业务流程描述；

分析每类业务场景包含的项目、领域、用户、数据、业务活动信息，根据每类业务场景的需求相关信息确定上述项目、领域、用户、数据、业务活动信息间的关联关系，建立该类业务场景的基于卡牌的需求获取元模型。

场景为需求描述提供上下文环境。需求描述是一种具体化的过程，在实践中需要提供尽可能多的实例和细节。需求的提供者需要置身于相应的上下文环境中，调动个人经验和想象能力，才能将业务活动或者所期望的软件需求尽可能描述准确。

优选地，基于卡牌的需求获取元模型模块包括项目模块、领域模块、用户模块、数据模块、业务场景模块、业务活动模块和用例模块；

其中，

所述项目模块中包含项目名称、项目简述、功能概述、用户类别字段信息；

所述领域模块包含领域名称、领域概述、领域特征字段信息；

所述用户模块包含职责、交互方式、权限级别、使用频率、使用的平台和语言字段信息；

所述数据模块包含数据项名称、数据项描述信息字段信息；

所述业务场景模块用于描述所有用户使用系统的活动场景，包含场景名称、场景描述、场景流程、相关依赖字段信息；

所述业务活动模块用于描述活动场景中的共性事件，包含活动名称、活动描述、优先级、前后置条件、活动流程字段信息；

所述用例模块用于描述用户和系统之间的交互过程，包含用例名称、优先级、前后置条件、用例流程字段信息。

各个模块通过具体的业务场景，根据各个模块的功能相互关联，构成了基于卡牌的需求获取元模型，基于卡牌的需求获取元模型示意图如图2所示。

本申请通过梳理需求工程领域优秀实践中的获取方法和业务需求相关的愿景和范围文档、用户需求文档及功能需求相关的软件需求规范说明中涉及的内容和模块，归纳、总结出了一套基于卡牌的需求获取元模型模块，并对其各个模块进行了具体分析，相关工作人员利用本申请提供的基于卡牌的需求获取元模型及具体模块，可以简化需求获取设计过程，减少工作量，本申请对相关需求获取具有指导意义。

在基于卡牌的需求获取元模型中，

用户和领域属于多对多的关联关系，用户和项目属于多对多的关系。

用例用来描述一个用户在某种业务场景下的相关交互活动，一个业务场景由多个用例实现，一个用例完成多个业务场景中的共同部分。

一个用户能够创建多个领域领域，一个领域也常常包含多个用户。用户和领域之间属于多于多关联关系。用户能够创建项目担任管理员或者加入项目担任某角色实例，项目可以包含多个用户，用户和项目之间之间属于多对多关联关系。需求获取会涉及多个具体的业务场景，即使是同一个业务场景，也会包括多个具体的交互活动，需要多个用例来完成，通过分析用例和业务场景之间的关系，使得相关工作人员明确本申请提供的需求获取模型的使用规则，便于提高相关工作人员的工作效率。

通过每一类需求获取元模型所获得的需求元模型，建立得到每类需求获取元模型的缺陷检测模型。

在需求获取早期使用卡牌模型获取需求相关信息的基础上对获取到的需求信息进行缺陷检测，从而支持需求获取过程中早期缺陷的发现，并引导需求相关方及时修订和充实需求相关信息。

所述缺陷检测模型为4层树形结构；第一层为缺陷检测模型层，节点唯一对应一个缺陷检测模型实例；第二层为交互活动规格层，代表了包含数据流和控制流信息的一个用例规约；第三层为交互活动层，代表了一个用例规约中的控制流或者数据流；第四层为节点层，代表了控制流或者数据流中的组成节点元素。

借助这种树形结构，在遍历缺陷检测模型实例时，只需要从根节点找到包含了控制流和数据流信息的缺陷检测规格，就可以找到所有与之关联的模型元素。缺陷检测模型能够找到所有的缺陷检测规格，而且缺陷检测规格的子元素都存储在该节点的属性下，所以都可以获取。除了缺陷检测模型，属性中不包含父层信息的模型元素都是没用的，所以保证了一定可以访问缺陷检测模型实例中的每一个模型元素。

缺陷检测采用自动化遍历检测方法，包括：

从根节点开始，找到包含控制流和数据流信息的缺陷检测规格集合；

通过广度优先遍历方法找到所有与需要检测的需求元模型关联的模型元素，访问得到缺陷检测模型中的每一个模型元素；

利用所访问得到的每一个模型元素对需求获取元模型进行检测，根据所述检测结果对得到该需求元模型的需求获取元模型进行优化。

通过自动化遍历检测方法，能够有效检测需求获取元模型，并根据检测结果对需求获取元模型进行优化。

优选地，所述步骤S4包括以下步骤：

步骤S401：根据优化后的需求获取元模型，结合具体领域和元模型模块对应的信息，建立需求获取模型，进行可视化展示；

步骤S402：利用CRAM支撑工具人机交互界面的仿真验证能力验证需求获取模型的完整性、一致性及逻辑可行性。

根据模型中元素的类别制定检测规则，CRAM基于规则完成需求获取模型的完整性、一致性及逻辑可行性检测。通过建立需求获取模型，并验证需求获取模型的完整性、一致性及逻辑可行性，使得本申请建立的需求获取模型功能更加完善，更具有指导意义。

进一步地，所述CRAM(multi-view Cards based Requirement Acquisition andModelling tool)支撑工具根据Web架构，具体分为展示层、控制层、服务层和持久层四个部分，CRAM支撑工具结构示意图如图3所示。

所述展示层中，Tomcat负责对JSP和Servlet的容器提供支持，与Vue.JS编写的交互界面共同实现最终Web窗口和页面的展示；

所述控制层中，通过FilterDispatcher拦截机制获取页面的Action请求，控制JSP视图和数据模型间的数据交换，Vue.JS中调用的所有HttpServlet请求将直接由Tomcat容器支持；

所述服务层中，所有Action和Servlet统一调用逻辑层由JavaBeans实现的各种service服务接口；

所述持久层中，通过MyBatis提供的数据库的持久化技术，建立数据库表与内存模型之间的映射关系，并将Service中的数据处理接口通过*Mapper.xml的配置，经由DAO实现对MySQL的增删改查操作。

本申请针对基于卡牌的需求获取模型，设计了相应的功能验证支撑工具，该支撑工具具有很强的仿真验证能力，能够验证需求获取模型的完整性、一致性及逻辑可行性。

本领域技术人员可以理解，实现上述实施例方法的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读存储介质中。其中，所述计算机可读存储介质为磁盘、光盘、只读存储记忆体或随机存储记忆体等。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (9)

1.一种基于卡牌的需求获取模型建立方法，其特征在于，具体包括以下步骤：

步骤S1：以场景为单位，将软件的整体业务活动划分为若干类业务场景；

步骤S2：根据每类业务场景，建立该类业务场景的基于卡牌的需求获取元模型；

步骤S3：建立基于卡牌的需求获取元模型对应的需求缺陷检测模型，对根据所述需求获取元模型所获取得到的需求元模型进行缺陷检测，根据该缺陷检测结果对所述的需求获取元模型进行优化；

步骤S4：根据优化后的需求获取元模型，建立需求获取模型，进行可视化展示和仿真验证；

所述缺陷检测模型为4层树形结构；第一层为缺陷检测模型层，节点唯一对应一个缺陷检测模型实例；第二层为交互活动规格层，代表了包含数据流和控制流信息的一个用例规约；第三层为交互活动层，代表了一个用例规约中的控制流或者数据流；第四层为节点层，代表了控制流或者数据流中的组成节点元素。

2.根据权利要求1所述的基于卡牌的需求获取模型建立方法，其特征在于，所述每类业务场景的需求相关信息包含开始条件、结束条件、优先级和详细的业务流程描述；

分析每类业务场景包含的项目、领域、用户、数据、业务活动信息，根据每类业务场景的需求相关信息确定上述项目、领域、用户、数据、业务活动信息间的关联关系，建立该类业务场景的基于卡牌的需求获取元模型。

3.根据权利要求2所述的基于卡牌的需求获取模型建立方法，其特征在于，基于卡牌的需求获取元模型模块包括项目模块、领域模块、用户模块、数据模块、业务场景模块、业务活动模块和用例模块；

其中，

所述项目模块中包含的字段信息有：项目名称、项目简述、功能概述、用户类别；

所述领域模块包含的字段信息有：领域名称、领域概述、领域特征；

所述用户模块包含的字段信息有：职责、交互方式、权限级别、使用频率、使用的平台和语言；

所述数据模块包含的字段信息有：数据项名称、数据项描述信息；

所述业务场景模块用于描述所有用户使用系统的活动场景，包含的字段信息有：场景名称、场景描述、场景流程、相关依赖；

所述业务活动模块用于描述活动场景中的共性事件，包含的字段信息有：活动名称、活动描述、优先级、前后置条件、活动流程；

所述用例模块包含的字段信息有：用例名称、优先级、前后置条件、用例流程。

4.根据权利要求3所述的基于卡牌的需求获取模型建立方法，其特征在于，在基于卡牌的需求获取元模型中，

用户和领域属于多对多的关联关系，用户和项目属于多对多的关系；

用例用来描述一个用户在某种业务场景下的相关交互活动，一个业务场景由多个用例实现，一个用例完成多个业务场景中的共同部分。

5.根据权利要求1所述的基于卡牌的需求获取模型建立方法，其特征在于，通过每一类需求获取元模型所获得的需求元模型的实例，建立得到每类需求获取元模型的缺陷检测模型。

6.根据权利要求1或5所述的基于卡牌的需求获取模型建立方法，其特征在于，

缺陷检测采用自动化遍历检测方法，包括：

从根节点开始，找到包含控制流和数据流信息的缺陷检测规格集合；

通过广度优先遍历方法找到所有与需要检测的需求元模型关联的模型元素，访问得到缺陷检测模型中的每一个模型元素；

利用所访问得到的每一个模型元素对需求获取元模型进行检测，根据所述检测结果对得到该需求元模型的需求获取元模型进行优化。

7.根据权利要求1所述的基于卡牌的需求获取模型建立方法，其特征在于，所述步骤S4包括以下步骤：

步骤S401：根据优化后的需求获取元模型，结合具体领域和元模型模块对应的信息，建立需求获取模型，进行可视化展示；

步骤S402：利用CRAM支撑工具人机交互界面的仿真验证能力验证需求获取模型的完整性、一致性及逻辑可行性。

8.根据权利要求7所述的基于卡牌的需求获取模型建立方法，其特征在于，所述CRAM支撑工具根据Web架构，具体分为展示层、控制层、服务层和持久层四个部分。

9.根据权利要求8所述的基于卡牌的需求获取模型建立方法，其特征在于，

所述展示层中，Tomcat负责对JSP和Servlet的容器提供支持，与Vue.JS编写的交互界面共同实现最终Web窗口和页面的展示；

所述控制层中，通过FilterDispatcher拦截机制获取页面的Action请求，控制JSP视图和需求获取模型间的数据交换，Vue.JS中调用的所有HttpServlet请求将直接由Tomcat容器支持；

所述服务层中，所有Action和Servlet统一调用逻辑层由JavaBeans实现的各种service服务接口；

所述持久层中，通过MyBatis提供的数据库的持久化技术，建立需求获取模型数据库表与内存间的映射关系，并将Service中的数据处理接口通过*Mapper.xml的配置，经由DAO实现对MySQL的增删改查操作。

Images