最近，我阅读了编写有效用例的第三部分：对忙于编写用例的人的提示。
要使需求文档短小简明，而且易于阅读。过去，我在编写文档的时候没有考虑过要让文档易于阅读，将来，我在编写文档的时候，会尽可能的考虑使得文档易于阅读。
用例不是仅仅记录了主执行者和系统之间公共的可见交互操作。如果用例仅仅完成了这些操作，那么它不是一个可接受的行为需求，而仅仅是文档化了用户界面。过去，我对于用例需要哪些东西的了解不够全面，将来，我会尽可能的提高自己对用例需要东西的认识，使之变得更加全面。
用例中的前置条件表明了用例的可运行条件。系统必须保证前置条件为真。编写前置条件是为了在以后用例编写中不用再对它们进行检查。过去，我对于前置条件的认识不够深入，将来，我会尽可能的提高自己对于前置条件的认识。
业务用例的设计范围是业务运作，它所涉及的执行者在组织外部，完成与组织者=相关的目标。业务用例通常不涉及技术，因为它只涉及如何进行业务运作。系统用例的设计范围就是要设计的计算机系统。它所涉及的执行者完成与计算机系统相关的目标，它涉及到技术问题。过去，我对于业务范围和系统范围的了解不够清晰，将来，我会尽可能的了解相关的知识。
首先从广度上而不是从深度上，做到逐步精确。工作随着细化逐步加大，这将有助于分配你的精力。过去，我对于首先向广度上努力的认识不够，将来，我会尽可能的提高自己对首先向广度上努力的认识。
了解你的项目在整个范围中的位置。不要被小型、非正式系统中的小错误搞得筋疲力尽。但是如果错误的后果非常严重，就需要认真对待。过去，我对于认识错误的代价的认识不够深入，将来，我会尽可能的提升自己关于认识错误的代价的认识。