需求收集真正的体现了需求的市场和用户驱动。访谈，调查表，头脑风暴，竞争对手和产品分析都是需求收集的方法。需求收集我们需要搞清楚用户真正的需求，问题背后的深层次问题，这样才可能为挖掘需求提供数据。需求收集的过程应该流程化，收集的需求应该分类入库的归档化。必须将需求收集活动看做为一个结构化的流程或过程，以真正的促进收集的过程和采集的数据的有效性。
收集的需求在论证分析中应该确定优先级，而优先级的确认应该引入价值工程，即我们应该认识到一个需求的重要性应该体现到它对产品价值的短期和长期的增值上面。要理解这个，就必须要考虑收集的需求是普遍需求还是特殊需求，是核心业务对应需求还是辅助业务对应需求，是使用频率高的需求还是偶尔使用的功能点需求。我们必须有清晰的头脑来分析用户急的是否就一定是优先级高的需求。
用户往往习惯了给我们提希望系统实现什么功能，这些需求往往是用户已经转换后的需求而不是原始需求。当用户遇到业务上的问题的时候他们往往假设了一种实现方式，如果在需求收集过程中错误的把问题的解当做需求，则我们就忽略掉了真正的原始需求。需求收集的重点应该在用户真正面临的问题域和问题场景的收集。
需求收集人员的业务背景和经验往往对需求收集有效性有很大的影响。需求收集的访谈过程不是简单的听用户如何讲，而是需求我们去引导用户讲出他们真正面临的问题。通过我们积极的沟通让用户把他们真实的想法真正的表达出来。
需求收集是整个软件产品开发的源头，是确定产品方向和定位的重要活动。需求收集活动出现大的误差将是方向性的重大错误。如果我们开发出来的产品不能真正满足用户的需要和得到用户的认可，那产品本身就不可能创造价值，及时这个产品有很好的质量，易用性和功能等，这个产品仍然是失败的。
需求分析和开发
需求分析工作需要意识到是包含了业务分析和系统分析两部分内容。对于业务分析包括了业务流程分析，组织结构和岗位角色分析，以外的对象分析，数据流分析，重点是描述现在。系统分析的内容重点是将需求转换为系统可实现的软件需求，因此必须要考虑到需求的可实现性，如果对于面向对象分析则重点在用例分析，业务对象建模，业务规则分析。系统分析最好是有软件开发经验的人和业务背景的人进行，这里的一个重点就是要把软件开发中已经成熟的分析模式和模型和实际的业务进行匹配。
软件产品要能够适应需求的变化，不仅仅是软件架构上的可扩展性考虑，更重要的是在需求分析阶段就需要考虑软件需求如何适应用户需求的变化。对应用户经常可能变动的需求点进行抽象，引入一些标准的可配置的模型，如权限模型，工作流模型等。软件需求对业务需求和用户需求的一个处理要点就是会考虑到哪些经常变化的需求需要转换为灵活的可配置的需求。
用户都不清楚自己要什么或者说用户的需求经常变动更应该促进我们去改进需求分析和开发的过程。在这个时候系统分析员的开发经验和业务背景将起到很重要的作用。需求的一种变更对于软件开发往往是一种必然的情况，只是如何把它变更的范围控制住，如何实现需求的变更不是要修改设计和编码，而是通过灵活的配置来实现的。
收集来的用户需求如何转换为需求规格说明书，中间的一个重要过程就是需求分析和开发。这样正好体系一些需求分析工作的重点内容，通过识别需求的优先级以更好的安排项目资源和进度，有的放矢。通过对原始需求的分类，合并，抽象以提取通用的需求模型。通过识别非功能性需求以增加整个系统的健壮性，性能和易用性。通过对需求模块单元的划分，流程和规则的描述，功能点分析为项目进度计划安排和进度跟踪创造条件。因此我们将需求分析是一种业务和系统的模式匹配，如果才能够匹配好就是需求分析的责任。
需求管理
应该首先看到需求管理的目的首先为项目管理服务，结构化的需求管理使项目管理真正做到可视化，另外需求管理为用户服务，通过有效的需求管理能够更好的满足用户的需求，提升用户满意度。最后需求管理为后续项目提供支持数据和依据，因为需求管理的内容是结构化和文档化的，这些是内容是项目重要的过程资产。
要管理需求，则我们的需求必须是结构化和文档化的，否则就谈不上需求管理。因此需求管理必然会涉及到配置管理相关工作。同时为了量化的说明需求管理的有效性，我们的需求本身又必须是可度量的，需求功能点的粒度应该在一定范围内。需求规格说明书是需求管理的重要对象，必须文档化，而且会在整个软件开发生命周期中被多次使用到。
需求全生命周期的管理的一个重点就是需求的状态管理，用户提出来的需求就是是否实现了，现在处在哪个环节都需要依靠需求的状态管理和跟踪来实现。因此需求分析阶段需求功能点的条目化就是需求状态管理的一个重点，而需求状态跟踪的过程正好就是我们对项目进度和状态的跟踪过程。如果项目管理的状态监控的好，则需求状态管理也可以做好，同时拆分后的需求状态管理为我们增量和迭代开发提供了基础，有了这个才可能真正做好项目挣值管理，才可以更好的应用挣值中的0-100原则。
需求的变更控制重要性体现在真正的使甲乙双方对范围的承诺有共同的重视。当有了共同基准依据的时候才能够真正的体现用户满意度上面，同时需求变更真正的体现出项目计划的严肃性，保证项目计划的受控和严格执行。需求老发生变动，项目老延期都是需求变更没有做好的一种表现形式。对于已经开发完成的软件产品，我们更需要有结构化的需求变更流程，将变更的影响分析影响植入到流程中，这样才可以保证整个软件产品的稳定性。
