//我的第一个故事来自大名鼎鼎的东软。我在2005年接一个项目的时候，听说这个项目之前是东软做的。当时东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域。
以上的例子让我感觉到了软件分析的重要性，如果前期的软件需求没有做好，那么就意味着你的程序制作的过程中，会越来越偏离客户的软件需求，等软件写好了给客户按看的时候，客户一看明显软件与需求不符，一次又一次的修改，而且由于偏离需求太多，每一次的修改很有可能都是大工程。就像如上的例子中十几次的大修改，每天的加班，使一个公司直接崩溃。这也让我感觉到如果你想搞垮一个软件公司，而这个公司的需求分析师又没两把刷子，最好的办法就是给他找一个大项目。
//不能客户怎么说软件就怎么做
写软件的是我们，我们才是这个软件的技术人员，我们遇到的很多客户他们是没有学过编程的，他们提出的很多需求有可能是理想状态的，是不切合实际的，以为客户是不会去考虑技术方面的实际情况的。我们必须要基于技术实现去引导客户的需求，我们不能一直让客户牵着鼻子走。而我们去指导客户当然不是一点理论基础都没有，我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。
//我们提早将开发成果给客户看
我们在写程序时，可以考虑使用快速原型法。它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。我们以以恶搞比较快的速度先写出一个大致满足用户需求的软件，一开始写的这个软件我们可以先忽略一些简单的bug或者安全性问题，因为这并不是要最后交给客户的，这只是一个简单的测试版，当我们把测试版写出来让用户看到了一个直接的软件后，客户也就对自己的需求有了一个基础，而不是像以前一样只是靠想象，众所周知对于一个测试版软件我们无论是更改起来还是完善起来所需要的时间都相对于完整版会大大缩小。而当客户看到这个实际的软件后，他会对我们以后的修改方向有一个更明确的要求，这可以大大缩小我们修改软件的次数。
//最可以依赖的人，我们一定要与他们站在一起，荣辱与共，建立战略合作伙伴关系。
我们写软件的结果对公司的人会有着不同看法如很多ERP项目会损害采购和销售人员的利益，因为信息化的管理断了他们的财路；很多企业管理软件会遭到来自基层操作人员的抵制，而那些通过这个项目可以提高政绩，提高自身价值的人，都希望我们可以拿出一个好的软件，这些人都是是我们可以争取的盟友。总之就是那些对我们怀有敌意的人。尽管有敌意，但我们能够坦荡的，敞开心扉的与他们交往。虽然不能奢望太多，但拿出诚意去争取他们，也还是有机会化干戈为玉帛、化敌为友。如果能够那样，那是再好不过了。
//对于不同的公司我们要有不同的需求分析方法。、
对于那些总公司对下级公司有着绝对的话语权的公司，我们可以要求子公司派遣人员代表到总公司来一同商议软件需求的问题，这样我们才能写出一个适合全体公司的软件，而不会产生我们的软件在某些子公司行不通的情况。而对于另一种情况，若总公司对子公司没有很大的管理权时，我们就应该深入到每一个子公司内部去了解他们的需求，尤其是他们需求的不同点。
//采用主动的态度去捕获需求。
我们在需求分析的过程中不能一直“保持谦逊”，因为这会导致我们得到一份不完善的需求，我们在客户解释需求的过程中，对于有问题的或者有歧义的我们一定要立马提出来，这样对大大的降低我们在程序编写过程中的风险，最好的办法就是在客户描述完需求之后，我们再复述一边得到客户的确认。
需求分析是一个需要耐心的不断重复的过程，在需求分析的过程中我们一定要有耐心，有信心，一个准确的需求报告，对我们后期程序的编写有着极其重要的作用