1、什么是需求？——理解需求和功能的区别
我们举个例子，比如用手机打电话。首先，你需要开机，然后，手机通过无线电信号连接到基站，然后，打开手机通讯簿，找到小朱的电话号码，接着，拨号、通话，通话完毕，挂断。
在这里，打电话是一个需求。给小朱打电话是一个需求的实例（需求的实例，有时也称为应用场景，可以拿来做系统测试用例，但是不能只开发专门给小朱打电话的手机！）。对于手机软件而言，必须提供：开机、联网、通讯簿、拨号、挂断这几项功能，才能满足打电话这一个需求。
我们在做软件的时候，常常会碰到：我已经做完了所有的功能了呀，为什么用户还是不满意呢？这就是将功能和需求混淆了。如果手机分别提供开机、联网、通讯簿、拨号、挂断这几项功能，而不通过打电话这个需求将这些功能有机的联系起来，你说消费者还会买这款“具备了所有功能”的手机吗？
2、需求是需要分析的
需求来自我们的用户。但，用户说的不一定是他想要的，他想要的未必都说了出来（也许是他不能、不会），所以，需求需要分析。
有时候路上碰到熟人，说：“小朱，有空吧？我请你吃饭去！”我其实有点饿了，但是习惯性的客气几句：“啊，不啦不啦，谢谢、谢谢，改天改天！”这叫做“口不应心”。这种场合当然是处于客气，但是，对于软件用户，由于不是计算机专业的原因，的确不能说出他想要的来。
比如现在天气热了，用户对你说，“小朱啊，帮我买只冰激凌来！”如果我不假思索，跑去买了一只给他，他肯定说：“哎呀，我要的是巧克力味道的，你买的是牛奶的！”无语～～～只能跑去自掏腰包买一个牛奶的。如果是软件系统，那么就意味着加班赶工重做。。。
好了，第二次，另外一个用户要买冰激凌，我这次学聪明了，先问：“您是要牛奶的，还是巧克力的？”他说，“巧克力的。”，我继续问：“那么是什么牌子的，准备买多少钱的？”“伊犁的，2块钱的那种。”好的，拿钱去买。
心想，这次应该没有问题了吧？买了给他，一尝，他说了，“哎呀，不对，还是牛奶的比较好！”晕倒～～～
到底要怎么样呢？
第三次，又有人要冰激凌，我决定这样：“您为什么要冰激凌？”，用户说：“因为我口渴。”我分析了一下，在夏天口渴的话，冰激凌并不是解渴的，相反，甜腻腻的冰激凌吃了会更渴；什么东西解渴呢？冰冻的绿茶是很解渴的，于是，我说：“您口渴的话，我建议还是喝绿茶比较好。冰冻的绿茶更加解渴。”如果用户是理性的，他肯定会同意。于是我买来绿茶，口渴解决，项目圆满完成！
如果用户不理性呢？最好的做法是不要让这些人成为你的用户。如果碰到了，解决的办法也很多，但通常都要付出代价。比如，同时提供小份的冰激凌和绿茶的试用装给他，他一试就知道要什么了。但是，我们却要付出制作小份试用装的代价。对于软件系统，这个代价有时候是很昂贵的。
所以，请不要将《需求规格说明书》作为《用户要求记录单》来用，应该先运用你的专业知识来分析一下。
3、需求是会变的
通过分析、沟通，终于确定了一份需求文档，签了字，值得庆祝！但是，先别大意，因为需求肯定会变的。
需求会变是一个现实，就像太阳每天东升西落一样。随着工作开展的深入和对于系统的熟悉，用户原来的想法肯定会和刚开始看一份抽象的方案不一样。既然不会不变，我们只能想办法来应变！（残酷啊，现实！逼得我们进化！）
通常有2个手段：
（1）积极的沟通。及时了解变化，并进行变更控制管理。
（2）在系统的架构设计上，为变化做准备。面向对象也好、面向服务也好、三层也好、四层也好，我们为什么把代码分开层次，为什么提供那么多抽象的接口？都是为了应对变化，为了我们在这个需求像云彩一样变化的环境中能够适应。
所以，在痴迷的学习这些架构、设计模式的时候，别忘记是为什么要学习他们。
4、保持沟通渠道的畅通
说了上面一大堆，有一个前提还没有讲，就是和用户的沟通渠道。（当然同样重要的是公司内部的机制和沟通渠道，不过这不在本次的议题中，以后有机会再谈。）
即使和用户争吵也比不相往来要好。需求是需要沟通来了解、来确认、来变化的。沟通，未必能够做好需求（原因多方面，比如用户对系统并不关心。。。）；但是不沟通，项目就失去了成功的机会。
无论无何，留住这个沟通的渠道，也许突然有一天用户对你说：“哎呀，你辛苦啦，上次提的那个功能不做算啦！”：）
