一种基于场景的业务需求描述方法与流程

本发明涉及软件工程技术领域，尤其是需求工程中的需求建模与描述领域，具体涉及一种基于场景的业务需求描述方法。

背景技术：

在软件工程理论发展的几十年里，正确地获取待开发软件系统的确切需求一直是该领域研究的重要课题。在需求分析研究的早期阶段，bell和thayer观察到，不充分、相互矛盾以及非完全的软件需求描述是影响软件设计质量的一个非常关键的因素。他们指出“设计一个系统的需求并不总是非常清楚的，特别是对于较为复杂的系统设计，需要采用工程的观点，对待开发软件系统的需求进行系统化的分析和设计”。

最近的调查再次证明软件开发过程中需求分析问题的重要性。例如在美国，一项涉及350家公司8000个软件工程项目的调查显示，大约有三分之一的工程没有完成，另外还有大约一半的工程仅仅是部分的完成。真正达到预期效果的工程项目仅占整个被调查对象的10％不到。当被问及这些项目实施的失败原因时，需求分析的不充分是其中一个非常重要的因素。改进描述软件需求的质量是如此的关键，但在早期的软件工程研究中，其往往成为一个被忽视的方面。分析其原因，一方面早期软件开发规模比较小，一个人或几个人就可以将其很好地开发出来，无须复杂的工程规划过程。另一方面，需求的分析和研究是一种充分体现社会特性的，高度抽象化的过程，用户通过语言描述的体现人类社会性行为和规则的粗糙的需求概念和关系与软件设计开发的精确的技术描述之间有着较大的差异，很难描述出一个既能让用户轻松理解又能作为开发人员的开发规范的描述文档。随着软件规模的不断增长，需求分析在软件开发过程中的重要性也在不断增加。为了更深入地理解，有必要了解一下需求分析的相关研究内容。

需求分析(requirementanalysis,ra)是软件系统开发过程的首要行为。该行为通常包括获取广泛的有关待开发软件系统的需求信息、分析识别需求信息的基本设计目标、分析与实现需求相关的重要领域知识和约束要求、针对需求特点选择合适的软件体系结构、分析实现需求的基本组件和服务模块等。从这个描述性的定义可以看出需求分析涉及的范围非常广泛，从人类社会的组织模式和行为法则到自然世界中的基本规律、从高层的抽象对象到具体的组件描述、从一些模糊意念的表达到严格的数学推理等都被包含在其中。为了综合全面地建立一个系统的需求模型必须从多个不同角度进行分析，特别是需要结合系统所处的环境考虑系统的设计要求。

需求分析的目的是通过对待开发软件系统预期实现目标的分析，识别出所有相关的概念和关系，建立需求模型。建立需求模型需要有一套完善的需求分析理论的支持，来保持系统的组织结构以及系统组件的能力和它们所提供的服务的稳定性。

传统需求描述方法主要以软件开发为中心，以系统功能点为单位，结合软件流程图，来对业务需求进行描述。这样的需求描述方法存在以下缺陷：

(1)不同领域的需求合并困难。随着跨界服务的出现，不同领域的服务和需求需要被整合合并。比如医养康服务的需求来自医疗、养老和健康三个领域，通过传统需求建模方法很难统一表达。需求容易出现一词多义或是多词一义的情况。

(2)传统需求描述方法难以涵盖离线场景。传统需求描述方法主要描述线上软件中的业务流程，忽视了线下业务流程需求的刻画，比如在医养康服务中，线上服务和线下场景(体检、上门问诊等)是强绑定的。

技术实现要素：

针对本领域存在的不足之处，本发明提供了一种基于场景的业务需求描述方法，可以帮助产品经理或业务中台在现有跨界服务涌现、线上线下融合的背景下，更快、更准确地定位和描述需求。

本发明的基于场景的业务需求描述方法的流程示意图如图1所示，包括：

(1)对所描述领域的业务需求进行建模，定义业务概念、业务场景、业务流程、业务规则和业务需求；

(2)描述需求中的业务概念；

(3)基于已描述的业务概念，描述需求中的业务场景，以及业务场景之间的连接关系；

