软件工程不同于其他计算机专业，因为是与人打交道的，服务于人。软件是给人用的！在众多软件中，成功的有很多，但失败的例子也是数不胜数。因此在做一个项目的时候贯穿适始终的总之就是考虑用户的需求。但这个需求却不是专业人员凭空想象出来的。是通过需求分析得到的，可见需求分析的重要性。需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。只有需求分析人员准确的分析出用户的需要，底层程序人员才能更好的满足客户的需要。不然结果就是一个项目要改很多遍，最终还有可能面临失败。
从这四个故事可以看出需求分析的重要性，第一个故事中十多次的结构性改变与不计其数的局部调整后，最后所欲偶员工都离开了，并且远离了软件开发行业。确实是非常惨痛的教训，当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。因此需求分析需要一次一次的迭代。
1.初识
需求分析的第一步就是需求调研，而需求调研的第一步则是与客户见面，认识。与客户保持适当的谦卑是有必要的，但过于的谦卑却常常给项目日后的进程带来风险。因为过于的谦卑，客户说什么就是什么，就会使客户变得非常强势。于是客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。我们做得很累，但是客户确不满意。我们应该做的是对客户需求深入了解后，结合我们的专业知识提出更加合理的解决方案。让客户感觉我们输得就是他想要的，再会议阶段，也要考虑用户的不同身份。比如各个部门的需求是不一样的。大概可分为高层领导、中层领导、基层人员。其中最重要的是基层人员。
2.拜访
经过一段努力获得了初步成果，此时需要做的就是拜访各中用户，分析一个客户人群的关系，就是在分析这个人群中，谁有意愿支持我们，而谁却在自觉不自觉地阻碍我们。那些通过这个项目可以提高政绩，提高自身价值的人，都是我们可以争取的盟友。他们是我们最可以依赖的人，我们一定要与他们站在一起，荣辱与共，建立战略合作伙伴关系。
3.研讨会
业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
4.需求研讨
需求分析并不是一件最简单的事情。客户说他们需要做一个什么软件，有些什么功能，我们照着做就可以了，所谓的需求分析员就是需求的记录员。这是错误的。客户可分为几类：对软件不了解，能提出业务要求，比较详细的提出要求。但是总之，我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。我们应该集合自己的专业知识认真分析用户提出的要求是否可行，或者给出更好的方案。最重要的是要相信自己的专业水平。
5.迭代
需求分析不是一蹴而就的。研讨会上收现金画出用例模块，再画出用例图，要分析各个业务之间的关系。在用例分析的同时，需求分析人员还需要对业务中的相关事物，制作领域模型。领域模型，是对用户业务领域中相关事物、相互关系、相互行为操作的描述，它是以对象图和类图的形式表达的。最后整理出文档后，应当对及时地与客户进行反馈。就这样一次一次的迭代，每一次都完善一些。
6.需求捕获
需求捕获是迭代的开始，再这个阶段中不要被动的去接受用户提出的要求，总是诺诺诺。应该结合自己的专业知识认真分析。还要发觉行业的尝试信息，客户没提出，可能是因为他觉得这个是行业尝试，但是项目人员却不了解。因此在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。
7.功能角色与用例图
功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。每个用例都有确定的场景，明确的目的和结果。
8.业务流程分析
许多软件最终失败的非常重要的原因就是对需求分析过于草率、浮于表面，我们要做调查，从高层的信访举报发现问题，将问题支撑问卷，发给下层。最终分析出真正有价值的东西。