接下来是前置条件触发事件和保证前置条件生命力启用该用例前应该满足的条件，下订单的前置条件是正确的登录最小保证是系统向项目相关人员作出的最低承诺不必再最小保证中一直列举事失败的列子因为失败的例子已经在扩展场景中表明了最小保证可以使系统保证将执行进度计入日志中中处理不是显而易见但是确实是至关重要的最下保证被写成断言的形式（z只有。。。才。。。或者是如果没有。。。那么。。。。）。触发事件指明了启动用例的事件一般触发事件是用例执行的第一步。主成功场景和扩展场景可以包含场景执行的条件完成的目标执行步骤集结束条件、作为场景片段的
可能的扩展集，对于并行的顺序不确定的活动可以用注释来说明在足球的例子中球员1把球传给足球员2,2运球传给球员3，控制球的执行者就是句子的主语，足球时候传递的信息和数据四个准则分别是使用简单的语法、明确的写出“‘谁控制球、从俯视的角度来编写用例、显示过程向前推移、显示执行者的意图而不是动作包含合理“的活动集、确认而不是检查是否、可选择的提及时间限制、习惯用语用户让系统A与系统B交互、执行循环步骤知道满足条件。步骤编号的好处是在扩展部分显示出引用的主成功场景，但坏处就是插入一些场景时需要对后面的编号重新排序。关于扩展用例纹理裤既描述出了成功场景也描述出了扩展场景但缺点是场景的任何一个变化会导致；了其相同文字的场景都拷贝，另一种方法是”如果。。。，系统，。。，否则。。。“缺点是容易失去用例行为的线索，扩展的实质是冲主用例中被拆分下来的，是一种错误的处理二开发人员并不了解这种业务规则，需求人员必须研究正确的响应当程序员编程时遇到bug时才去寻找新的业务规则是很浪费时间的。扩展条件是系统在一些条件下系统会完成的不同二等动作，包括成功的和失败的两种条件集中讨论可以在编写扩展条件前收集大部分可能出现的扩展条件，当然女这种集中讨论是很费精力的扩展条件经常是一个系统检测到了什么短语或者是一个句子关于错误是在用户输入数据之前还是之后这养的情况可以放到系统的验证步骤中，如果在编写时没有加上步骤编号，那就没办法明确条件发生的步骤。扩展列表的合理化是为了使扩展列表尽可能的短，理想的扩展条件应该是尽时系统处理的情况，可以通过合并扩展条件，合并扩展条件可以缩短文档，从而减少了读者的阅读量，并清除掉那些系统不需要的条件，合并失败的最大的好处是，在高层用例中只用一个词就能恰当的为该层报告失败的情况