（一）软件开发的相关人们（stakeholders）使用用例（Use Case）来探索需求。编写有效的用例，形象具体，简洁，清晰的表达需求。
　　（二）书中的四个图标清晰形象：
　　1.Figure1.1 The "Hub-and-spoke" model of requirements，表达UseCase和全部需求的关系。
　　2.Figure2.2 Striped trousers:Scenarios succeed or fail，比喻Scenarios中两部份的成功和失败。
　　3.Figure5.1 Use case levels. The use case set reveals a hierarchy of goals --- the ever-unfolding story，用例的三个级别：Summary Goals，User Goals，Subfunctions 及其关系的形象表述。
　　3.Figure5.2 Ask ‘‘Why‘‘ to shift levels， 三个级别向上Why和向下How。
　　（三）一个UseCase 结构模板
　　Primary Actor
　　Scope
　　Level
　　Preconditons
　　Trigger
　　Main Success Scenario
　　Extensions
　　Variations
　　1、用例的前置条件（precondition）声明了启动该用例之前系统必须满足的条件。通常，前置条件是指该条件已经通过其他用例的执行进行了设置。
　　简单的例子，在论坛里发贴子用例的前置条件是用户登录。
　　往往层次高的用例中前后两个没有可选路径的步骤，降低一级层次后，两个步骤独立为两个用例，那么前一个用例是后一个用例的前置条件。如在“病人看病”用例里，第一步骤是“挂号”，第二步骤是“去诊室见医生诊”，那么“在去诊室诊”用例里，“挂号”是其前置条件
　　2、在编写前置条件时通常易犯的一个错误是，把经常是正确的但不是必须的条件写入前置条件。
　　例如，医院急诊病人诊可以不预先挂号，那么“挂号”不是“急诊病人诊”的前置条件。
　　3、小保证是系统向项目相关人员作出的低承诺，尤其是在主执行者的目标不能被满足的情况下。在目标遭遇失败的情况下，项目相关人员认可他们的利益得到了保护，这时小保证是否成功/失败的测试标准。
　　4、成功保证（success guarantee）说明了用例成功结束后项目相关人员的哪些利益得到了满足，用例可以通过执行主场景获得成功，也可以通过执行可选路径获得成功。成功保证通常作为小保证的添加内容：小保证被满足以后，并且一些附加条件为真；附加条件中至少包括用例标题中声明的目标。
　　5、项目相关人员认可他们的利益得到了满足，这是成功是否成功/失败的测试标准。找到成功保证的好方法是问这样一个问题：“在用例结束时，什么事会使项目相关人员感到不高兴？”这个问题通常很容易回答，然后写出答案的反面回答。
　　6、触发事件（trigger）指明了启动用例的条件。