这几天每天都是早上5点多起床，做公交倒地铁再倒地铁再倒公交，在路上都光折腾了两个多小时，参加了北京高级需求分析师的相关培训，我们每天都提需求，也
因为需求我们的项目都存在不同的延期，需求变更管理，需求分析，需求管理等都是我们软件项目中存在的一个大问题，本人也是在不断的学习过程中，对需求的认识也还很肤浅，对于这次学习把一些心得和大家分享分享，其中系列文章中都是经过自己加工写出来的白话，希望能和大家探讨和学习，有不正确地方希望能给予指点。
1) 需求是什么，需求是软件成功之本。在IT行业分为需求工程和软件工程，而不是分成什么设计工程等。在软件行业，创新工程和创新点更多的是指需求工程，因为正确的需求可以降低成本和缩短时间，而错误需求会对整个项目造成多米诺骨牌效应，遗漏用户需求也将导致遗漏系统需求，又将导致遗漏设计模块，最终导致功能失效。需求工作对软件项目的整体影响
2) 需求能力成熟度模型
l 初始级-模仿级：认为已有产品或同类系统比较好；认同原有使用习惯；认同原来的使用需求；忽略自己的个性化领域需求；忽略自身个性化的使用习惯；容易走向“削足适履”式建设道路。
l 发现级-领域经验积累期：注重领域需求的分析；注重用户自身已有的使用习惯、质量需求；建设了项目需求信息数据库，具备同类问题的需求重用；具备了需求模式重用的特征；有助于新人快速熟悉所在行业，全面了解已有系统的支撑能力，快速入手。
l 创新级-创新领域需求：创新级-创新领域需求；总是能创新、创造新产品；具备市场细分能力；具备信息战略规划能力，能够用信息规划带建设，用项目辅助企业创新、发展，获得更多利润。
2. 需求的有效方法
在软件工程中，科学的方法是“管理阶段化，开发迭代化”。管理阶段化包括需求分析、设计、编码和测试等。开发迭代化，指的是对于每个阶段出一个版本，而且这个版本是可视化的。这软件工程的管理方法不细讲，下面讨论关于需求的有效方法，怎样有效的开展进行需求分析等。
在需求的有效分析方法中归纳为三点：有组织、有流程、有绩效
1. 有组织：
双方前期开展有效的培训，不管是甲方(项目提供方)，还是乙方(软件开发方)提供财力和物力，在互相尊重的前提下开展有效的培训，培训内容主要围绕项目的业务开展，先由甲方讲解生产流程或者业务流程等，让甲方讲讲他们的业务困惑，已进一步去了解甲方的业务或需求。乙方根据甲方的讲解进一步分析，引导甲方的需求，共同协商业务领域等问题，这样能达到甲方去体验乙方的生成流程或业务，乙方更能体会或理解软件的需求，使双方能达到一个共识，共识很重要，所有需求的开展都在于这个共识之上，比需求更重要的是共识。
可能有人会认为这个组织和培训不好开展，客户会说“我很忙”，这时候怎么办？方法也有很多种，但可以提倡两种有效方法：权驱动方法和利益驱动方法，权驱动方法涉及到项目的关键人物，下面会在各方面分析讲解。
2. 有流程：
需求怎么开展？去问对方，你要什么软件？你想要什么功能？显然这是很业余的。如果你和客户说，你想要鸡腿呢还是想要鸡翅？显然这种才是去引导用户。在这里提几个有效的需求分析开展流程有效方法：
1) 标杆法：如果你们之前没有做过类似的项目或没有类似的经验，但你们是有这个能力去做的，但为了能引导用户或者有效的开展用户需求，怎么办？可以以业务中或者一些已经存在的项目或案例为标杆进行引导。如，你们要开发一个邮件系统，但之前没有做过，你可以以126或者新浪等已经很成熟的邮件系统作为标杆，功能上界面上可以去引导用户，引导用户有效的开展需求。
2) 系统原型法：这个是我们公司自己用得最多的一种方法，而且这个方法也很有效，可以根据用户初步的需求做一个系统的原型，即我们所说的DEMO，根据这个DEMO去引导用户，有效的开展更多的需求。但这个方法也存在着许多的困惑，如刚开始的时候DEMO做的很详细，客户看了下说很好，然后回去后开发人员就开始埋头进行开发，过一段时间后，用户就说这个不是我们想要的，我来和你讲讲我想要的吧。怎么办？
所以，在开发系统原型的时候也要采用迭代式的方法，前几个版本不要过于细，根据你所理解所知道的去做原型，慢慢的去引导用户，迭代的出原型。
有些人会说，我们公司更注重于文档，需求一般采用文档进行管理和确认。其实系统原型也是种文档，而且是种可视化的文档，现代的软件工程都提倡体验式的软件工程，可视化就是可以去体验的。
在《走出软件作坊》这本书中，作者会经常提到一个观点，沟通有效于文档，文档是沟通和协助之间的一种服务，什么ROSE工具、JUDE工具，你能进行有效的沟通和协调，大家能理解，TXT都是很好的。
3. 有绩效：
我干死干活，别人闲得要死，照常都发一样工资，我为什么要干这么多？怎么保持团员主要主干的积极性，保持主要主干的目标一致性，一股劲向前，最好的当然是通过绩效进行考核，成功的奖励，失败的惩罚等。对于用户的积极配合的人员也应该适当的给予一些奖励等。
