一种结构化需求用例自动生成方法及装置与流程

本发明涉及计算机领域，尤其涉及一种结构化需求用例自动生成方法及装置。

背景技术

互联网研发中涉及到的需求各种各样，通常以需求记录的方式呈现。如图1所示，需求记录通常以文档为载体，主要涉及需求的背景、需求的流程图以及ui交互流程。这种需求记录难以用于自动化分析，并且还存在下述弊端：

(1)没有说明完成需求这个功能需要哪些系统来辅助完成；

(2)需求在实现过程中考虑了哪些人的利益无从考证；

(3)很多情况是一个示意或一个流程，不能清楚的表达在需求实现过程中设计的业务规则；

(4)在很多情况下，需求仅仅从用户角度提起而并不考虑执行需求的系统，因此，机械地把多个从用户角度使用的功能耦合在一起，开发好的系统不利于用户的使用；

(5)缺乏对系统安全性、可用性、性能的明确要求，开发出的系统欠缺性能管理，从而对用户或公司的利益造成损失。

技术实现要素：

为了解决上述技术问题，本发明提出了一种结构化需求用例自动生成方法及装置。本发明具体是以如下技术方案实现的：

第一方面，一种结构化需求用例自动生成方法，包括：

获取需求记录；

对所述需求记录进行结构化分析，并构建所述需求记录对应的模型；

根据所述模型输出所述需求记录对应的结构化需求用例。

第二方面，一种结构化需求用例自动生成装置，包括：

需求记录获取模块，用于获取需求记录；

分析模块，用于对所述需求记录进行结构化分析，并构建所述需求记录对应的模型；

输出模块，用于根据所述模型输出所述需求记录对应的结构化需求用例。

第二方面，一种计算机可读存储介质，用于存储程序，所述程序用于实现所述结构化需求用例自动生成方法。

第三方面，一种服务器，所述服务器用于运行所述结构化需求用例自动生成装置。

本发明提供了一种结构化需求用例自动生成方法及装置，具备下述有益效果：

本发明能够通过结构化分析把需求进行结构化表述，依据本发明实施例中描述的结构化分析方法得到的需求用例能够清晰地表达出需求的具体内容和需求的原发动因，从而可以让产品的研发人员以一种逻辑严谨的语言进行沟通，从而极大地提高了研发的效能。

此外，结构化的需求用例通过清晰地表达需求的原貌，减少沟通误差，满足涉众的要求，让系统的要求更能满足涉众的利益。通过让需求的表述更加的完善和规则，减少研发人员因为不同的需求格式导致研发效率降低的情况，从而使得产品在研发过程中的沟通效率更高。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1是本发明背景技术提供的以文档为载体描述需求的示意图；

图2是本发明实施例提供的一种结构化需求用例自动生成方法流程图；

图3是本发明实施例提供的结构化分析规则示意图；

图4是本发明实施例提供的扫码充值过程中的交互过程流程图；

图5是本发明实施例提供的在未配置可扫码员工时的ui界面示意图；

图6是本发明实施例提供的配置过卡扫码名单的商户号后超管看到的ui界面示意图；

图7是本发明实施例提供的在名单中的员工看到的ui界面示意图；

图8是本发明实施例提供的非名单中的员工看到的界面示意图；

图9是本发明实施例提供的一种结构化需求用例自动生成装置框图；

图10是本发明实施例提供的服务器结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明实施例提供一种结构化需求用例自动生成方法，如图2所示，包括：

s101.获取需求记录。

具体地，所述需求记录具体为提供需求的一方对于需求的描述。所述需求记录可以使用任意表达方式进行表述，包括但不限于文档、语音、视频和图片。

s102.对所述需求记录进行结构化分析，并构建所述需求记录对应的模型。

具体地，所述结构化分析可以按照预设的结构化分析规则执行。所述结构化分析规则用于对需求记录进行自动化建模。在建模过程中，依据所述结构化分析规则提取所述需求记录中的需求要素并获取各个需求要素之间的关系。