(4)基于已描述的业务概念，描述需求中的业务流程；

(5)基于已描述的业务概念，描述需求中的业务规则；

(6)整合业务概念、业务场景、业务流程、业务规则，形成业务需求。

本发明中，所述的业务概念为该业务需求中可能出现的业务角色、业务行为。所以，步骤(1)中，所述的业务概念包括业务需求中的业务角色和业务行为。

所述的业务角色的元素包括角色名称、角色属性、属性类型、角色属性到属性类型的映射关系，即对于每个业务角色，需定义的元素包括{角色名称，角色属性，属性类型，角色属性到属性类型的映射关系}。

所述的角色属性一般包括该角色在业务过程中表现出的物化属性，如性别、年龄等。

所述的属性类型为现有常用的数据类型，如数字、字符串、数组、字典等。

所述的业务行为的元素包括动作名称、动作类型、动作描述，即对于每个业务行为，需定义的元素包括{动作名称，动作类型，动作描述}。

所述的动作类型包括主动、被动，即需定义的元素包括{主动/被动}。

所述的动作描述为对动作执行效果的文字描述。

本发明中，所述的业务场景为该业务需求所描述的业务执行所对应的线下场景，作为优选，所述的业务场景为结合了线上服务的线下场景。

步骤(1)中，所述的业务场景的元素包括场景名称、执行者、前提条件、影响，即对于每个业务场景，需定义的元素包括{场景名称，执行者，前提条件，影响}。

所述的执行者为业务角色。

所述的前提条件为决定场景可入性的条件，可经过推理判断{真/假}。

所述的影响为当前场景业务结束后，根据情况选择进入下一场景的约束。

本发明中，所述的业务流程为在一个场景中需要执行的业务流程，主要指在单个业务场景中涉及到的线上业务流程。

步骤(1)中，所述的业务流程的元素包括流程名称、操作集合、关系集合，即对于每个业务流程，需定义的元素包括{流程名称，操作集合，关系集合}。

所述的操作集合中，单个操作的元素包括操作名称、操作行为、操作对象，即需定义的元素包括{操作名称，操作行为，操作对象}。

所述的操作行为为业务行为。

所述的操作对象为业务角色。

所述的关系集合中，单个关系的元素包括关系名称、从哪个操作出发、到哪个操作、条件，即需定义的元素包括{关系名称，从哪个操作出发，到哪个操作，条件}。

本发明中，所述的业务规则为在一个场景中执行业务流程时需要遵守的业务规则，主要指在单个业务场景中执行业务流程时，需要遵循的业务规则。

步骤(1)中，所述的业务规则的元素包括规则名称、生效条件、规则生效出发的操作、规则类型，即对于每个业务规则，需定义的元素包括{规则名称，生效条件，规则生效出发的操作，规则类型}。

所述的规则类型包括操作规则、属性规则、触发器规则，即需定义的元素包括{操作规则/属性规则/触发器规则}。

所述的操作规则表示生效条件生效时，操作变得可执行。

所述的属性规则表示生效条件生效时，操作须已执行过。

所述的触发器规则表示生效条件生效时，操作自动执行。

步骤(1)中，所述的业务需求的元素包括业务需求名称、业务需求概念集合、单元需求集合，即对于每个业务需求，需定义的元素包括{业务需求名称，业务需求概念集合，单元需求集合}。

所述的业务需求概念集合为业务角色和业务行为组成的集合。

所述的单元需求集合中，单个单元需求的元素包括单元需求名称、业务场景、业务流程、业务规则，即需定义的元素包括{单元需求名称，业务场景，业务流程，业务规则}，表示在何业务场景下，执行何业务流程，须遵循何业务规则。

步骤(6)中，业务需求将所有解耦的业务概念、业务场景、业务流程、业务规则进行组合，形成新的业务需求。

本发明与现有技术相比，主要优点包括：

(1)对需求中的概念进行统一的形式化描述。通过对需求中出现的概念进行统一的定义和管理，来解决需求中可能出现的一词多义和多词一义的问题。

