首页 > 代码库 > 关于用例需要多少文档以及业务用例等等

关于用例需要多少文档以及业务用例等等

2024-07-06 01:37:26   231人阅读

整理者：张克强

缘起

@jackyrong 发了如下一条微博

敏捷中的文档该写多少合适，一直是永恒的话题，每个用例故事的设计简要卡片，用例图，序列图，类图，数据字典，简要原型图，算法补充说明，应该是必要的吧，大家可以继续探讨 @袁斌_AgileDo @竹十一 @敏捷广州联盟 @火球_Fireball

| 转发(58)| 收藏| 评论(35)
5月16日

张克强-敏捷307：这些都写了，那不就是RUP了？ (5月18日 17:37)

    jackyrong：回复@张克强-敏捷307:那倒不一定，看的是写的侧重和“度”的问题 (5月18日 17:48)

张克强-敏捷307：注意到用例故事这样的组合，上次@agile123 也提到了用户故事，源自于何处？目前有什么定义或者说明吗？ (5月18日 17:51)

    agile123：“用例故事”好像是源于特级资深敏捷教练张恂老师的《用例故事胜过用户故事》这篇文章吧，简单说用例故事是Use Case的中文别称，因为用例本就是故事，比用户故事出现更早、更成熟的需求故事 http://t.cn/RvwEJ4h 

    agile123：#统一用例方法#UUCM提倡在敏捷开发中用Use Case Card取代User Story Card，卡片上可放用例名称、用例图、用例简述（相当于XP用户故事）、优先级等信息，其他如需求文档、架构文档则是必须的 

焦点问题的出现

火星人陈勇：第一级应该是“有什么”图（建议用例图，但真心不好用），辅以简单故事卡描述；还有时间，银行推荐业务逻辑图（泳道、序列），互联网推荐界面原型；还有时间，才画类图等与实现相关的。不过，与其画UML，不如加入一些别的东西。比如写扩展流不如写Gherkin。 (5月20日 16:07)
【注意：@火星人陈勇说的是 第一级】
张克强-敏捷307：回复@火星人陈勇:赞同勇哥，rup中的业务用例以及业务用例图就是真心不好用的典型。还不如最传统的功能模块图，不过uml的活动图和序列图优于传统的流程图。rup中业务用例-业务用例实现-用例-用例实现真是让人无语，吓退n多骚年。雅格步森大师自己境界太高了，真是太高估业界骚年了。 (5月20日 20:58)
火星人陈勇：回复@张克强-敏捷307:用例图有几个大问题：1. 只能用来记录发现的用例，不能用来分析出用例；2. 没有直观方法看出“已经列出了所有必要的用例”，很容易遗漏； 3. 用例七大八小； 4. 用例之间的关系极其模糊。而且UML并没有其他配套图形协助用例图解决这些问题。一起大赞序列图。 (5月20日 21:06)
【按照陈勇和我微博的上下文，我们讨论的对象是第一级和业务用例、业务用例图】

争论的出现

agile123：胡说，业务用例（相当于business process）与功能模块是一回事么？用例是以用户为中心分析出来的系统服务价值单位，优于传统功能分解。两位学习用例技术其实还没入门 [弱] 
UMLGreatChina：回复@火星人陈勇:怎么没有直观方法？画在一张用例图里的就是所有必要的用例，一目了然，还不直观？如果嫌空间小，可以换A3纸或者更大的屏幕、图纸，把“所有必要的用例”都装下 [嘻嘻]  //2. 没有直观方法看出“已经列出了所有必要的用例”
UMLGreatChina：回复@火星人陈勇:这也不是什么缺陷。需求本来就有大有小，有粗有细，用例的分层不过是对这种复杂客观现实的反映，而且通过用例分层技术可以把大大小小各种不同粒度的需求整理得非常清楚而有条理 //3. 用例七大八小
UMLGreatChina：回复@火星人陈勇:这根本不是个问题。用例图（diagrams）只是一个表达形式和结果，如何分析出用例要靠用例分析的方法（methods），如UP、Jacobson、Cockburn、UUCM等，你只学了图，不学方法怎行？这逻辑不对 //用例图有几个大问题：1. 只能用来记录发现的用例，不能用来分析出用例 @张克强-敏捷307 (5月21日 11:08)
UMLGreatChina：回复@火星人陈勇:解释起来其实很简单，C语言的include、Java类的extends你总熟悉吧意思差不多：包含是公共功能，扩展是附加功能。你认为极其模糊是因为你学用例还没入门，一知半解，不得要领 //4. 用例之间的关系极其模糊。而且UML并没有其他配套图形协助用例图解决这些问题。@张克强-敏捷307 (5月21日 11:21)

