用例书写，在一开始的时候不必太深入，这样既可以减少自己在书写用例上的精力，又可以给相关成员更多修改和深入思考的机会。还有如果一开始的用例是错误的会造成过多的精力浪费，不仅增加了工作量，更给心理上添加了负担。还有就是项目的范围，我感觉书中的方法很好。创建一个由三列组成的简单表格，左边一列是有关项目的主题，其余两列以内和外表识，在项目组内对每一个项目进行内和外的区分。这样可以在编写项目的时候建立清晰的框架。
　　场景中的目标和交互往往可以展开成更精细、更小粒度的目标和交互。这就涉及到目标的分解即将高层次的目标逐步过渡到低层次。用例的前置条件指该条件已经通过其他其他用例的执行进行了设置。例如对系统进行更改的前置条件就是已经登陆该系统。场景的结构可以包含在以下元素中:场景的执行条件、完成的目标、执行步骤集、完成条件、可能的拓展集。场景主体包括三个主要的内容:1.两个执行者之间的交互。2.为了保护项目相关人员利益的确认过程。3.满足项目相关人员利益的内部变化。在场景描述过程中需要有一定的准则1.使用简单的语法。2.明确地写出"谁控制球"，就是写清楚每一个步骤的执行者。3.从俯视的角度编写用例。4.显示过程向前推移。5.显示执行者的意图而不是动作。6.包含合理的活动集。7.确认而不是检查是否。8.可选择地提及时间限制.9.习惯用语:用户让系统A与系统B交互。10.习惯用语循环执行步骤x到步骤y，直到满足条件为止。
　　准则的解释。1.就是使句子的结构简单，容易理解。3.从系统外部即从用户的角度看系统。4.一些语句来显示用户执行过程的前进。5.在用例中只描述用户执行的意图，对于具体动作的描述属于设计的任务，而不应该在功能需求文档中出现。7.确认比检查更专业。8.明确系统的时间限制。9和10描述语言更加专业。

第二篇阅读笔记