(2)结合线下应用场景描述业务需求。通过引入场景的概念，将业务活动和操作与场景进行匹配，来同时描述线上、线下的业务流程需求。

附图说明

图1为本发明的基于场景的业务需求描述方法的流程示意图；

图2为本发明的基于场景的业务需求描述方法的优选方案流程示意图。

具体实施方式

下面结合附图及具体实施例，进一步阐述本发明。应理解，这些实施例仅用于说明本发明而不用于限制本发明的范围。下列实施例中未注明具体条件的操作方法，通常按照常规条件，或按照制造厂商所建议的条件。

如图2所示，本实施例的基于场景的业务需求描述方法，包括：

(1)对所描述领域的业务需求进行建模，定义业务需求模型，具体定义业务概念、业务场景、业务流程、业务规则和业务需求；

(2)描述需求中可能出现的业务概念，具体描述业务角色、业务行为以及确定角色、行为的匹配关系；

(3)基于已描述的业务概念，描述需求中所有可能出现的业务场景，以及业务场景之间的连接关系，具体描述执行者、前提条件和场景影响；

(4)基于已描述的业务概念，描述需求中所有可能出现的业务流程，具体描述流程操作、操作关系；

(5)基于已描述的业务概念，描述需求中所有可能出现的业务规则，具体描述生效条件、生效行为，确定规则类型；

(6)整合业务概念、业务场景、业务流程、业务规则，链接概念集合、单元需求集合，形成业务需求。

步骤(1)中，所述的建模的优选方案如下：

为了便于理解，假设存在以下两两不相交的可数无限集：原始类型动作类型规则类型类(名)每个类的标识符为idc。一个类型可以是

中每种类型τ的域，表示为dom(τ)，定义如下：

如果是原始类型，则域dom(τ)是一些已知的值的类型集(整数、字符串、数组、集合、字典等)；

如果为动作类型，则dom(τ)＝主动(positive)/被动(passive)；

如果是规则类型，则dom(τ)＝触发器规则(triggerrule)/属性规则(attributerule)/操作规则(operationrule)；

如果是一个类(名)，则dom(τ)＝idτ，可以是除以上三种类型名外的任意字符串。

此外，本方法中还会出现条件(condition，或简写为∈)，一个condition可以是一下几种中的一种：

(a)正确(true)/错误(false)；

(b)done(a，o)，如果角色a已经执行了操作o则为true，否则为false；

(c)est(a1，a2，comp)，如果属性a1，a2满足比较运算comp(大于/小于/等于)则为true，否则为false；

(d)∈1and∈2，当两个条件∈1和∈2都为true时为true，否则为false；

(e)∈1or∈2，当两个条件∈1和∈2都为false时为false，否则为true；

(f)not∈，当条件∈为true时为false，否则为true；

(g)任意可以判断正确(true)/错误(false)的语句。

1.定义需求中可能出现的业务概念；

在本方法中，一个业务概念集被定义为concept＝(cco，ro，a，μra)，cco代表这个概念集的标识符，ro和a分别是这个概念中的角色集合和动作集合，μra是一个部分映射，将每个动作映射到角色上。

角色集合ro中的一个角色role＝(cro，atτ，μat)，其中cro是这个角色的标识符，at是这个角色的属性，τ是角色属性的类型，μat是在从at到dom(τ(at))的部分映射。

行为集合a中的一个行为action＝(cac，τ，d)，cac是标识符，τ是动作的类型，d是动作的描述。

2.基于已定义的业务概念，定义需求中所有可能出现的业务场景，以及业务场景之间的连接关系；

本方法中，一个场景scenario＝(cs，e，p，e)，其中cs是标识符，e∈ro是场景中角色的执行者，p是场景执行的前提条件，是条件的一种，e是场景结束后的影响。

场景中的影响effect＝(ε，ρ，μep)，其中ε是一个条件，ρ是关于cs的一个场景的集合，μep是一个将每个条件分配到场景的映射。

3.基于已定义的业务概念，定义需求中所有可能出现的业务流程；

本方法中定义了流程process＝(cp，o，r)，其中cp是流程的标识符，o是操作的集合，r是操作之间的关系集合。

