最近，我阅读了编写有效用例的第二部分：经常讨论的主题。
当满足如下要求时，才算完成任务：已经命名了与系统相关的全部主执行者及其用户目标、捕获了系统的全部触发条件、编写了所有用户目标用例以及必要的概要用例和子功能用例、每个用例描述足够清晰、投资方确认用例集覆盖了他们所有的需求。过去，我对于什么时候才算完成的了解不够，不能够清晰的认识到什么时候才算完成，将来，我会尽可能的提高自己这方面的认识。
在对大量用例进行处理时，可以采用两种行之有效的技术：对每个用例进行简单说明，或者把用例分为多个簇。过去，当遇到大量用例需要处理时，没有行之有效的技术，将来，可以尝试使用这两种技术进行处理。
我们把创建一个实体、检索一个实体、更新一个实体、删除一个实体这些基于数据库操作的小用例称为CRUD用例。由于每个小用例都表达了单独需求，甚至还可能由不同的人在不同安全级别上执行，因此它们是独立的。但它们打乱了整个用例集，使需要跟踪的用例成倍增加。过去，我对于CRUD用例的认识不够，将来，我会尽可能的提高自己对于CRUD用例的认识。
通常在谈论用例时，总是说业务过程建模或文档化，而不是业务过程重组或设计。因为用例仅仅是对过文档化，不能代表过程重组或设计。在创造设计时，设计者需要经历一个思维跳跃的过程，但用例不能告诉他们怎样去做。通常，每个层次文档所描述的是下个层次设计必须满足的行为需求。引入新技术经常会改变业务过程。它们分别是从面向技术的核心业务，从新业务过程到技术，以及从技术直接驱动，对业务过程进行重组。过去，我对于业务过程建模的认识不够，将来，我会尽可能的提高自己对于业务过程建模的认识。