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