在1998年的OOPSLA大会上，12个资深的用例设计者和教师聚集在一起，讨论一些常见的编写用例容易混淆的地方和困难，以及是什么使得人们写出的用例都各不相同。大会的组织者Paul Bramble收集了这些意见并将意见分类。用例在不同情况下可能会不同，你不用担心这个问题，这是大家都无法避免的。
你可能发现在下面所列的情况中，有些情况组合起来迫使你不能按期望工作。耐心一点，宽容一点，你就可以写出符合要求的用例。在列出了所有这些影响因素后，我们可以找到一个一致的问题答案:"怎样写出可读的用例?"
矛盾的因素:业务环境、社会作用、不同文化
你想要描述用例，但是可能遇到下面的情况或争论(我不是想平息这样的争论，而是要你认识到并不是只有你会遇到这样的情况)。
我们总是按照另外一种方式去做事情。
在不同的文化背景中，你可能发现:
在小组中存在偏见。
存在不同的工作文化，在这些文化的影响下，人们只不过在"以不同的方式做事"。
写用例的人和读用例的人使用不同的词汇表。
理解层次
在不同的时间、地点，不同的人对同一件事情会有不同的理解。你可能会修改推荐的用例编写格式，这可以根据:
现在你知道多少:
- 关于领域
- 关于用例
你知道当前阶段是处于软件生命周期的哪个阶段吗?
你是否需要确定工程的内容或花费?
你现在是需要广度的研究还是深度的研究?
- 暗中分析或慢慢地分析现状。
- 人们都强调他们所知道的内容。
- 时间计划、知识深度与领域知识的对立。
项目相关人员的要求
你同意下面哪些观点?
用户是读者，也是用例的使用者，他们关心用例的高层次描述。
IT公司的技术人员是编写者或实现者，他们关心细节描述。
一些开发组可能想通过一些服务小组来表达关于用例的多个观点，或者对建立一个完整模型还是部分模型产生分歧。是否还涉及其他不同的读者?如果有，他们是谁?
经验与格式
经验(experience):每个小组中都有用例的初学者，但是他们很快就成为"有经验"的编写者。有经验的人知道一些捷径，初学者则希望有清晰的方向和一致的指令。
格式(formality):不管是对有经验的设计者还是初学者，领导者或部门传统的工作方式都需要有一种正式(或非正式)的书写格式。
覆盖面
用例的覆盖面依赖于开发组的组成、编写技巧、成员之间的交流及他们是需要覆盖整个问题，还是只需要与读者交流信息。
覆盖面的变化可能是由于:
领域问题专家(他们关心的问题可能集中在某一个方面)编写者人数
读者人数
实现者人数
业务人员是否知道他们需要什么
按照一个通常模式来工作的决定开发组成员的地理位置分布
一致性
用例内容一致性的要求可能会与客户需求的不一致性和不确定性冲突。需求的易变性
格式的一致性
复杂度
用例的复杂度涉及下面几个方面。
对用例完整性的要求
描述整个问题领域
多角度的描述
简化系统视图
表达的简化
细化用例表达
范围窄的视图和范围宽的视图
问题的复杂度
加入技术细节的要求(特别是在问题很难解决的时候)
下面的因素影响了系统的复杂度。
分析停滞(系统的复杂度超过了分析师的分析能力)执行者的数目
功能点的数目
系统的种类
用户系统的简单性
实时系统
嵌入式系统(必须有容错能力)
冲突
需求是为了解决用户冲突，但需求的不确定性又掩饰了冲突。
完整性
妨碍用例完整性有下面几个因素。
工程的需求不完整。
设计者没有接触过用户(用户不是你的客户)。
目标与任务-完成什么与怎样完成
用户经常细化需求而不是系统的使用方法。
系统环境可能和使用方法冲突。
活动和任务描述了系统会发生什么，而不是为什么发生。
资源
写出好的用例是需要时间的，但项目的时间是有限的。在编写项目的用例时就必须引入管理机制。
其他因素
其他影响用例的因素有:
- 工具需要/支持
- 不明确的目标
- 将需求分块，并分别进行分析
- 无约束的设计与将要进行的设计的层次
- 清晰与可理解的设计
- 抽象用例与具体用例
- 可描述性
- 合作的积极性
这个列表有些与众不同。尽管本书中大部分内容适用于所有的情况，但你可以参考这个列表来决定采用多少形式化的东西，是否现在少做一些，而将来多做一些，设计到什么程度或怎样来安排设计的阶段，在深入编写用例之前理解问题的广度和精确程度。