具体地，所述自动化分析规则可用于构建模型的静态结构，所述自动化分析规则包括属性以及各个属性之间的关系两部分内容，所述各个属性之间的关系可以存在下述情况：泛化、实现、依赖、关联、聚合和/或组合。

泛化指的是一个属性继承另外的一个属性的内容，并可以增加它自己的内容；依赖就是一个属性(a)依赖另一个属性(b)，属性(b)的变化会影响属性(a)；关联就是一个属性(a)强烈依赖另一个属性(b)，这种关系比依赖更强、是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；聚合是关联关系的一种特例，体现的是整体与部分、拥有的关系，即has-a的关系；组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；总的来说，后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖。

s103.根据所述模型输出所述需求记录对应的结构化需求用例。

具体地，本发明实施例提供一种结构化分析规则，所述结构化分析规则可以使用类图表示。如图3所示，本发明实施例中结构化分析规则包括第一属性组、第二属性组和第三属性组，按照所述结构化分析规则构建的模型以需求用例为输出；所述第一属性组为与所述需求用例构成聚合关系的属性形成的组合；所述第二属性组中的成员与第一属性组中的一个或多个成员之间为泛化关系；所述第三属性组中的成员与第二属性组中的一个或多个成员之间为泛化关系或者组合关系。

具体地，所述第一属性组中的属性包括执行者、涉众利益、前置条件、后置条件、路径和补充约束。其中所述执行者包括主要执行者和辅助执行者；所述补充约束包括字段列表、业务规则、质量需求和设计约束四个部分。其中设计约束包括平台约束、接口约束和ui约束；所述路径通过为实现所述需求用例所需各个执行步骤之间的执行流程来表达。

在一个具体的实施例中，用例的名称使用动宾短语表达，比如执行者使用系统干某个事情，通过涉众利益表达需求的来源，比如需求所涉及的法律、风俗习惯、以及需求设计的一方的既得利益。

具体地，本发明实施例中对于各个属性组中的各个字段进行详细解释：

(1)主要执行者：

主要执行者可以使用名词短语表达。所述主要执行者为与执行主体发生功能性交互的人或物。所述主要执行者不属于执行主体并且与执行主体发生的交互应当是功能性交互。比如售票员使用鼠标和售票系统(执行主体)进行交互，但执行者为售票员并不是鼠标，原因在于发生的交互是来自主要执行者的功能需求。

进一步地，所述主要执行者可以是系统：可以是人肉系统，也可以是智能系统，甚至是一个特别的外系统——时间。

(2)辅助执行者：

辅助执行者可以使用名词短语表达。所述辅助执行者是在交互过程中被动参与进来的，但是和主要执行者一样都是达到需求用例目标所需要的。如果辅助执行者不参与，需求用例一样可以达到所需要的目标(纵使体验差些)，那这个需求用例就没有辅助执行者。

以支付系统为例，其主要执行者可以是银行系统或支付完整注册用户，辅助执行者可以是营业用户在办理取款时，必须要储户输入密码，才能完成，营业用户就是在取款这一需求中还担任了辅助执行者的角色。

(3)前置条件：

前置条件必须是需求用例开始前，系统能检测到的为了实现所述需求用例必须满足的约束，且必须实在需求用例开始实施前系统能检测到的。例如：受理单笔退款的前置条件“商户账户中有足够钱“是错误的，因为需求用例开始前无法检测商户账户中的钱。

具体地，所述前置条件可以通过【系统】{已}*{动词}{名词短语}来表达，其中【系统】表示了前置条件的执行主体，{已}表示该前置条件应当是已经存在的状态。比如所述前置条件可以是已存在或已登录。

需要被强调的是，前置条件是约束，不是动作，例如：“系统记录完成支付的订单”是一个动作，不是条件，条件应该是“系统已记录完成支付的订单”。

(4)后置条件：

后置条件必须是需求用例按照路径走就能达到的，是系统能检测到的需要满足的约束，例如：收银员收银的用例中，后置条件“顾客已带着货物离开商店”，这个是系统无法检测的，因此不是后置条件。

具体地，所述后置条件可以通过【系统】{已}*{动词}{名词短语}来表达，其中【系统】表示了后置条件的执行主体，{已}表示该后置条件应当是已经存在的状态。比如所述后置条件可以是已保存、已更新、已创建、已生成或已记录。

