软件项目需求管理是指一个为系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。那么，在实际管理工作中，会有哪些疑问呢?
1.需求工作涉及到哪些内容
首先需求包括了产品需求，用户需求，软件需求。产品需求关注的是产品的标准化和通用化，会对收集到的用户需求进行分类和优化，结合业界标准系统模型进行抽象并通用化。用户需求反映的是用户面临的问题域，根据问题域用户期望的能够达到的解决效果;而对于软件需求则是用软件工程的语言结构化和文档化的对用户需求和产品需求的描述。
需求工作涉及到需求开发和需求管理。需求开发涉及到需求调研，需求收集，需求分析，需求开发等工作，其中的重点有业务流程，数据字典，业务规则，界面原型。对于基于面向对象的开发方法则涉及到业务用例，系统用例(涉众，基本流，扩展流，业务规则，界面，操作)等诸多内容。需求管理工作涉及到需求的状态管理，变更管理，需求的跟踪，需求的验证和确认等重要内容。
在我们需求分析和开发中，最容易忽视的主要有两点，一个就是缺乏需求分析和开发的过程，把用户需求直接作为了软件需求，没有需求建模和抽象的过程。另外一点就是对于性能，安全，易用性，可维护性和扩展性等非功能性需求没有考虑，导致开发出来的系统是一个不好用的半成品。CMMI把需求管理放到2级，需求开发放到3级，实际上真正的提高需求人员的需求分析和开发能力才是解决需求问题之道。需求分析开发做不好，需求变更或追踪管的再好也没有用处，在这点上一定不能本末倒置。
2.做好需求分析需要具备哪些知识
需求分析岗位主要承担的是系统分析员的工作，做需求分析的人员要有软件工程基础知识的积累，而且最好有一定的软件开发经验积累。自己做过设计开发工作的才能够体会到如何才能够把系统做好，如何更好的把软件需求和后续实现更好的衔接起来。有一本《软件需求》的书讲的很系统，从事需求工作的都值得仔细阅读。对于采用面向对象的需求开发和分析方法的，一定要熟悉RUP统一过程和用例分析和建模。
对于管理软件都离不开其涉及到的业务领域，因此要做好需求分析工作必须要熟悉管理软件所涉及到的业务领域，对业务领域相关的标准模型进行分析和研究，对业界的一些标准和最佳实践进行熟悉。比如做供应链管理系统和软件应该熟悉业界标准的SCOR模型，做ERP的应该结合现在的业界比较大的厂商的ERP产品进行学习，对于研发管理系统可以结合PACE和IPD等等。只有熟悉了业务领域才可能在需求调研和分析的时候提供很多有建设性的意见，或者说需求分析人员不是被用户牵着走，而是真正的可以引导用户。
3.项目需求分析的步骤和输出有哪些
开始首先是需求的收集，需求收集可以通过调查表，访谈，业界标准，会议讨论沟通等多种方式进行。需求收集第一是要能够很好的描述现状，第二是要搞清楚用户的期望。同时一定要弱化用户期望系统怎么做，因为用户并不熟悉系统实现和内部原理，我们的软件需求不仅仅考虑的是功能的实现，还需要考虑需求复用，业务抽象，可扩展和配置等多方面的问题。
收集回来的需求就需要开始进行分析工作，分析包括了动态行为分析和静态数据分析。动态行为分析涉及到用例分析，业务流程和活动输入输出的分析，数据流分析，业务操作规则分析。静态数据分析设计到业务对象建模，数据字典，组织结构，权限等分析。在这一个阶段的重点就是需求的系统化和结构化，最好要体现到规范的文档中。在软件开发过程中我们最强调的需要文档化的输出就是需求文档和总体设计方案文档。
需求分析阶段还有一个重点的产出就是原型和DEMO，为了更好的和用户沟通并挖掘需求，我们需要将我们理解后的想法更加形象的讲述给用户，所以原型就显得额外重要。不管是否是抛弃的原型，都需要客户看到的原型和最终实现的系统基本一致，因此原型开发需要投入一定的时间，并根据客户反馈的信息不断修正。在原型中多投入些时间，就会多减少一份后期需求变更引起的返工时间。软件原型是降低需求变更风险的有效方法。