需求管理是项目中技术相关的最为重要的内容，项目失败的主要原因就是需求不清晰，所以需要在项目中对需求特别重视。IT项目执行过程中的需求和售前的需求不同，售前的需求是为了更快的形成有针对性的解决方案，而项目中的需求是真正将客户的需要形成为客户提高效率，进行业务操作的IT系统的需求工作，并且有严格的需求管理、需求变更等更深深层的内容。有很多书籍对需求的获取和管理提供了详尽的指导，但需求的获取及管理是一种实践型的方法，只是凭理论是做不好需求的获取和管理，有如看开车的视频是不可能在马路上开好车的。
业务需求放映客户对系统的目标要求，在项目定义中，项目目标和建设内容概要部分，说明的就是这种业务需求，从客户和用户处获取需求以后所完成的是客户当前业务及需要，但此时的业务需求还具有一些不确定性，很大可能还需要对业务流程进行改进后才是真正的业务需求。如果业务需求的稳定性较差，则最好采用先咨询项目后建设项目的方式，避免投资的浪费。业务需求一般用业务流程图来描述。
用户需求描述了用户使用此系统或产品针对日常的工作必须要完成的任务。业务需求很容易对业务描述达成一致，而用户需求则不同，用户对实现这个业务方式的方法理解不一致。用户对如何实现这项业务有了千差万别的理解，所谓“条条大道通罗马”，但是我们修路只能修一条，是修高速公路呢？还是修普通公路呢？正因为如此，用户需求是最不好平衡的，甚至对系统界面上的文字要求都可能起到对整个系统的影响。
功能的需求和用户需求息息相关，有什么样的用户需求，就会有什么样的功能。需求不是设计，有时候把系统的原型当成一种需求，实际上可以用原型来引导需求，而不是真正的需求。非功能性需求描述了系统展现给用户的行为和感受，例如一些操作界面的要求，或者去满足某些规范和约束。
无论那一种需求，都需要和客户、用户充分沟通，进行验证，这样会提高需求分析报告的清晰度，另一方面是为后续的工作提供坚实的基础，无论是设计、开发、测试、验收，都是和需求紧密相连的。
需求完成以后形成需求规格说明书，同时开始对需求进行管理，需求形成项目范围，经过审批以后成为范围基线，就可以正式进行设计和开发了。
用户需求的影响：
公司曾经为客户开发一个小软件系统，实现一个非常简单的流程和数据上报功能。合同签订以后，我们提出要进行用户调研，客户对我们说，不用调研，直接按照我们的思路和想法实现就可以，我们提出，系统最后要有真正的使用者来用，他们如果不提供，最后系统可能会缺乏信息而有隐患，客户固执己见，经过公司沟通以后项目继续。很快系统上线运行，客户要求用户来培训，准备使用系统的时候，系统的数据上报功能遭到用户的强烈不满，言辞激烈，客户负责人等面红耳赤，哑口无言，项目组在座位上脸色苍白。虽然从合同签订到系统部署上线，只有不到一个月的时间，但是对项目组而言，所有的时间完全浪费了，项目彻底失败，只能从头再来。后来凡是客户再有这种没有用户需求的事情发生，我就讲解这个教训，这会让客户转变观念，积极为我们协调真正的用户来参与。
