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

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

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

    根据排队原理,用户故事的不确定性是导致系统开发周期非线性膨胀的主要因素。不确定因素主要有:不确定的迭代长度,不确定的用户故事集合,用户故事大小差距很大,团队成员不固定发布时间,不固定新的需求到达时间。解决的方案就是让一切变得确定,稳定。需要把大的任务切成类似大小的小的用户故事。这样就大大减小了不确定性,提高了效率。

    个小功能的完成都是一个反馈点,可以及时沟通信息。大块需求导致很多需求的缺陷往往在最终测试的时候才发现的,如果不能及早完成,尽快测试,缺陷会越来越难以解决。软件很少一次就做好,多次反馈以及不断演进才是一个真正能把功能做好的策略。沟通更加及时,有问题可以及时发现,立刻解决,而不需要过长时间的等待。

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