用例编写推荐守则

 

1. 没有最佳的用例模板,格式和章节是为用例的内容服务的,它们仅仅帮助理解和分析,一旦你发现它们是一种累赘,或者可有可无,应该毫不犹豫的丢掉他们;
2. 不谈界面,切忌在用例中描述了界面的细节,那往往容易掩盖需求的根源动机;
3. 行文简明,不要以为越多的文章描述能够帮助用例的理解,这往往会提供更多误导信息;
4. 系统是个黑盒子,不要描述系统的内部行为,这是设计应该干的事情;
5. 突出参与者(Actor)的意图,把握需求的根源动机;
6. 画边界找"演员"(Actor),这老用来捕获用例;
7. 顺藤摸瓜,通过业务事件找到触发它的参与者;

用例不是所有地方都适用的,尤其使开发后台服务,或者针对接口实现的类似项目尝试进行用例描述,可能会让事情变得糟糕.那就试着用特征进行描述吧.

以上内容均引用于或受启发于:

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition

By Craig Larman