1、完整正式的用例格式：（1）单列文字（不是一个表格）（2）步骤编号（3）没有条件语句（4）扩展部分的编号规则是数字和字母的组合
完整正式的用例模板<名字>
|
<用例名应该是一个用主动语态动词短语来表示的用例目标> 使用语境：<目标较长的描述，如果需要，还包括触发事件> 范围：<设计范围，在设计时将系统作为一个黑盒来考虑> 级别：<概要、用户目标、子功能三者之一> 主执行者：<主执行这的角色名称或主执行者的描述> 项目相关人员和利益：<用例中项目相关人员和关键利益的列表> 前置条件：<我们所希望的，周围环境已经达到的状态> 最小保证：<在所有退出操作前，如何保证得到必须的信息> 成功保证：<目标完成时环境的状态> 触发事件：<什么引发了用例，可能是时间事件> 主成功场景： <在这里写出从触发事件到目标完成以及清楚的步骤> <步骤编号#><动作描述> 扩展： <在这里写出扩展，每次写一个扩展，每一个扩展都指向主场景中的特定步骤> <被改变步骤><条件>：<动作或子用例> <被改变步骤><条件>：<动作或子用例> 技术和数据变化列表： <在这里写出场景中因技术或数据变化而引起的可能分支> <步骤或变化编号#><变化列表> <步骤或变化编号#><变化列表> 相关信息 <项目所需要的所有附加信息> |
2、图形符号有两个可用性方面的问题，第一，最终用户和业务执行者不可能熟悉这些符号，也不会有耐心来学习这些符号；第二，图形不能完全表示你所需要的意思。用例本身就是文字的，任何图形都只是为了帮助读者找到他们所要阅读的文字。
3、影响用例书写格式的因素
（1）矛盾的因素：业务环境、社会作用、不同文化
这个列为第一因素真的不为过，特别在中国，地大物博，很多项目可能是北方公司的人到南方做项目，文化背景不同，语言也不是很一致，这个会直接影响需求获取的精确度
（2）理解层次
本来开发人员和业务人员就存在理解层次不一致的问题，开发人员没业务人员懂业务知识，业务人员没开发人员懂软件开发知识，所以要降低这个因素的影响必须找到一个共同的具有标准格式的“语言”（如通用的用例格式）和很好的分工与协作方式。
（3）项目相关人员的要求
每个涉众（即项目相关人员）都有自己关心的方面，所以他们的要求也不相同，所谓众口难调，在这里体现的淋漓尽致。
（4）经验与格式
（5）覆盖面
（6）一致性
（7）复杂度
（8）完整性
（9）目标与任务——完成什么与怎样完成
（10）资源
（11）其他因素
存在着这么多因素，所以需求调研就不能以一种固定的模式推广，只能在一个比较大的框架上，通过调研人员发挥主观能动性与涉众一起完成需求的调研，但这些因素是提醒人们在需求调研过程中应该注意的问题。
4、五种项目类型的标准，五种情况：
（1）了解需求，甚至包括用例根本不在最后的需求文档中使用的情况（模板见p108）
你的用例通常作为一个黑盒，大多数都是用户目标级别。你可以用一个较高层的用例来描述语境，但是你最好不要经常使用海平面级别以下的用例。
（2）业务过程建模（模板见p108）
阅读这些用例的人往往是一些高层人员、部门经理和高级执行官，因此尽量使这些用例可读性强，减少细节的内容。步骤的编号突出了活动的时间顺序。一定要在扩展中描述错误的处理，这样才能揭示重要的业务规则。
（3）设计和量化系统需求（模板见p109）
当你为估计系统大小和结构而分析需求时，使用这个模板。以后，你可以细化需求知道完成这个完整的用例。
（4）在一个短期、高强度的项目中编写功能需求（模板见p110）
由于时间和经济的原因，需要避免编码的开销和编写完整模板；因此你可以使用非正式的格式。但你还是必须了解前置条件、保证条件和扩展。
（5）在一个长期、大型项目中，在增量式开发开始时编写详细的功能需求。（模板见p110）
当你收集行为需求，并且需要完整正式的用例格式中的所有信息时，可以使用上述模板。这种模板可能应用在大型、关键、昂贵的项目中；或者 应用在有固定预算的项目中；或者应用在开发组分步在不用地方，在增量式开发的开始阶段需要扩充和检查以前设计的量化用例时；或者这样做时你的习惯