首先，我们要将业务流程分层描述，业务流程不需要指明执行角色（在较高层次业务流程中也无法确定执行角色），然后逐层细化，可以将业务流程细化到可以根据业务流程编写出伪代码的程度。在各层的业务流程图中，我们需要识别出能表述单一功能的流程点（这个可能需要经验来判断），这些识别出的功能点在之后可以作为验证用例图完整性的依据。
　　 然后通过对不同业务角色人员操作的不同功能，以及边界外系统与本系统的一些交互功能，以及本系统的处理功能，画出用例图，将此用例图使用之前从业务路程中识别出的功能点进行完整性的验证，以防止用例遗漏。再针对每个用例图，给予一个简单的说明，将用例中的事件流等说清楚，最后形成用例描述文档（也就是功能说明文档），另外还应该产出一个补充文档用来说明非功能性需求。
　　从用例推导出类图，就是采用领域模型（domain modeling），就是第一步将用例描述中的名词识别为域对象，然后再根据用例描述识别出对象的属性，最后将用例描述中此对象名词的动词再识别出对象的方法（这一步也可以通过先根据用例画出用例序列图，然后将序列图中的序列动作转化为对象的方法），按照此种方法推导出的是最原始的类，在此基础上，再补充相关的一些类，还需要识别出这些类之间的包含、关联关系，同时将一些类的共同点进行抽象（将抽象出的抽象对象作为一个新对象，被抽象对象从抽象对象泛化），最后就形成了完整的类图。在推导类图时，还需要注意系统的技术架构，因为技术架构确定了类图的依赖层次关系，比如技术架构中分为jsp，action，service，dao，db这几层，那么在类图中也必然有这些层次。
　　在类设计时，必须根据技术架构将整体框架设计完成，划分好类层次结构；然后先对底层模块进行设计，比如先设计权限模块、通讯模块、日志记录模块等，然后再对业务模块进行设计。在设计业务模块时可以通过局部设计技术，对某个或某几个功能点进行局部设计，多使用设计模式。
　　 在类设计完成后，最好能进行业务驱动的功能推导（可以借助完善用例的序列图来推导），以验证类图设计的完整性和是否存在矛盾的地方。