Use Case与MFQ&PPDCS相似性剖析

发表于二月 13, 2018

记不清是几年前买的《编写有效用例》(英文《WritingEffective Use Cases》)这本书,总之它一直静静地躺在我的书架里休息,直到近几日,才一时兴起,认真咀嚼了一翻。这一读,让我大吃一惊,原来UseCase与我提出的MFQ&PPDCS,在分析需求的思路上二者极为相似,本文就细数一下这些相似点。 

 

介绍

1. Use Case

 

用例是什么?引用书中的定义:“用例是系统中各个项目相关人员(stakeholder)就系统行为所达成的契约。

 

通常(when,如果一个项目使用用例的话,那么业务人员、需求分析人员、开发人员(who可以使用编写用例的方式来挖掘需求、讨论需求、分析需求、记录需求(what

 

虽然可以用流程图、顺序图来表示用例,但作者AlistairCockburn认为“从根本上说,用例是文本形式的”、“简单的文本通常是编写用例的首选形式”。

 

相比于传统的购物清单式的需求列表,用例这种叙述式的需求描述更易于理解。“用例通常是作为一种捕获需求和对已知的功能性需求进行建模的方法被使用。

 

2. MFQ&PPDCS

 

什么是MFQ&PPDCS?简单地说,MFQ&PPDCS是我在2008年提出的一套测试分析与测试设计的框架,详见这本书《海盗派测试分析:MFQ&PPDCS》。

 

通常(when,如果项目使用了MFQ&PPDCS的话,测试人员(who会用这套框架来学习需求、分析需求(what,以及据此设计出最终的测试实例。

 

相比于传统的重文本描述、重流程的测试分析与测试设计方法而言,MFQ&PPDCS以轻量型的图形化表达方式为主,无论是KYMTCO的思维导图、还是Modeling用的各种图表格式,均强调以轻快的图形来代替大量的文本,记录那些对了解需求与分析需求而言最重要的信息。只有在测试设计阶段、而且项目认为绝对有必要花费更多精力开展测试设计的时候,才使用文本的形式出具一条条具体的测试实例。

 

所以,MFQ&PPDCS以图形化表达方式为主,而用例以文本叙述的表达方式为主,这是二者很大的不同,但在学习或挖掘需求、分析需求的思路上,二者却有着极为相近的地方,下面就重点聊聊这一块。

 

相似性剖析

1.     从精确度上,由粗到细、分层次地进行

 

精确度(precision)是指对所关心内容的表达程度。”编写用例时可按照如下4个精确度等级由低到高、由粗到细、分层地进行:

Level 1执行者和目标

Level 2用例概述和主成功场景

Level 3失败情况

Level 4失败情况处理

 

 使用MFQ&PPDCS了解需求、分析需求时,有三个大体的步骤,从精确度上看也是个由粗到细、分层次进行的过程:

 

KYMKnow Your Mission,了解whowhy,也即了解执行者和目标,同时对what 也就是SuDSystem Under Discussion)有个大致的了解;

TCOTesting Coverage Outline,了解what,这一步是对SuD更细致些的了解和分析,TCO后会将SuD分解为多个单功能M

Modeling:对每一个单功能M建模,首先是对M有个概要的描述,确定M的范围,然后在对其建模,无论选用PPDCS哪一种模型,都要先考虑主成功场景,再考虑各种异常的失败处理情况

 

针对单功能M建模时,PPDCS中的第一个P代表Process,即通过画出流程图来建模,也可以用文字描述每一个主场景(MainFlow)和辅场景(AlternativeFlows),这就与UseCase非常像了,只不过一般我不建议用太多的文字来描述(这主要是考虑投入产出比,当然也存在开发与测试工作目的性的不同而导致),所以即使用文字来描述场景时,也不会像正式的UseCase那样有太多的字段。

 

在这个相似性下,二者也有两个明显不同的地方:

 

一是,使用用例建模,针对的对象可以是一个单功能,可以是一个特性,也可以是整个系统;而MFQ&PPDCS主张将SuD划分到足够细的粒度时(也就是单功能M),再针对每个单功能建模,针对特性或系统一级的SuD,最好先用KYMTCO开展分析(当然,这只是我的建议,实际上就MFQ&PPDCS本身的方法而言,也可以应用于整个系统的级别)。

 

二是,针对单功能M建模时,MFQ&PPDCS强调一个选择模型的过程,根据SuD的不同特点,分别有五类建模方法即PPDCS可以选取;而用例方法,相当于PPDCS中的P-Process方法,所以建模方法单一(作者也在书中最后表明,并不是所有需求都适合用用例形式描述,对涉及到执行者相互作用的需求是非常适合用用例描述的)。我想,这也与开发与测试工作的目的不同有关吧,当从无到有挖掘需求、了解一个新事物时,一切还都处于模糊未知的状态,理清处理流程确实是一个不错的开端,也易于使用;而对于测试人员来说,大多数情况下,是学习了解一个已经存在的需求,当然也可以用流程图方法,但是更重要的是运用逆向思考的方法、挑剔地问问题、找出那些值得测试关注的场景,而不同的模型会帮助测试人员以不同的角度思考问题,各有所长。

 

2.     从应用场景上,可以多种多样

 

用例,作为一种编写形式,能够在项目组中激发对目标系统的讨论。项目组可以用用例来记录实际需求。。。可能会用用例来记录他们的最终设计结果。上述活动既适于支持大到整个公司系统,也适于支持小到软件应用程序的一个片段。

 

业务过程人员编写业务用例描述业务的操作;而硬件或软件开发人员编写系统用例来描述需求;设计人员可能会另外编写一些系统用例来记录他们的设计结果,或者用例进一步分解子系统的需求。

 

对于这句话“能够在项目组中激发对目标系统的讨论”,我无法同意更多。实际上,我一直以为,无论是用例还是MFQ&PPDCS,甚或是其他的什么方法或框架,比如UserStoryImpactMapping,其最大的价值就在于能够促进成员对SuD的讨论,从而增进对目标系统的认知,至于是否严格遵循某个方法或框架的流程定义、最终的产出件的质量有多高、书写的有多完整等等,这些方面通常远没有人们认为的那么重要。毕竟,只有参与的“人”对需求的认识提高了、理解更深刻和完整了、对问题考虑得更全面了- 也就是“人”本身经过需求挖掘需求分析工作已经升级为更高level的“人”了 - 才有可能在后续的开发或测试工作中有高质量的产出。

 

与用例一样,MFQ&PPDCS可以应用在多种多样的场景中。无论是在项目的哪个阶段,当你第一次接触一个新的特性新的系统时,都可以使用KYMTCO 帮助理解上下文、理解用户及其目标、理解产品需求;无论是开发人员还是测试人员,每当你遇到一个稍微复杂些的逻辑时,都可以运用PPDCS中的某种建模技术帮助你理清其中的逻辑,顺便提出几个有挑战的问题,关于这点,可以参见这个案例“我和91的一次小练习”;当然,项目组也可以用KYM+TCO+Modeling记录需求。

 

3.     从范围上,明确区分

 

当业务人员描述需求时,是从业务的角度出发的,故其中既包含了业务的需求也包含了计算机系统的需求,这时就要明确区分出范围来。

 

范围(scope)一词用以描述项目开发人员负责的设计工作的边界,以便与应由其他人负责的设计工作或已经完成的设计工作相区别。

 

Use CaseMFQ&PPDCS中都首先进行了范围的区分,不过用例中的范围区分明显做得更胜一筹,尤其是《编写有效用例》的第三章讲到的用“内/外列表”标识功能范围和用图标(辅以设计框图)突出设计范围的做法,更是让我拓宽了思路。作者主张为了消除项目成员对范围的误解,列出每一个用例的设计范围,以及为系统的最外层范围(outermostscope)设计用例。

  




MFQ&PPDCS中是随着待分析的SuD精确度的逐步细化来逐步区分范围的:在KYMKYProd(了解产品)环节,会考虑ScopeExclusions(这一般是特性一级);在TCO后会划分出MFQ各自大致的范围;在建模时,针对每个单功能M,会先通过一个Brief进一步明确M的范围(类似地,UseCase也会使用2~6句话的用例简述描述用例行为)。

 

4.     从价值上,识别用户目标


Weinberg大师对质量的定义是“Qualityis the value to some person.”要交付高质量的产品,就是要交付对用户而言有价值的产品。实际上,软件项目组交付的并不是一个个的功能(Function),真正交付的是价值(Value)。所以,无论是业务人员、开发人员还是测试人员,都要对价值有准确的认知。

 

谈论价值,就是要探讨WhoWhy的问题,这个产品对谁重要、为什么重要?

 

探讨价值,依我目前的认知看,可以在三个层次上进行。

 

层次一,是从整个系统的角度考虑价值。识别系统的利益相关人以及他们各自关心的利益,这种考虑虽然很粗泛,却是后面两层用户价值的总纲。KYM中虽然在KYC环节中,也会首先跳出当前所讨论的特性,站在系统或产品的层面,询问用户及用户的价值,但这个过程还是比较随意,不系统。

 

一种站在较高的角度考量、同时也是比较系统的考虑WhoWhy的做法是影响地图,详细做法可以参考《ImpactMapping》这本书,我这里想重点提另一种比较新颖的方法。

 

前一阵子听王小刚老师的《有效需求分析训练营》的课程,被我挖到了一块宝,小刚老师提出的BBR模型(Bangmang-BuReshi模型)正好可以用来做这个层次的价值分析。

 


举个例子,前几天和一个测试人员小C聊起,他提的bug经常被开发人员和产品经理打回,要求关闭,理由多种多样,比如“这个问题不在本项目范围内”,“这个问题是其他模块的,这次需求不涉及这个模块”,“这个问题是老问题了,一直就这样,不用修改”等等。

 

为了让正确的问题得以重视并优先修复,于是我和小C结对做了这个小练习:对所在产品做了个BBR分析,识别出产品的支持者、团队对象、反对者和中立者。然后我们选中一个bug来分析,这个bug的大意是用户的权限没有做明确的区分:业务员A可以查看并修改业务员B下面的用户订单信息。由于这是老版本中存在的问题,产品经理和开发人员要求关闭问题。可是,借用BBR模型,会发现这个问题会损害项目的主要干系人、也是这个系统的支持者、也是此项目的需求提出者的利益,即公司的VP,而业务员应该处于第三象限。于是小C在适当的时机向VP描述了这个bug,果然,VP要求立即修改。

 

层次二,是从特性的角度考虑价值。这是KYM最为擅长的地方,在Know Your Customer环节,首先要识别用户群体,可以用“CUSHeuristic,分别从CustomerUserStakeholder的角度考虑涉及到的不同用户,然后考虑每一个用户使用本特性的目的、帮助他们解决什么问题、带来什么样的影响、用户会在哪些场景下使用本特性、用户有什么特别的需求等等。 

Use Case中“执行者-目标”模型也是在分析用户及给用户带来的价值,虽然是站在系统的层面,但是由于关注的任务级目标,所以视角与BBR模型并不一样。


 

层次三,是从具体的需求层面考虑价值。这个在MFQ&PPDCS中,没有明显的对应做法,也就是说,在每一个MFQ的建模分析时,并没有特别强调再去分析对应的用户及给用户带来的价值,而是依赖于测试人员,也就是说,每一个测试人员在具体的建模分析的过程中,都要时时刻刻站在用户角度思考、问问题、考虑测试场景、考虑相应的风险等,以便开展基于风险的测试。

 

而在UseCase中,是有显式的做法的:即“项目相关人员和利益”模型,在每个用例里,“列出所有的项目相关人员和他们的利益,并用这个列表进行仔细的检查以确保用例中没有任何内容被遗漏。这个微小的改动却能对用例的质量产生重大的影响。


用例的场景由执行步骤组成。“在成功场景中,项目相关人员的所有(一致)利益都通过系统有责任实现额服务而得到满足。在失败场景中,那些利益都根据系统的承诺而得到保护。当项目相关人员的所有利益都得到满足或得到保护时,场景就结束了。

 

当然,这段话中所述的“一致”二字我个人持有保留意见,从上文的BBR模型不难看出,支持者和反对者的利益是很难保持一致的。

 

除了UseCase,在具体的需求层面,对用户价值分析比较到位的工具还有UserStory,那个著名的“作为。。。我想要。。。以便于。。。”句式中,“以便于。。。”的部分其实就在述说用户的目标,是很重要的价值分析部分。只不过,据我个人接触的项目而言,遗憾的是实际项目的UserStory质量往往差强人意,对用户的价值并没有准确的描述和分析。

 

从系统、特性和需求层面都了解清楚WhoWhy,对用户及用户的目标有足够的认识,无论对开发人员还是测试人员后续的设计和实施部分都有着不可估量的价值,能让我们准确识别工作优先级,输出更高质量的HowWhat

 

5.     从对象上,区分所在层次

 

用例场景中的交互“可以根据需要被折叠或分解,就像目标能大能小一样。场景中的每一步都捕获一个目标,因此每一个都可以被展开,而成为一个单独的用例。。。用例常常被看做是一个可以不断展开下去的故事。

 

为了解决用例编写者经常面临的问题“我应该描述哪个层次上的目标呢?”,作者给出了三个命名的目标层次:概要目标(白云需求)、用户目标(风筝需求)、子功能(规格需求)。



海平面/蓝色用户目标极为重要,因此值得花大力气去理解它们,为它们编写用例,当然,在海平面以下和以上的部分都有可能要编写用例,于是可以用白云、风筝、鱼这样的小图标标明用例所在的层次。

 

MFQ&PPDCS中存在类似的思路:KYM时也会了解SuD,这时对需求的理解比较粗略,只能算是白云级需求的程度;到了TCO时,对SuD了解得更加细致了,但是也只是能据此划分出具体的单功能来,对每个单功能M,可以知晓其大概的范围、涵盖的主要规则或流程、主要的功能,这基本上对应到风筝级需求的程度;然后在Modeling时,对每一个单功能M就要细致的分析了,理清每一条逻辑、每一种正常异常的场景、每一个涉及到的变量,对应到规格级需求的程度。

另外,应用PPDCS建模的人员,也会常疑惑“我应该在哪个层次上建模呢?”理论上,可以运用PPDCS在任意一个层次上建模,小到一个函数、大到一个系统,只不过我们认为M非常重要,值得我们花大力气为每一个M建模。

 

但是一定要知道,M(单功能)和F(功能交互)的概念是相对的,任何一个M都可以再被细分为更小的M,这与上面提到的用例也可以被不停的细分下去是一样的道理。

 

结束语

  • 其实,无论是Use Case,还是MFQ&PPDCS,甚或是其他的需求分析类的工具如UserStory,这些方法本身所定义的形式、流程等并不那么重要,重要的是提供了一种思路去探索未知的、模糊的需求,提供了一种方式去记录一路学习到的、重要的信息,提供了一个机会促进参与者之间的沟通交流、从而升级自己的认知

  • Use CaseMFQ&PPDCS无论对开发人员还是测试人员而言,在需求阶段可以发挥很大的作用,包括需求的挖掘、需求的分析、需求的记录等;但是它们并不擅长表示设计与实施阶段的很多细节,比如那些数据需求、接口需求等。

  • 如果您应用了Use CaseMFQ&PPDCS,并且取得了不错的效果,记住:那不是这些方法或框架本身的功劳,功劳完全应该归功于您,只有具备了相应的分析技能的人员,才能取得好的成绩。所以使用Use CaseMFQ&PPDCS的过程,其实是在训练您的分析技能,记住这点尤为重要。

附录:KYM最新图示


Comment Box is loading comments...