(5)主路径：

执行者和执行主体一个个回合交互，直到达成目的，从而得到了主路径。每个回合的步骤分为四类：请求、验证、改变、回应。一个回合可以有四类中的2-4个，比如请求、验证，或者请求、验证、改变、回应。

主路径的主语只能是主要执行者或系统，比如：“【系统】干某事”，“直连商户干某事”。

写法：{编号}、{【系统】|主执行者}{状语从句}*{动词}{定语}{名词}[[{连接词}|，]{状语从句}*{动词}{定语}{名词}]*

{状语从句}：{介词}[{副词}]{形容词}{名词}[{方位词}]

动词具体可以为：校验、更新、记录、创建、生成、展示、反馈、提交、请求或发送。编号：编号只能为数字，例如1，2，3；其中状语从句举例可以为{向|从}合适的账户。路径以请求开始，回应结束，可以有多个回合，其中校验的路径的规则应有一条校验字段列表。

(6)扩展路径：

扩展路径是基本路径上系统要处理的意外和分支。不是所有的意外都是扩展(必须是系统能感知而且要处理的)。例如：“商户操作员心脏病发作”导致“受理申请代发提现退款”未完成，但它不是扩展，因为系统无法处理。扩展会出现的原因可以是执行者的选择的原因、业务规则的原因、系统验证的原因等。

需要提及的是，用户的选择不能被认定为扩展路径，比如选择验证支付密码、指纹支付，只是选项但是并不属于扩展路径，无论选择哪一个，都是验证身份。

写法：{编号}{子编号}、{【系统】|主执行者}{状语从句}*{动词}{定语}{名词}{不}*{形容词}*

子编号：只能为字母，扩展路径的扩展的子编号也只能为字母；

形容词可以是合法、合规、失败；动词可以是校验、更新、记录、创建、生成、展示、提交、请求、需要、查看。

在一种优选的实施例中，每个涉及系统展示、报错、提示、要求用户选择的扩展路径都自动生成有对应的ui交互图，ui交互图的编号和扩展路径编号一致；一个合法的业务规则应对应一个扩展路径，业务规则编号和扩展路径编号一致。

(7)字段列表：

系统的输入和输出都有字段列表，和主路径或扩展路径中具体的步骤相对应，字段列表的编号和路径的编号要对应起来。

写法：输入的字段列表包含：字段名字、是否必填、类型、长度、描述，输出的字段列表包含：字段名字、描述。

(8)业务规则：

请求合法性规则中应有一条校验字段列表的规则，一个合法性的规则对应一个扩展路径，规则编号与扩展路径一致。此外，还包括展示规则、报错规则、提示性规则、用户选择的规则。

(9)设计约束：

包含了接口、平台、ui设计约束，并且ui约束与具体的路径相对应.

通过上述对于结构化分析规则表述内容可知，通过将需求记录按照上述结构化分析规则进行分析，可以将需求记录转化为结构化的用例，从而完成了整个用例的结构化表述，清晰地表达需求的原貌，并且减少沟通误差，满足涉众的要求，让系统的要求更能满足涉众的利益。结构化需求用例的表达方式让需求的表述更加的完善、规则，减少研发人员因为不同的需求格式导致研发效率降低的情况，从而使得产品在研发过程中的沟通效率更高。明确的需求也减少了系统的重复开发，减少无用功，提升系统功能的对涉众要求的准确性。

为了更为清楚的表述本发明实施例中的结构化分析方法，本发明中通过具体的小微商户扫码充值进行举例，如图4所示，其表述的扫码充值过程中的交互过程包括如下动作：小微商户老板向支付账户充值、小微商户财务向支付系统配置扫码充值员工名单、支付系统更新可充值员工名单、小微商户财务获取支付系统充值二维码、小微商户财务向支付系统扫码付款、支付系统向银行系统付款，以及按照时间控制发生的支付系统的查单操作。

在上述几个需求中，以小微商户财务展示扫码充值界面的需求为例，进行结构化分析，得到各个属性的具体内容：

