用户需求就是能帮用户解决实际问题的一套解决方案。
在经历过多年的企业项目之后，发现项目中最大的风险来自于用户需求的变更。需求变更产生风险的最大原因在于未做好需求处理，所以在此希望和大家探讨下企业应用的需求处理。
先给大家举一个未处理好需求的例子：用户说要做一个实时监控的功能，要监控网络中实时发生的问题，等我们做完之后，用户才发现实时监控发生的问题数据量太大太多，根本看不过来，也不知道什么问题是重点，然后用户要求修改为监控统计数据，然后我们就又重新做了一遍。
沉思一下。。。。。。。。
需求处理中遇到的问题：
需求不断：用户往往今天说要这明天说要那，你不知道用户的需求何时是个尽头？也不知道应不应该满足客户提出的需求？
需求总变：你埋怨客户总是变更需求，用户说你是专业人士你应该能分析出我想要的，怎么一个需求搞这么久都搞不定呢？
所以需求处理人员需要具备：
1：对产品的理解以及对对产品功能的熟悉。
2：对项目的理解以及对项目范围和边界的把握。
3：站在比用户更高的层次思考需求，因此你必须具备用户的业务知识。
4：善于引导用户，我们做项目目的是为给客户带来价值，而不是满足客户的需求。
5：分析用户：用户是技术型，管理型还是饭桶型的，技术性的喜欢抓细节，管理型的喜欢抓整体，饭桶型提不出什么需求，都会说界面不好看。
需求处理人员必须得清楚：
1：用户描述需求时表述的那些话不一定是用户需求。
2：用户所说的需求不一定是用户想要的需求，描述和想象始终会存在差距。
3：谁是真正能拍板的用户。
4：需求的满足需要一个过程。
5：用户的需求基本都是拍脑门说出来的，很少是冥思苦想了很久。
6：大多数情况下，需求没有变，而是你没理解用户真正的需求。
需求分析的过程
将用户的所提出的需求，放到用户的业务场景中去分析，分析用户是想解决一个什么问题，是否能为用户带来价值。这个需求到时候是否能真正用起来，这需要考虑用户的组织结构，部门角色，用户的推动力。
此需求是否属于项目和产品范围之内，不是则不做。
确认需求之后，思考该需求是否会存在衍生需求，然后思考下能否用我们产品中已有的功能变相的来满足客户的需求。
如果确认需要开发，需要鉴定该需求我们是否能做，做多久，做初步的可行性分析。
需求处理
将分析出来的需求，同用户确认，有界面的最好用原型法，假如用户不和你确认（我遇到的大多数情况是这样的），你可以发一封邮件给用户，并说请您确认下需求，假如没有异议，我们后天就按照这个开始做了。他不回你就表示用户默认了。
需求归类：该需求是项目需求还是产品需求，是否能产品化？划分到产品的哪一个版本里？