（此文所指设计是指批量销售的产品，而非定制话的个案）
很多有两到三年开发经验的程序员很想提高自己的应用程序设计分析能力，希望可以以后做系统分析师，可是这项技能很难从书本或者网络直接的学习到，身边又没有合适的老师，所以经常无所适从，往往是设计模式比他们的架构师背的还熟，可是就是什么也设计不好。
写这些系列的文章，并不打算让你从程序员可以“突变”成分析师，只是为你提供学习的方向和零碎的技巧。
好，言归正传，我们怎么做分析，刚开始的时候，你不要想着一下子接收一个系统过来，即使再小（麻雀虽小，五脏俱全）也不好。比较容易接手的项目是一些独立的小模块，他们看起来功能单一，你所需要考虑的面就小的多。
现在就假设你已经“光荣”的接到这个模块的设计任务，有些人可能已经迫不及待的编码的一番（这个功能太简单了），呵呵，不是太好，虽然我也是搞极限编程的，但是也不推荐一点不做系统分析。还是按部就班一二三：
- 找合理的功能用例；
- 分析排列用例的重要级别；
- 设计出满足基本功能的第一个版本（没有文档吗？是的，基本上只有用例）；
- 使用用例测试；
- 加入部分未实现的用例，重构当前版本，再来一个轮回。
- 直到你认为工期就要到了，赶紧收手，或者你很聪明，搞定了所有用例；
- 出文稿吧。
嗯？和书上写的差不多吗？当然差不多，我还没有神奇到可以发明成一种新的设计方法论。事实上，只是帮你复习一下:)。
步骤都一样，最重要的还是看到底怎么做。
怎么做找用例
要找到合理的用例是十分重要的，一般你可以在这些地方找到用例：
- 现有产品的功能，如果你有老版本，那现有的功能怎么可以丢呢？否则你的功能做的再天花乱坠，客户还是说：这个都没有以前的好。
- 竞争对手的产品，其实我们的销售人员在外面推销的时候，除了花60%的时间陪客户，10%的时间讲我们的功能，还有30%的时间在讲竞争对手的产品怎么怎么的不好，你看我这个功能他们就没有。能够将竞争对手好的设计“吸收”进来，会给你减少很多麻烦。
- 来自以前的不管是做好的，还是未做好的二次开发案例，既然存在这些案例，就表示事实存在这些需求。
- 好吧，如果你真的时间好充足，精力好旺盛，老板也批准的话，你还有一个选择，挑几个你的典型用户，到客户那边去，像个空气人一样的在那里看他们怎么工作的。千万不要拿个本子，露出微笑的面孔，来一句：请问，您有什么需求啊。
哦，你一定发现了，我把与客户交流放在最后了，这是不是大忌？这个问题我就要讲讲找用例的注意事项了：
- 你面对的客户是他所在行业的专业人员，不是“软件专业人员”，你才是“人才”，你问他需求，搞错了吧？所以到客户那里是用自己的主观去“悟”别人的需求。他们提出的需求是外行的需求，你要自己悟出来成内行的需求。
- 用例切记防止需求膨胀，需求膨胀主要表现有：
- 暂时不要的功能，未来8年的功能基本就不要考虑了；
- 过分的性能和负载，明明是几百人的小厂，却想办法要搞一个负载平衡，上千在线用户并发操作；
- 过多的兼容性，你的产品明明就只卖1万块钱，你却要搞SQLServer和Oracle两个版本出来；
- 客户随口的“强烈”需求。这个就不要说了，好多文章发过此类警告。
- 用例必须是简单的，对于总结出来的用例，必须非常的简单，如果太复杂，建议再拆分成几个更简单的用例。简单的用例能够减少交流时的歧义。
网上有很多的需求用例的模板，可以参考拿来用用，一般最重要的是：输入和输出，需要描述的很准确。
好了，文章也一样，还是短一点的好，我将有空的时候再继续写：如何将需求用例转化为代码。