“用户需求”这一概念并不是某个人特意造出来的词，“用户”和“需求”这两个词字面上的意思都很好懂，组合在一起用也不需要过多的解释，谁都能明白。如今 “用户需求”这个词包含着十分广泛的、模糊的定义。所有用户需要的，用户提出的要求都可以被称为用户需求。但是其中有两个问题需要注意：
1、试图满足各种“用户需求”，最后发现众口难调。往往在细小的、具体的功能上，我们很在意“用户需求”。用户说出来的要求通常是不系统的，是想起啥就要啥。如果产品的设计者只是简单的按用户的要求去做产品，那么后果是…“隐身，对其隐身，隐身对其可见…”按照这种“惟用户需求是从”的方式做一阵子，设计者往往会感叹众口难调，于是很容易陷入另外一种错误中…
2、认为用户其实不知道自己想要什么
“如果我问我的用户，他们只会说要一匹更快的马。”—亨利•福特
“如果只按用户需求来做，永远也不会有walkman。”—很多讲产品策划的老师都这么说

     在这个标榜“用户价值”的时代里，谁一张嘴都是“用户有这样的需求…”“…这是用户需求啊~”或许过分嘲讽类似的说法并没有什么积极的意义，产生这样的说法还是因为我们并没意识到滥用“用户需求”概念的害处。

     因此用户的需求到底是什么就需要“用户需求分析”，所谓"需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。可以说，在软件工程当中的“需求分析”就是确定要计算机“做什么”，这就是用户故事。 可以工作的软件能够更好、更真实的反应项目进度状况。精力和智力所限，人天生只能关注很小的部分。

    根据排队原理，用户故事的不确定性是导致系统开发周期非线性膨胀的主要因素。不确定因素主要有：不确定的迭代长度，不确定的用户故事集合，用户故事大小差距很大，团队成员不固定发布时间，不固定新的需求到达时间。解决的方案就是让一切变得确定，稳定。需要把大的任务切成类似大小的小的用户故事。这样就大大减小了不确定性，提高了效率。
    每个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往在最终测试的时候才发现的，如果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一次就做好，多次反馈以及不断演进才是一个真正能把功能做好的策略。沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。

    使用用户故事，也让需求变得简单、明了，一次很容易让不同人同时去完成。