关于业务用例

@张克强-敏捷307:业务用例与功能模块不是一回事，但业务用例与用例也不是一回事，业务用例能够帮助理解用例的背景，但其有@火星人陈勇 说的那些问题。
张克强-敏捷307：回复@UMLGreatChina:注意我一直说得是业务用例与业务用例图有蛮多问题。对用例和用例图可是很推崇的。真不建议你再去弘扬业务用例。 (5月21日 11:04)
UMLGreatChina：既然你也推崇用例，那就没理由反对业务用例啊。UML需求用例分析的精妙在于用同一套思路方法同时来做系统和业务建模，只不过把boundary扩大到业务组织。你说BUC到底有哪些问题？
       @张克强-敏捷307:业务用例的关键问题就是边界极为模糊啊，范围写大了浪费时间，写小了可能漏，写细了与用例重复，写粗了与功能模块划分没区别,，无论如何写都不合适。用几张泳道图或者序列图把核心业务流程表达就足够了。把有限的时间直接放到用例上。
                       UMLGreatChina：没这么难吧，scope是从一开始就应该确定的，BUC的概念无非是把边界扩大点，除system外把human的活动也考虑在内。估计是你没掌握技巧，最好举个困难的例子？
                          张克强-敏捷307：关键不是难度，关键在于其意义可以被更经济的替代。而且其业务用例本身没有合适的规范，一旦开写，不同角色可以从不同角度提不同意见，麻烦多多。    
                           UMLGreatChina：你的意思是不要写业务用例的文本细节？可以，要不要业务建模、业务用例这都要看项目的实际情况，的确业务建模可以画图为主，简单的用UML活动图甚至BPMN等就够了，但是许多复杂的业务流程只画图可能不够。It depends 
                           UMLGreatChina：是否要写业务用例文本要看项目需要ROI，通常金融业务系统只画图不够。至少一个公司内部应形成需求用例的标准，我的UUCM模板可供参考  
@张克强-敏捷307:我认为业务用例图有蛮多不足，但用例和用例图绝对是uml&rup的精髓。通过用例图、角色和系统边界识别用例是行云流水般的思考，远远优于传统的需求规格书，我很享受这种过程，能够充分体会用例之美之优雅。

关于未来

火星人陈勇：应该这么说，我（们？）正在尝试消灭功能模块，只留下业务用例，把业务用例作为分析、设计、开发、测试、验收的共同单位（很类似BDD或者FDD吧），因此”留下“的东西要继承”砍掉“的东西的一些特性。 (5月21日 13:44)
                   agile123：UP、OUM、Taij/UDD等都是用例驱动的，而ATDD、BDD加用户故事的意思其实差不多，但后者受极限派影响是不敢或不便提UseCase的，这就是科学家之间的门派之争 