操作集合o中的一个操作operation＝(cop，act，σ)，其中cop是操作标识符，act∈a是预先定义的动作概念，σ∈ro是动作act的操作对象。

关系集合r中的一个关系relation＝(cre，from，to，∈)，其中cre是关系标识符，from和to是关于cop的操作的名称，∈是关系成立的条件。[def：关系]

4.基于已定义的业务概念，定义需求中所有可能出现的业务规则；

本方法中的业务规则rule＝(cr，∈，o，τ)，其中cr是规则标识符，∈是规则生效的条件，o是关于cop的相应的操作，τ是规则的类型。

本方法中关于三种规则类型的说明：

operationrule(操作规则)：操作规则用于表示对应条件∈为真时可以执行操作o。

attributerule(属性规则)：属性规则用于表示，如果对应条件∈为真，则与操作o必须已经被执行。

triggerrule(触发器规则)：触发器规则用于指示只要相应条件∈为真，操作o将自动执行。

5.整合业务概念、业务场景、业务流程、业务规则，形成业务需求。

本方法中的单元需求requirement＝(creq，s，p，r)，creq是单元需求标识符，s是基于γ定义的场景，p是基于γ定义的流程，r是基于γ定义的业务规则。

本方法中的业务需求businessrequirement＝(c，γ，req)，c是业务需求标识符，γ是关于cco概念的集合名，req是一组关于creq单元需求的集合。

下面以养老健康领域中上门问诊的业务作为例子，具体说明本发明的技术方案。此处是一段需求节选：“上门问诊的基本业务流程为医生到老人家中进行问诊。系统需要预先导入医生的姓名、年龄、专业，以及患者的姓名、年龄、病史。医生在病人家中先进行问诊，记录结果，没有经过问诊，系统不允许医生开出药物，然后给患者开药并生成药单，医生开药时如果问诊没有完成也是不允许的，如果老人有所好转，则可以开始返程，如果病人病情加剧，则马上拨打120并执行急救措施。如果老人不在家则终止。”

可以看到，这段需求描述中，出现“老人、病人、患者”等在此业务中多词一义的情况，另外姓名、年龄、专业、病史等数据的存储类型有所缺失，描述缺乏逻辑，线下场景转移描述混乱。

以下是本发明的技术方案的描述。

1.业务需求建模，使用上述建模优选方案

2.描述业务概念

2.1描述角色概念

{医生，姓名：字符串，年龄：数字，专业：数组}

{患者，姓名：字符串，年龄：数字，病史：字符串}

2.2描述角色行为

{问诊，主动，询问患者状态并记录到系统中}

{开药，主动，给患者开出处方并生成药单}

{急救，主动，拨打120并查询实施急救措施}

3.描述业务场景

{患者家，医生，患者在家，{患者家的影响，患者好转，返程}}，表示该有业务场景为“患者家”，业务执行人为医生，场景准入条件为患者在家为真，当场景结束时患者好转的话则进入返程的场景。

4.描述业务流程

{上门问诊流程，{{问诊操作，问诊，患者}，{开药操作，开药，患者}}，{{关系1，问诊，开药，病情明确}}}，表示在上门问诊流程中，存在向患者进行问诊、开药两个操作，且两个操作的顺序为先问诊，病情明确的情况下，可以开药。

5.描述业务规则

{开药规则，病情明确，开药操作，操作规则}，表示在病情明确的情况下，系统中的开药操作才是可执行的。

{开药规则2，执行开药操作，问诊操作，属性规则}，表示执行开药操作时，问诊操作必须是已执行状态。

{急救规则，病情加剧，{急救操作，急救，患者}，触发器规则}，表示如果患者病情加剧，则自动执行急救操作，对患者进行急救。

6.形成业务需求

{上门问诊业务需求，上门问诊概念集合，上门问诊单元需求集合}

上门问诊概念集合为{概念集合1，医生，患者，问诊，开药，急救}。

上门问诊单元需求集合为{单元需求1，患者家，上门问诊流程，{开药规则，开药规则2，急救规则}}。

此外应理解，在阅读了本发明的上述描述内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所附权利要求书所限定的范围。