最小保证是系统向项目相关人员做出的最低承诺尤其是在主执行者的目标不能被满足的情况下。当然在目标被满足的情况下它们仍然成立但是当编写有效用例主要目标被放弃时它们就成为人们真正关心的事情。大多数情况下两个或更多的项目相关人员必须在最小保证中被提及例如可以有用户、提供系统的公可还可能有政府管理部门。不必在最小保证中不厌其烦地列举出用例的所有失败情况。失败的情况多种多样而且千差万别。所有的失败条件和处理方案都已在扩展区做了描述要使两个列表保持同步既麻烦又容易出错。在模板中加入最小保证的目的是为了声明系统的承诺。最常见的最小保证是“系统将其执行进度情况记入日志”。为失败的事务处理做日志并不是一个显而易见的需求但却是至关重要的。在需求描述中系统日志经常会被遗忘后来又被程序员重新发现。然而它们对系统拥有者和用户来说都是十分重要的。一旦正常的运行条件得到满足系统可以利用这些日志继续某项事务的处理项目相关人员利用日志来解决纷争。用例编写者应该能通过调查项目相关人员的利益或集中讨论失败条件生成的日志发现这些需求。最小保证被写成一些简单的断言形式无论用例如何被执行这些断言最终都应为真。它表明每一个项目相关人员的利益都得到了满足。最小保证:只有收到付款以后才启动订单。最小保证:如果没有捕获到最小信息那么不完整的索赔请求就被丢弃不对这个请求做任何记录。如果最小信息被捕获(见业务规则)那么不完整的请求就被保存并记入日志。在目标遭遇失败的情况下项目相关人员认可他们的利益得到了保护这是最小保证是否成功的测试标准。