火星人陈勇：哦，不是这个意思，我是说比如在百度”用例图“前三张，（作为外行）是否能看出里边缺少了什么用例？包括他画在别的图里边的。利用一种新的东西（其实还是用例图的变形，但配合了FPA、MVP），我现在就能找到缺少的东西，甚至能告诉他缺少的东西叫什么好。这个以后再揭秘。 (5月21日 13:52)
火星人陈勇：如果有一种图，图中的元素大小相近，而又能分层把不同颗粒度的……是不是更好？我称之为有根有叶树，有根就是你说的整理地非常有条理，有叶则是存在一种大小相似的东西（自然界同种的树尺寸差别很大，但叶子却差不多），作为最终需求、估算、设计、开发、测试、验收、度量用。
火星人陈勇：在我们看来，用例和用户故事史无前例地采用”条目“而非大段文字表述需求，已经达到”历历可数“的状态，可惜数完了却被告知尺寸不一，因此无法把用例放在分母上得到生产率、缺陷率、测试覆盖率……等，实在可惜。若此问题被克服了，将对用例的价值有很大提升。但这就要动用例的一些规则。 (5月21日 14:00)
火星人陈勇：等回头看”用例-状态图“吧，10分钟教学，10分钟练习（之前不用任何UML基础），6个团队绘制6张他们的图，一般有2张图我找不出漏了什么，2张图漏东西，1张图惨不忍睹。 (5月21日 14:03)
火星人陈勇：我做下一个月迭代的时候最关心的是：”这一大堆用例里边，哪些拿出来，正好满足两个条件：1. 开发出来的东西完整可交付（不多，不少，MVP）；2. 正好一个月开发完（可估）。“1. 需要能看到用例之间的一种依赖、内聚关系，包含、扩展没用；2. 需要有相近颗粒度和生产率 (5月21日 14:14)

火星人陈勇：图先不着急，我可能要自己绘制超过100张才会有足够稳定的图发布。但在发图之前，我想知道有没有人和我一样感受到用例图的4个问题（或者对现有解决方案不满意的地方），以及有何尝试。就像现有的UML会限制思维，我的图也一样。 (5月21日 14:21)
火星人陈勇：给个提示：2月份和一个资深朋友聊，我说我喜欢用例，因为和用户故事、功能点能做很好的对应。他说他会先画状态图，因为可以不多不少地分析出用例（状态图的线条其实就是某些用例），我大吃一惊……1个月后，就有了我说的那张图。 (5月21日 14:27)
火星人陈勇：@UMLGreatChina @张克强-敏捷307 @敏捷123 我当前正在同时使用UML，FPA，用户故事，BDD四者管理需求。我个人感觉与其讨论“哪个更好”（到处都是），不如取长补短。所以要去掉三个，留下一个。所以现在说的“找缺点”，不是说找到缺点把UML扔掉，而是留下并改造它，去掉另外几个。 (5月21日 16:32)
       UMLGreatChina：这思路不错，UML、UseCase、UDD完全可取代用户故事和BDD 
  
        火星人陈勇：UML的战线最长，工程化程度最高，因此作为一个基础在其上扩展比较容易（甚至有时候是做减法），其他几个都是点状的，无法承载“过程”“模型”等这些词汇；不过不改造还是有一些不足。
            UMLGreatChina：的确这是一个技术路线问题，这些年OO方法技术一直是主流
火星人陈勇：回复@张克强-敏捷307:嘿嘿，下次见面我画个“用例-状态图”，体验一下跟头云的感觉。不过最近想和精益的MVP（最小可用产品）结合一下，从外界重新分析一下，也重新命名一下。MVP听名字就比“用例-状态图“外向地多，商业地多，有价值的多，视野开阔地多。
火星人陈勇：回复@张克强-敏捷307:长相更像用例-活动图，因为发生在用例之间而非之内，所以叫用例-状态图更妥。此图用来找出用例；绘制完成后会知道”完成了“；两个人绘制的图几乎一模一样；平均每张图开发工作量35人天；看着图能写出测试用例（群），还能知道写完了没有；每张图是一个迷你MVP，必须完整发布……

结语

张克强-敏捷307： 说了这么多，其实还没有直接回答原博主的提问。我来回答下吧：在敏捷环境下，如果只使用用例表达需求（不联合使用用户故事），那么围绕用例必须的文档是用例图和用例规约（不一定要正式的）+数据字典。 其它的不是必需的，依赖于团队对UML和OOAD的认识和水平，但就算团队对UML和OOAD有很高水平, 见续
张克强-敏捷307： 如果把以上提到的全写了，覆盖所有类，而且没有一个强大的支持正反向工程的UML工具，那么多半是不敏捷了。 (10秒前)

其它

袁斌_AgileDo：我目前在需求的分析中，主要是把需求分为系统级需求、架构级需求、开发级需求，不同级别的需求在不同阶段完成，其中前两个在先启阶段完成，后一个在构建阶段提前一个迭代完成 (5月22日 09:31)


联系
我们