（一）软件开发的相关人们（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）指明了启动用例的条件。