需求分析的原则
不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险,这里的"成功"是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险. 客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与.究其原因:一是因为开发人员感觉与用户合作不如编写代码有意思;二是因为开发人员觉得已经明白用户的需求了.在某些情况下,与实际使用产品的用户直接接触很困难,而客户也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同经历整个开发过程. 系统人员在实践过程中,也有些感觉,在实施一家公司的项目时,若无足够的用户参与,系统人员获得的需求是片面的,不完整的,这样系统在需求之初就埋下风险.
在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致,这使得问题更难解决.实际上,问题根源在于用户需求的改变和开发者对新需求所作的修改. 要想把需求变更范围控制到最小,必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明,并将此说明作为评价需求变更和新特性的参照框架.说明中包括了对每种变更进行变更影响因素分析的变更控制过程,有助于所有风险承担者明白业务决策的合理性,即为何进行某些变更,相应消耗的时间、资源或特性上的折中. 产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护.插入补丁代码使模块违背强内聚、松耦合的设计原则,特别是如果项目配置管理工作不完善的话,收回变更和删除特性会带来问题.如果你尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它.这样设计阶段需求变更不会直接导致补丁代码,同时也有利于减少因变更导致质量的下降.
1.发现需求。了解用户需求，发掘用户需求，而不是去想创造需求。 2.需求真伪的分析。用户往往会说这不好，那不好，需求分析应该更注重为什么用户为说不好，他们可能真正需要的是另外一种东西。 3.需求的优先级判断。需求分析需要能够敏锐的把握每个需求的优先级，交付给产品或者开发。 4.需求的平衡。需求在有些时候是矛盾的，需要了解不同角色的需求，怎么平衡和利益最优化。特别是用户需求和公司战略冲突的时候最为严重。 5.需求的对接，成为需求方和产品开发方的桥梁和纽带 6.需求的管理，监督需求的解决方案、落实，并跟进落实后的使用反馈。
纯理论化的用户需求分析流程。
一、产品定位是什么：这点是重中之重，产品不知道是干什么的，解决什么问题的，目标是什么的，那这个产品一定悲催了。
二、目标用户是谁：这点也很重要，要定位产品都面向哪些用户，我觉得很少有产品能说自己的产品适合所有用户的，总归会有一个定位的，而且要将目标用户进行分类，在每类抽取出用户角色卡片进行分析（其实这步现在很多产品都不做的，包括我自己做的产品）。
三、竞争对手是谁：特别是对于已经是红海的市场来说，看清楚目前竞品都有哪些功能，为什么做这些功能而不做那些，市场占有情况如何等，并划出产品的SWOT图，这点其实个人认为是最重要的，即使不进行目标用户分析，也要做关于竞品的分析工作。
四、用户场景分析：开始对用户使用产品的几个重要的场景和流程进行分析啦，这个分析清楚后产品的需求列表就可以形成了，并根据前期的竞品分析的结果将产品的需求进行优先级划分。
1.在没有开始你的项目之前，可以先通过相关领域的同行，竞争对手那里积累点经验，看他们是怎么做的 2.直接找你的潜在用户做问卷调查，让用户参与进来，不仅集思广益，而且有利于培养种子用户，前提是给他们一些好处，没有物质上的也要有精神上的。
需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求. 关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".
