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）
当你收集行为需求，并且需要完整正式的用例格式中的所有信息时，可以使用上述模板。这种模板可能应用在大型、关键、昂贵的项目中；或者 应用在有固定预算的项目中；或者应用在开发组分步在不用地方，在增量式开发的开始阶段需要扩充和检查以前设计的量化用例时；或者这样做时你的习惯