文摘:《尤克滨：简单正是用例的价值》《非程序员》第19期（2002－11）
vbjava: 是不是use case 是给系统架构师和系统分析员沟通用的，而不是给用户看的，即便在use case workshop。
barbeque: 不是，Use Case 模型是用户眼中的Architecture. 当然Use Case 可以为后续的开发活动提供诸多便利，它将需求按照用户的目标以
高内聚、低耦合
的方式组织在一起。
higoals: 那么如何组织用户的需求呢？我脑袋中老去不掉未来可能的设计方案啊
barbeque: 用户的想法需要被有条理的捕获出来，而不是随机的捕获，然后在用设计人员的思路组织
gallenliu: 有人说：最清楚的需求文档就是user manual,你是否同意？
barbeque: 清楚的需求文档有助于快速地建立user manual。需求的内容应该是user manual 内容的超集
myzoucp18: 请问做需求时，是不是可以将性能方面的问题放在一边？
barbeque: 不是，性能需求是非功能需求的重要组成部分，尽管和应用逻辑没有直接的关系，但不等于不重要
evpu: 啊?!用户自己去直接修改需求?这个动作是发生在需求还没确定的时候,是吗?这样的话,就是说以用户的观念
(思路,条理)来组织,设计需求的结构和细节,是吗?
barbeque: 用户有能力自己修改需求的内容，隐含的意思是：用户完全理解我们写出来的东西。
higoals: 在需求调研中，用户和我，谁应该是主导角色？
barbeque: 有两种情况：如果是软件适应稳定的业务模式，必须由用户主导；如果软件起到改变业务模式的作用，
很可能是代表领域专家意见的人员主导
evpu: 我觉得,use case 就一个小人一个圈,再加一个箭头,其实还是要靠大量的文档,最大的用处还是在于圈定范围,是不是?
barbeque: Use Case 就是以文字为主体的功能需求描述方式，同时也是一种捕获方式。Use Case 图可以看作为UseCase 需求的“主页”
perl5: 想请教您如何把握界面原型在软件需求中的位置？
barbeque: 界面原型在软件需求中的作用很大：建立用户界面原型的主旨是在启动实质开发活动之前揭示和检验拟建系统的功能与可用性，在大规模投入资源之前，提供一个确认拟建系统正确性的机会。
Charity_Zhou: 有必要对用户进行UML 的培训吗？
barbeque: 不懂UML 的用户完全可以帮助你得到高质量的Use Case 模型。
vbjava: 采用以文字为主体的use case 表达方式是不是说明uml 在ooa 方面还不够成熟呢？
barbeque: 作Use Case 并不是做OOA。（它也不是OO范畴的）
vagawind: 但是use case 是OOA 很好的表达形式，对吗？
barbeque: 不对，OOA 是用OO 的方式将需求转述出来,其要素是所谓的分析类.Use Case 中的内容是用自然语言表述的需求,是OOA 的理想依据.
rareren: 怎样把一个或多个功能作为一个UseCase（如Insert,update ,delect 分开还是做为一个维护）
barbeque: Use Case 是某类用户的目标,达到一个目标可能会有多种可能的场景,每个场景中有若干个动作(交互). 通常的
误区
是将动作或者场景当作Use Case. 注意Use Case 中的Case 和Test Case 中的Case 是有区别
ltxd: 能不能详细说明一下用例这间的三种关系的区别
barbeque: 比如你上楼,你也许必须要走楼梯(include),当然你有可能在中途去一下洗手间(extend).（记录主体行为，而不是旁支末节）
txiaofeng: use case 是否存在最初原型和分析模型这两种概念？
barbeque: Use Case 是面向用户的,主要是记录应用场景,还没有到分析的时候.
ltxd: 在做某些大型系统时,是否可以考虑顶层的use case 只做几个, 然后针对每个顶层的use case 再进行细化, 对它又再建use case model, 这样形成层次关系, 保证单个平面单个区域上的use case 不要太多呢?
barbeque: 不是. 有些文献中建议在不同层面应用Use Case 的概念,但并不意味这不同层面的Use Case 之间存在细化的关系. 不同层面主要是指用户对系统理解的不同概括程度.
casual_wen: 那么经过需求分析阶段，应当产生哪些文档呢？
barbeque: 不同的规范有不同的文档体系,如果是参照RUP,主要有"前景","Use Case 规约(组)",界面原型,补充规约,词汇表
ltxd: 那这么说use case 就应该存在一个特定的粒度大小问题了, 即可以概括地说一般一个USE CASE 映射到多少个分析类？,多少个设计类, 能否给出一个数字, 我现在就是把握不好USE CASE 粒度的大小, 谢谢!
barbeque: Use Case 通常不能一蹴而就,开始先得到Use Case 规约的骨干内容:基本事件序列的步骤和备选事件序列的名称. 横向比较Use Case, 此时有些明显过大或者过小的USe Case 可以进一步分解或者合并,当然不能影响用户对其基本内容的理解. powerpeople: 用例规约中的，基本流和备选应该怎么理解啊？
barbeque: 你做100 次同一目标的事情,80 次的情形类似,它就是基本事件序列.
txiaofeng: use case 的分解与合并依据什么？
barbeque: Use Case 的内容更易于理解和管理.
powerpeople: 请问，我一个仓库管理系统中，增加出库单和修改出库单是不是应该分为两个use-case 啊
barbeque: Use Case 的划分主要是和用户直接讨论,你的问题不能脱离特定的上下文.
ltxd: jacbson 的use case 的定义是否只是针对所谓的concrete use case 的(而不是被included, extended 和被inherited
的?)
barbeque: abstract use case 已经不是具有基本含义的Use case...在应用USe Case 方法捕获需求时,建议不使用UseCase 之间的关系. 这种关系是当Use Case 模型已经相对完备之后用于优化Use Case 模型本身的, 对用户理解需求并没有显著的积极贡献
casual_wen: 但是如果use case 之间不建立关系的话，use case 是不是太简单了呢？
barbeque: 简单正是该方法的价值
powerpeople: 前置条件和后置条件怎么理解啊？
barbeque: 后置条件的翻译容易引起误解, 建议理解为"结束状态"
powerpeople: 比如说，我增加了一条信息，然后需要刷新界面，这算不算是“结束状态”啊
barbeque: 也许"界面被刷新"和"界面维持不变"更类似于"结束状态"
rareren: 不过我有点搞不明白一个Use-Case 到底什么时候开始？如一个查询功能从打开查找条件编辑界面之前说起呢?还是之后说起?
barbeque: 从用户需要做的第一个动作开始
rareren: 其实我觉得难处就是在于对不同的Use-case 用户需要做的第一个动作到底是什么?也就是use-Case 怎样划分的问题吧？不知是不是这样?
barbeque: 不是,Use Case 的划分的关键是用户最终要什么结果...
perl5: “从用户需要做的第一个动作开始”，那不是每次都要从系统登录开始？
barbeque: 通常可以从logon 之后的动作开始,因为logon 是每类人做每类事的必经之路,它通常被当作前置条件,并且logon 单独作为一个Use Case. 几乎成为惯例..（logon作为一个单独用例，并作为其它用例的前置条件）
Charity_Zhou: Jacobson 在software reuse 一书中强调UC 是可复用的，关键是要寻找变点和变体。但在ROSE 中无法体现变点以及变体
barbeque: 广义上,Use Case 可以复用主要指其内容及组织形式可复用. 并不是强调Use Case 被其它的Use Case 复用(尽管可以),因为这并不能体现出对Actor 的价值.
powerpeople: 怎么理解子系统啊?子系统和包有没有什么关系啊？
barbeque: 包就是一种一般的组织方式, 子系统强调行为特征(其内容通常组织在包中).
wy666666: 我觉得因为OO 就是分析、设计的技术，这与业务建模、需求是没有什么关系的。业务建模、需求完全可以用非OO 的技术来实现，经过讨论，甚至发现根本不必用计算机去实现都是有可能的！OO 并不是业务建模、需求的必要条件。您认为呢？
barbeque: 对。不过,
OO 是可以用于业务建模的
...:)