1、需求是什么
通常意义下，软件行业对需求的定义可能是由“需求方”以文字，口头，示意图 或者其他途径提出的“关于功能要怎么做”的表述。
2、需求有什么问题
往往软件开发行业陷入了一个困局，明明是按照需求方提出的需求，逐条实现的，为什么需求方往往不满意，做完又马上提出一堆变更，搞得双方都一肚子意见
3、真正的需求是什么，应该怎么分析
真正的需求应该把握这几个要点，“目的”，“方式”，“测试”，“结果”
逐条解释一下，
目的：需求的本质，这个需求是要做什么，这个在很多关于需求的分析中都讲得非常清晰了，即分析用户提需求的动机，是要实现什么。拿个经典的马车与汽车的例子，需求是要更快的马车，但是实际上如果给出汽车方案更符合需求。软件开发过程中这样的例子很常见，比如说客户要在某个位置增加一个表单，以实现浏览到这个页面的同时，顺便能提交一个什么东西，实际上如果针对这个需求给出新增一个功能模块，单独放在首页入口，或者是一个专题页面，这样从推广，还是从页面美观性更合理。
总结一下就是：分析目的，从而导出多种实现方式，择优。 （因为往往提的需求本身等价于某一种实现方式，需要追溯到原始节点，然后发现有多种路径）
方式：和目的环环相扣，目的导出方式，而方式决定了后面的结果是否满足目的。
测试：为什么会有个测试呢？这里的测试是指验证需求分析。 给需求方确认的东西以往都是文档，一堆设计图。 但是很多细节没有体现出来，客户也是按照自己的想象去脑补了这些部分，造成什么结果呢？ 产生了两份需求！！ 一份是你认为的 文档+UI+有一些没有直接体现的细节 的完整需求， 一份是客户认为的 文档+UI+自己脑补的细节 的需求。 后面就不用多说了吧。
那么应该怎么做呢？换个名词就懂了，表演。 将系统以一种什么方式真实还原给客户，让客户最大程度理解你们即将做的软件，效果是怎样的。
业务高保真原型+详细演示。 后续安莫比会发一些具体案例，这实际上是一个软件的沙盒演练过程，和客户去推敲。
结果：结果是以上3部分最终的节点。是怎样的结果完全取决于前面环节是怎么做的。
原文地址：https://www.cnblogs.com/andmobi/p/11828647.html