最近看的是第一章：需求实践现状分析：
失败的根源：
“在中国做软件太难了，客户连自己的需求都说不清楚”。这句话经常在我们耳边响起。但是正所谓：“它山之石可以攻玉”。
在做项目的时候，很多项目都是进度超期、成本超支。最主要的原因之一就是项目的重新启动，
在Standish Group总结的十大成功保证和十大败因中：
十大成功保证中的三个直接与需求有关，十大败因中与需求有关的更是高达五个，
项目失败的初步分析：
不完整的需求：
他的得票率是第二。那谁更有可能对需求的完成行进行评价呢？，我想大家会一致的认同用户代表要比开发人员更适合对完整性进行评价。
想让用户代表更好的参与到完整性评价中，就必须采用“业务导向”，的组织结构。而不是让用户将一大堆技术动作翻译到自己的业务场景之中，。我们要充分利用属性层次结构将宏观的信息与围观的信息进行有效的剥离。
缺乏用户得参与：
其背后存在的几个原因是：事不关己、高高挂起，逃离无趣区、被你赶走。
不切实际的用户期望：
用户总是很天真的提出大量的需求，有些技术根本无法实现，有的经费脆弱。其原因就是在软件的无形和成本的不透明，要解决这样的问题更需要的是从业人员主动地帮助客户更好的理解软件的成本，简单来说就是做不到是无效的，要说明为神魔做不到才能解决问题。
需求变更频繁：
其实最了解用户需求的是软件本身，越经常使用到的功能，就是越重要的功能，那些根本没有几个访问量的功能模块，一定是那些不在需要的。
透过本相、分析本质：
需求变更频繁：
说明需求的描述与沟通存在问题，导致需求的在交流的过程中产生失真，因此应该嘉庆需求过程中的管理，加强沟通手段的管理。需求变更集中在流程间：说明需要采用工作流引擎。及种子啊用户界面方面：寿命需要开发用户界面动态生成器。
上线阻力大：
主要是利益冲突、工作量增大、
运行效果差：
这种现象的存在，从根本上说就是软件项目在开发过程中缺打有效的目标作为指引。与实际的业务过程存在脱节的现象，而要缓解这一现象，在不同的层面有不同的方法。
完全崩溃：
实际上最常见也是最主要的问题在于非功能需求的描述上，我们需要更有效的认识非功能需求的特点，采取更有效的措施来传达和环节这一问题的关键。
方法论与需求工作：
计算模式：
这方面的经验是，对于计算机经验不太丰富而且工作比较单一的用户，也许更加固化的准用客户端更加合适一些。当技术团队再为采用B/S还是C/S的时候争论不休，戴着需求分析这顶帽子的朋友们一定不要忘记从要用户的角度分析那种模式更加合适更加适用。
软件工程方法论：
重方法论更加强调前期设计，未来设计，而敏捷方法论则更加强调职位现在设计。未来在重构他，而就是这个最为本质的区别才是根据项目实际特点进行正确选择的基础。
开发思想：
主要是成熟度、溯源、和了解局限性。
技术并不能解决所有的问题，因此对于任何一种技术都既有优势又有不足，只有全面的了解其局限性才不至于误用和滥用。
小结：
需求问题一直都是一个很大困扰。这就需要我们透过现象看本质、努力分析、总结经验、真正做到前车之鉴、后事之师。