在软件项目开发过程中， BA会将对业务的理解输出成UseCase。该文档主要是体现将业务需求转化为技术人员能看懂的内容，使得技术人员理解需求（很多时候是自以为理解了），帮助技术人员进行良好的软件设计和编码。
但是很多技术人员在这步会犯一个特别严重的错误，简单的认为该文档的业务语言即是能够指导编程的技术语言，从而忽视了对于业务逻辑的二次梳理。
虽然有软件设计阶段，但这个时候，技术人员的精力大多是放在了数据库设计，接口设计，目录结构，程序命名，单元测试，搭建框架，工具选择等方面，而忽视了根据UseCase对于业务逻辑的二次梳理，使业务语言能够转换为技术语言。
将业务语言转化为技术语言，具有的好处是：
1有效的指导程序开发，技术语言和程序之间的差别基本上就很小了，不会存在很大的代沟和误差。实现为代码的效率和准确性都会更高。
2 能够快速响应变化。因为在二次梳理的过程中，很容易识别出易变的部分，能够预感到将来的变化，怎样变化，变化成什么样子。所以相当于变化之前就做好了相应的准备。当变化发生时，快速响应也就很容易了。
3 代码质量会提高。翻译为技术语言后，整个代码的逻辑会对象化，抽象化，模块化，这样会有效的提高代码质量。同时能够做到保证质量的前提下，快速响应变化，那么代码的质量一定是非常高的。这样就形成了闭环，互为证明。
关于如何将业务语言翻译为技术语言，下面介绍一个很玄妙的点，就是：
将一切不同的逻辑尽量梳理成一致的逻辑。
这里的关键点是尽量，这样就赋予了这件事情是不可量化的，是永远没有终点的，是永远没有终极答案的。每个人都能自圆其说就可以了。但说的水平高低，就靠自身能力了。
无法准确量化是很美的，它是构成了这个世界丰富多彩的原因之一，也是每个人能够在这个世界上有意义的活下去的基础之一。
第一个例子是某TOP车企车辆管理系统其中的一个案例：
如下这个需求的业务语言表述为：
如果是车辆申请的是京牌，需要到系统中校验一下京牌（特殊国情）的限额是否满足，如果满足就可以上牌操作。如果是非京牌，直接上牌。基本如下图所示。
目前存在两个相反的逻辑判断，是否京牌，导致了程序走向不同。经过梳理，会发现非京牌也可以去校验额度，只不过额度是Integer.MAX。
经过梳理后的技术语言如下：
如果是京牌，获取京牌的额度，如果是非京牌，获取非京牌的额度(默认Integer.MAX)，后面的步骤就完全一致了。
将一切不同的逻辑尽量梳理成一致的逻辑，中的尽量体现在：
1 京牌和非京牌是完全互斥的，无法调和的，所以做不到一致。
2 京牌非京牌的不一致限制在了灰色的范围中，实际的代码可以是一个类或者一个方法。此处可以扩展，可以应对变化。如果以后非京牌也需要限额，或者增加了沪牌，改动量非常小。
3 后续流程完全一致了。
第二个例子是TOP 1 电信设备公司的供应链供需匹配系统。