整理者：张克强
缘起
@jackyrong 发了例如以下一条微博
敏捷中的文档该写多少合适，一直是永恒的话题，每一个用例故事的设计简要卡片，用例图，序列图，类图，数据字典，简要原型图，算法补充说明，应该是必要的吧，大家能够继续探讨 @袁斌_AgileDo @竹十一 @敏捷广州联盟 @火球_Fireball
张克强-敏捷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. 没有直观方法看出“已经列出了全部必要的用例”，非常easy遗漏； 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：回复@火星人陈勇:解释起来事实上非常easy，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的战线最长，project化程度最高，因此作为一个基础在其上扩展比較easy（甚至有时候是做减法），其它几个都是点状的，无法承载“过程”“模型”等这些词汇；只是不改造还是有一些不足。
UMLGreatChina：的确这是一个技术路线问题，这些年OO方法技术一直是主流
火星人陈勇：回复@张克强-敏捷307:嘿嘿，下次见面我画个“用例-状态图”，体验一下跟头云的感觉。只是近期想和精益的MVP（最小可用产品）结合一下，从外界又一次分析一下，也又一次命名一下。MVP听名字就比“用例-状态图“外向地多，商业地多，有价值的多，视野开阔地多。
火星人陈勇：回复@张克强-敏捷307:长相更像用例-活动图，由于发生在用例之间而非之内，所以叫用例-状态图更妥。此图用来找出用例；绘制完毕后会知道”完毕了“；两个人绘制的图差点儿一模一样；平均每张图开发工作量35人天；看着图能写出測试用例（群），还能知道写完了没有；每张图是一个迷你MVP，必须完整公布……
结语
张克强-敏捷307： 说了这么多，事实上还没有直接回答原博主的提问。我来回答下吧：在敏捷环境下，假设仅仅使用用例表达需求（不联合使用用户故事），那么环绕用例必须的文档是用例图和用例规约（不一定要正式的）+数据字典。
其他的没必要的，依赖于团队对UML和OOAD的认识和水平，但就算团队对UML和OOAD有非常高水平, 见续
张克强-敏捷307： 假设把以上提到的全写了，覆盖全部类，并且没有一个强大的支持正反向project的UML工具，那么多半是不敏捷了。 (10秒前)
其他
袁斌_AgileDo：我眼下在需求的分析中，主要是把需求分为系统级需求、架构级需求、开发级需求，不同级别的需求在不同阶段完毕，当中前两个在先启阶段完毕，后一个在构建阶段提前一个迭代完毕 (5月22日
09:31)
关于用例须要多少文档以及业务用例等等,布布扣,bubuko.com