例如判定矩阵，我遇到过一帮业务专家研究什么情况下叫故障，我问判断设备是否故障有多少因素？专家说共四个因素，那么每个因素有两个选项，列成表格形式，一共是 16 种组合。这个问题就迎刃而解，整个项目可以快速往下推动。软件开发团队使用正确的工具，可以起到非常大的改进作用，甚至缩短交付周期进而提高整体代码质量。在整个软件开发的过程中，BA 的角色叫业务分析师，他的定位是在领域专家和技术专家之间搭建起一个桥梁，将领域专家提出的领域需求翻译成一个技术需求，让技术专家能够实现正确的过程。BA 拿出一份需求文档，两方都有相同的理解，这才是一个优秀的 BA 应该做的事情。
以 Scrum 环境为例，在 Scrum 中团队没有进行细化，所以 BA 也是团队的一部分。在团队里 PO 跟最终用户进行沟通，将收集到的最初业务需求分解成用户故事，进行价值排序并设定产品计划、产品战略等等，那么 BA 就应该是把最初拿到的以用户故事为单位的需求，转换翻译成开发团队能够看懂，并且能够正确实施的需求过程，因此 BA 是介于这二者之间的一个沟通桥梁。需求处在开发过程的最上游，那么需求分析的质量改善就会对下游产生一个杠杆作用，因此 BA 不要去做低价值的事情，而是需要让团队价值得到更好地体现。
需求变更是常态，如果能够提前去想到应对变化的措施，那就真正掌握了如何提高灵活性。变化不仅体现在代码上，在需求层面也需要响应变化，才能够真正推进整个软件工程。需求文档写出来开发团队要看、测试团队要看，在 Scrum 中 Scrum Master、PO、UI、最终用户、干系人都要看，但每个人所处的立场不一样，希望看到信息也是不同的，如果把文档以合适的形式来组织，让每个角色都能快速理解并且保证高质量，那么整个软件开发过程都能得到很大程度的提升。
例如虚拟一个巴士租赁项目：国内旅行社要租赁国外的巴士安排旅客行程，接到订单就将乘客安排上巴士，行程结束司机结算相应费用。用如下流程图的方式将巴士租赁的主要业务逻辑画出来，可以发现在某些情况下并没有说明判断基准。遇到一个业务需求时，可能会有各种各样的条件来判断这些步骤是否可以往下推动，把这些条件全部列出时整个流程图会变大、没有分层导致难以阅读和维护，而且非常难以变更，如果想实现不论条件如何判断这张图都不发生改变，那么就需要通过解耦合的方式让文档产生一份固定和一份可变动的。
可以从下图看出判定矩阵的构成形式，前面是条件，每一个条件的选项按照 Excel 的形式列出，用这种方式列出所有的四种组合，动作全是派车，那么最后的结论就很清晰。用这种方式可以确保条件覆盖率达到 100%。如果有遗漏那是因为所采用的工具没法达到 100% 覆盖率，比如纯文字描述。如果是一个更庞大的表格，达到上百甚至上千行时，也可能产生人为的遗漏，因此需要采用更科学的工具进行自我校验。
下图表格的构成形式，前面是条件、中间是操作、后面是预期，这种 Give When Then 的形式就是测试用例，测试人员拿到表格，可以直接作为测试用例使用。这个判定矩阵不仅能提供 100% 的覆盖率，还能够引导程序员开发出正确的代码，达到一个好的效果。
状态之间是通过具体的操作进行切换的，例如状态 4 无法切换到状态 1，用这种方式把前面流程相应的状态全部梳理出来，就可以进行下一步的分析。举两个例子：一是贷款审批，实际上内部有三个步骤，第一步核实用户的真实身份，第二步核实用户的征信状况，第三步核实银行卡与用户信息的一致性。内部在处理数据时有子状态，但是对外都显示“贷款审批”，所以会分为内部状态和外部状态。另一种叫主状态和子状态，比如说出国手续的步骤可以分为机票——酒店——签证，每一个子过程都有自己的状态，并且三者是并行，全部状态完成之后整个过程才算完结。
