需求不简单
软件开发貌似是一件很容易的事——用户告诉开发人员他的需求，开发人员使用他所掌握的一种开发语言来实现需求。
可是当把开发完成的软件交给用户使用后，用户经常会对软件感到不满意，觉得不这儿好用那儿不好用，还老出现问题。
这些问题很大一部分都是由于开发人员没有正确理解用户的需求而带来的。
需求并没有看上去的那么简单。
需求是需要挖掘的
虽然用户是最了解需求的，但是当开发人员和用户进行交流获取需求的时候。用户所表达的需求未必就是用户真实想要的需求。用户受限于他的能力、经验以及所处的环境，可能无法在一次交流中就能够最准确的表达出真正的软件需求。真正的软件需求可能需要开发人员不断地诱导客户深入思考才能挖掘出来，或者是需要开发人员采用一些技术手段来挖掘，比如原型法、在真实的工作环境下演示。
不要忘记非功能性需求
影响用户满意度的往往不是功能需求，而是非功能需求。
所以不管用户有没有提到非功能需求，有没有把非功能性需求表述清楚，开发人员都不要忘记对非功能性需求的挖掘和开发。
想想看，如果软件对用户的一个简单指令的响应都需要好几分钟的时间，哪个用户能忍受？响应时间这样的需求，就算用户没有专门提出来，那么开发人员也要尽量去满足。
相对于功能需求来说，用户更难把非功能性需求说的清楚。但是开发人员不要忘记对非功能性需求的开发，要尽可能地和用户一起将非功能性需求量化。例如：用户要求响应要快，这只是形容词，是无法验证和确认的，开发人员应该量化说明响应时间，并取得用户的认可，譬如说，在20个并发用户下，平均响应时间为一秒。
学习领域知识
在与用户交流需求的时候，用户通常会按照他的工作习惯使用他的领域知识的语言来描述需求，这对于开发人员理解需求是一个困难。所以开发人员在与用户交流需求之前，要尽可能地去学习专业领域知识，这样才能理解用户的想法，减少误解需求的概率。
注意需求的可读性
在与用户交流需求的时候，开发人员要尽可能地使用用户熟悉和理解的语言或者图表等其他方式来交流需求。否则会给双方的交流带来不小的障碍，会影响双方对需求的理解与认知，会造成一些本来可以避免的对需求的误解。
应对需求变更
需求不变是个例，需求变更才是常态。所以开发人员应当做好需求变更的应对措施：深入挖掘用户需求，做好需求的验证和确认，预留变更的工作量，做好需求管理，执行严格的需求变更流程等。
总之，想要减少有需求带来的问题，就要切实做好需求获取、分析、确认和管理等工作。
这正是：
需求一点不简单，工作一环扣一环
谁要对他来小觑，跌个跟头不算冤
参考书目：学校没教的软件工程课，作者：周忠信，出版社：化学工业出版社