我首先读的是编写有效用例这本书，该书引言首先对什么什么是用例做出了解释，介绍中把用例归为一种契约，我的理解中用例就是不同用户与系统，以及不同用户之间实现交互的一个个典型场景的描述。典型的用例模式都是涵盖这几个模块例如主执行者、范围、层次项目相关人员和利益，前置条件等等，主执行者是指提出请求的项目相关人员，用例有可以分为两类一类是记录软件额行为需求这时的系统是指常见的计算机程序另类是记录一个组织的业务过程那么此时系统就是指的该组织，利益相关者指，这个组织人或者是和该组织有关系的人，通过这些来描述用户主要场景，与我自己认知不同的是我认为用例必须用用例图来表示，不过语言文本的表示也是挺清晰的，一个编写良好的用例应该具有可读性，无论是业务人员还是软硬件开发人员还是设计人员都可以通过用例来描述需求，关接下来范围是指真正被讨论的系统是什么，主执行者谁有药实现的需求，层次指目标的高低，主成功场景一切都成功的情况下，在第一个一个人准备通过万维网购买股票的情况中这个用例应该是一次处理就能完成的目标处于用户级的目标而第二个则不能从一次中完成，需要多不的处理显然处于概要的目标，两个用例的共同之处有最小保证和成功场景和扩展场景扩展是执行过程中可能遇到的意外情况于用例黑盒子就是不用太关心具体的细节，说的挺对不同的方法适用于不同环境，软件的规模不同对用例的正规程度的要求也是不同的，正规的就按用例模式一项项添加场景，定义，而非完整的是只就场景进行描述，从用例中可以看出部分或者说是主要的需求，用例的目的原来是针对用户，让用户提前知道新系统是什么样的对于可行的需求大纲包括目的和范围、使用的术语、用例等等其中的目的和范围有整体的范围和目标是什么？项目的相关人员？什么在系统之内？什么在系统之外，关于用例的增值作用一方面体现在对系统目标的描述，这在以后可作为项目不同的项目相关人员交流的工具，第二个增值作用是对异常情况处理的描述上，对于所有可能发生的所有异常情况列表显示出来，然后就是发现了异常和离散的用例的步骤所进行的集中讨论是为了避免对于新的功能和业务规则来说太晚，关于用例时精力的合理安排应该做到节省你的精力，就是开始时不要考虑所有的细节，精确度和准确度的区别3.1415.....已经有很高的精确度但准确度不是特别高。对于一系列的用例有多
种的排列次序这涉及到用户的请求是任意的在条形库的比喻总指明把所有的场景聚拢
到一起的目标一条腿标示成功的集合二另一条腿则标示以失败而告终的场景实际中，并不需要对每一个用例都从头至尾的单独进行描述还可以增加一些内容以表示自用例，子用例嵌入在为之命名的用例中，一个子目标可能成功也可能失败这是被折叠为单个步骤的用例。