我阅读了关于http://blog.csdn.net/yqmfly/article/details/7679781（我们应当怎样做需求分析），感触比较深，对于我们而言现在所做的所有的程序，并没有进行对软件的一个需求的分析过程，只是对题目提出的要求，进行机械般的实现它所要求的功能，我也就思考了，如果当我们真正的进入一个项目中时我们怎样在一个成本范围及能力范围中完成软件的开发，而且使得客户也满意。这点对现在的我们来说很难，不得不承认，我们现在所有写过的东西，都是不存在客户，都是根据自己一个开发人员的角度去完成程序编写，功能的实现，至于好不好用，一点没有想过。
开篇中东软的案例，客户对某个功能不满意，他们不得不对几百处程序进行修改。之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域但客户对需求改来改去的真正原因是什么呢？当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。所以说，对于一个软件开发的分析，不是单纯的客户要什么就去做什么，老师也提到过，客户有时并不清楚自己想要的是什么，那对我们来说，只能一点点的去摸索，一点点的和客户沟通，而且在需求变更的时候，需要理性的分析客户所提出的要求，不能客户说什么就是什么，要从业务本身去看需求。我觉得去理解客户的需求，就好比两个人在黑暗中教学一样，一点点摸索，慢慢去体会用户真正想要的，而不是用户提出来就去做。
很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。人与人交往，往往在接触的初期就决定了相互的行为方式，与客户交往也是一样。起初的唯唯诺诺，客户说啥就是啥，必然造成客户不再关注你的意见，对你发号施令就可以了。相反，起初展现出一位技术专家的姿态，能大方而得体地提出自己的意见，会使客户重视你的意见，甚至主动征求你的意见。这一方面要求我们对自己要有足够的自信，另一方面也要有循循善诱的表达能力。如果我们做到了这些，就会客户心目中形成一种威信，使项目向着一种良性的方向前进。