1. 做用例前，要先弄清楚研究对象是什么，并时刻提醒自己不要偏离主题。不然会发生“患者到医院挂号”，或者“患者到医院信息系统看病”之类的笑话。
2. 只要在形式上能写出符合需求标准的路径、步骤，都可以作为用例。注意，是“可以”，并不是“一定”。
3. 做用例分析时最常犯的错误是：把步骤当作用例。如“取款”用例中的“验证密码”与“扣除帐户金额”，它们是“取款”用例的步骤，而不是其子用例。
4. include的目的是为了复用有价值的步骤集合。形式往往是多个大用例include一个可复用的用例，即“多个老大include一个小弟”。
5. 用例是否用对了的一个判断标准是：其是否加强了和涉众的联系。如多级审批中，局长乐意跟科长共享一个审批功能吗？
6. 层次问题的出现常常是因为把研究对象弄错了，或者将系统契约与非契约混在一起。如将医院的职责“强加”给了医院信息系统。
7. 讲究“复用”不是需求要考虑的事情，而是设计要考虑的。高焕堂老师说：需求是收益面，设计是成本面。
8. 用例的步骤应该是回合制的，一个回合内包括一下几类步骤：
• 1.执行者请求；
• 2.系统验证(可选)；
• 3.系统改变(可选)；
• 4.系统回应。

1. 在第一次迭代之前，召开第一个时间定量的需求工作会议，进行高阶需求分析，如仅仅确定用例和特性的名称，以及关键的非功能性需求。在高阶需求列表中选取10%具有架构意义、高业务价值的需求进行功能和非功能性需求的详细分析；
2. 在第一次迭代钱，召开迭代计划会议，从做好初步详细分析的用例中选择本次迭代的任务目标；
3. 在三到四周内完成第一次迭代，并严格遵守时间；
4. 在第一次迭代即将结束时，召开第二次需求工作会，对上一次会议的所有材料进行复查和净化。然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，用一到两天对其进行详细分析；
5. 于第一次迭代结束最后一天举行下一次迭代的迭代计划会议；
6. 以相同步骤进行第二次迭代；
7. 反复进行四次迭代和五次需求工作会，这样在第四次迭代结束时，可能已经详细记录了约80%~90%的需求，但只实现了系统的10%；
8. 大约推进了整个项目的20%，这是细化阶段。此时根据分析以及早期反馈、早期编程及测试，已经可以获取系统的概貌和各种风险，可以把握住开发并能估计出需要多长时间来结束；
9. 此后，一般不需要再召开工作会，需求已经稳定了，接下来时一些列为期三周的迭代。

小结