误区4：用例和场景混淆
一个用例的执行是要有前因和后果的（前提是什么，结果会怎么样）；比如，煮饭和炒菜是用例，他们各自都有步骤，各自有好几个场景。比如煮饭，我可以用电饭锅煮，也可以蒸饭，煮饭前要先淘米，等等，这些都是一个用例的不同场景，但用户的最终目的都是一样的。不要把用例和场景混淆。
误区5：软件工程是不是用例驱动？
软件工程是不是用例驱动？需求是重要的，用例是构造需求的好方法。但如果你同时要考虑开发的所有因素包括重用，架构，花费，时间，你就无法仅仅从一个方面来驱动你的项目。好的软件工程是被一系列重要因素所驱动的，而且因素也因不同的公司和项目有着不同的重要程度。这些因素包括： 技术上对于设计的考虑，用户需求，重用，可更改性，系统性能，标准化，日程的安排以及其他的商务驱动。每个项目都有着自己不同的考虑。对于每一种情况，可以精确的说项目被域模型和用例共同驱动。
误区6：用例直接推导出设计
不要从用例直接推论出设计。如果这样做，“用例开发”仅仅成为了功能分解的一个借口。用例止于系统接口的边界！用例应该描述参与者使用系统时所遵循的次序，但用例决不说明系统内部采用什么步骤来响应参与者的刺激。
用例是帮助确定系统边界的一个好方法。用例也是获取需求的一个方法。用例也是产生测试用例的好方法。但是，从系统边界、需求、到详细设计还有很长的路要走。比如说，类图，事实上类图和用例图没有对应关系。换句话来说，用例是需求分析时的产物，类（边界类外）的设计期的产物。
