开发人员负责需求的分析与定义，难度最大的依然是思维视角的转变。开发要思考“怎么做”，而获取需求是思考“做什么”的问题。在与客户交流中，获取需求的系统分析员很容易在讨论系统“做什么”的过程中，陷入系统“怎么做”的思考方向上，自然，需求的获取就失去了尽可能完整的可能。更多的把自己设想在客户的角度,可能可以体会到"做什么"问题的更有意义更为紧迫。
在需求分析定义的过程中使用用例可以迫使需求分析人员从用户的角度思考问题。我想我们大概可以从这样两个角度去理解这个观点。首先，用例的编写第一步便是识别系统角色，系统设计实现的功能就是要满足这些系统角色使用系统所要达到的一定的目的。完整确切的识别系统角色，可以使我们在整体上考虑到系统将要实现哪几个方面的功能，比如，如果我们在需求阶段忽略了领导、管理者作为系统角色，那就很容易疏忽对数据综合汇总分析、统计等此类管理者关注的问题，甚至有管理者特权可以改变正常业务流程的功能也会被遗漏。
其次，用例事件流的必须体现“实现系统角色一个有价值的可见的结果”。这样一个基本原则就强迫我们在编写用例时需要考虑假设自己作为一个用户角色，自己所写的这一系列连续的事件步骤究竟要给自己带来什么样的明确的结果。依据这样的用例所设计的功能就会更好的符合客户的使用意图。事实上我们的很多设计，尤其是在体现用户和系统交互的界面设计上，不能明确完整的体现一系列交互操作究竟要实现用户一个什么样的具体目的，我们的界面设计仿佛是为了设计而设计，为了底层的数据库结构而设计，甚至是为了怎么样“易编码”而设计。
