我刚接手的一个项目，一个核心的业务子系统在很多地方客户都提了完善的意见、并且有很多功能还无法实现，易用性设计也比较差。总之要改造的地方很多。
我采用用例把所有要改造的功能点重新表述出来，这在分析系统功能上要远比使用菜单表达更合理，因为即便一个最底层的子菜单也并不代表就是一个软件的功能点，另外，菜单的组织是着眼于便于客户使用和便于导航的，它和系统功能并没有一一对应的关系。
用例毕竟是软件领域的技术方法，对于客户来说，理解阅读用例的每个元素所代表的意义应该说还要一段时间的交流和适应。用例可以很方便的让系统分析员根据功能点主事件流做出原型。而原型可以使软件实在化。用原型配合的需求交流，比起让客户阅读一份冗长无味的软件需求规格说明自然会取得很好的效果。
当然，原型最终的有效性是需要目标用户群的充分检验评价的，因此《SoftDemand》提示和客户交流原型要关注以下问题：
这个原型所实现的功能与你所期望的一致吗？
有遗漏的功能吗？
你能考虑一下这个原型所没涉及的一些出错情况吗？
有多余的功能吗？
这些导航对于你意味着怎样的逻辑性和完整性？
有更简单的方法来完成这一任务吗？