(1)主要执行者：商户操作员；

(2)涉众利益：

商户：希望能够安全、快速的使用微信支付为商户账户充值；

商户的操作员：在扫单充值名单中的操作员，可以顺利扫码；

微信支付负责人：仅限权限的人才能扫码充值，避免商户用此功能收单；

风控负责人：展示扫码充值界面时避免出现风控漏洞；

安全负责人：展示界面避免出现安全隐患；

客服负责人：展示界面及说明清晰，减少商户的咨询投诉，否则增加工作量；

(3)前置条件：商户操作员已登录；

(4)后置条件：无；

(5)主要路径：

商户操作员请求扫码充值；

【系统】校验商户操作员的登录态；

【系统】展示扫码充值界面；

(6)扩展路径：

【系统】校验商户操作员不具有登录态，跳转登录，用例结束；

(7)补充约束：

a.字段列表属性的内容如表1所示：

表1

b.业务规则属性的内容包括：

超管登录的提示信息展示规则如表2所示，超管登录且已经修改过一次可扫码充值名单后的规则如表3所示，操作员(非超管)登录的提示信息展示规则如表4所示。

表2

表3

表4

(8)质量需求属性的内容包括：可用性、性能、可支持性、安全性、易用性五个方面的内容；

(9)设计约束：

其中ui设计约束如图5-8所示，图5示出了在未配置可扫码员工时的ui界面，图6示出了配置过卡扫码名单的商户号后超管看到的ui界面，图7示出了在名单中的员工看到的ui界面，图8示出了非名单中的员工看到的界面。

本发明实施例中能够通过结构化分析把需求进行结构化表述，需求用例的结构化涉及用例名称、涉众利益、主要执行者、辅助执行者、前置条件、后置条件、路径、扩展路径、补充约束的方式表达，其中补充约束还包含了质量需求、设计约束，质量需求又包含性能、可用性、安全性、易用性的约束，依据本发明实施例中描述的结构化分析方法得到的需求用例能够清晰地表达出需求的具体内容和需求的原发动因，从而可以让产品的研发人员以一种逻辑严谨的语言进行沟通，从而极大地提高了研发的效能，提升整个产品的质量和成功率。

本发明实施例还提供一种结构化需求用例自动生成装置，如图9所示，包括：

需求记录获取模块1，用于获取需求记录。

分析模块2，用于对所述需求记录进行结构化分析，并构建所述需求记录对应的模型。

所述结构化分析按照预设的结构化分析规则执行；所述结构化分析规则用于对需求记录进行自动化建模；在建模过程中，依据所述结构化分析规则提取所述需求记录中的需求要素并获取各个需求要素之间的关系。

自动化分析规则用于构建模型的静态结构，所述自动化分析规则包括属性以及各个属性之间的关系两部分内容。

输出模块3，用于根据所述模型输出所述需求记录对应的结构化需求用例。

本发明的装置实施例中所述的一种结构化需求用例自动生成装置与方法实施例基于同样地发明构思。

本发明的实施例还提供了一种存储介质，所述存储介质可用于保存用于实现实施例中需要用到的的程序代码。可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络设备中的至少一个网络设备。可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

具体地，图10是本发明实施例提供的一种服务器结构示意图，所述服务器结构可以用于自动生成结构化需求用例。该服务器800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessingunits，cpu)822(例如，一个或一个以上处理器)和存储器832，一个或一个以上存储应用程序842或数据844的存储介质830(例如一个或一个以上海量存储设备)。其中，存储器832和存储介质830可以是短暂存储或持久存储。存储在存储介质830的程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器822可以设置为与存储介质830通信，在服务器800上执行存储介质830中的一系列指令操作。服务器800还可以包括一个或一个以上电源826，一个或一个以上有线或无线网络接口850，一个或一个以上输入输出接口858，和/或，一个或一个以上操作系统841，例如windowsservertm，macosxtm，unixtm，linuxtm，freebsdtm等等。上述方法实施例所执行的步骤可以基于该图10所示的服务器结构。

需要说明的是：上述本发明实施例的先后顺序仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

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