听到过一个说法，说需求分析与技术分析的最大的不同是思路的本质差异，技术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用这种方式思考，可以把大问题分解成小问题，发现难点逐一攻克。很多做需求的人都是开发出身的，所以开始往往会用这种思路做需求，听到客户提到的功能点，直接想怎么做系统设计了，有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。而真实情况是，需求分析是“树叶——树枝——树干”的分析过程，一定不能漏掉提炼用户需求的这个过程。
确实很有道理，后来仔细一想，其实另有两个问题值得继续思考补充在这个说法上。
第一，这里玩了一个偷换概念，两者的“分析”定义不同，按照逻辑学的通俗定义，第一种分析是真正的分析，而第二种“分析”似乎更应该被称为“归纳”。可是，如果现在提出一个“需求归纳”的概念，连我自己都觉得拗口，所以继续用“需求分析”这个词。
第二点更关键，“树叶——树枝——树干”的描述并不完整，它只是前半部分。其实完整的“需求分析”是一个先归纳后分析的过程，试想如果做到“树干”就结束，后端的开发人员还是不知道要做什么东西，所以我们还要继续把树干再次重新分解成树枝、树叶。
小结一下，需求分析的目的是把从客户那里收集到的“用户需求（更接近Want，有时候甚至是解决方案，但我们不能不假思考的照做）”做归纳，然后得到一个总体概念（用户的Need，真正的欲望所在）后再分析、分解为“产品需求（给出我们的解决方案）”。
举个例子结束：小明说要吃肥牛火锅（18元，iamsujie补：涨到20+了），我们分析认为他是饿了，不是馋了或者真的想吃牛肉，最后给出我们的方案，扔给他2个馒头（0.5元*2），结果他虽然眉头一皱，但考虑到性价比（省了94.4%的成本啊！他省的多我们的利润空间也会大些），还是很愉快的吃了……
伟大的需求分析师。
]]>1、设计模式
为什么要先说设计模式？因为设计模式在这些概念中是最基本的，而且也比较简单。那么什么是设计模式呢？说的直白点，设计模式就是告诉你针对特定问题如何组织类、对象和接口之间的关系，是前人总结的经验。比如我要在代码中实现一个全局唯一的配置类，那么就使用Singleton模式。设计模式在实际编码工作和设计框架时会被使用到，而更高层的架构和平台则不会太关注它。
2、框架
做WEB开发接触到最多的框架可数ORM框架，ORM框架只是所有数据关系映射框架的统称，具体的如NHibernate、ActiveRecord等，框架是为了解决特定问题而存在的，其它诸如模板框架、缓存框架，框架不能直接使用，需要二次开发。
3、架构
从大的层面来说，比如针对公司业务的B2C网站系统架构，里面可能会用到多种解决各方面问题的框架，关注的是技术整合、扩展、可维护性。换个角度，在框架中也会涉及到架构问题，比如开发NHibernate框架，也需要考虑如何进行设计。
4、平台
平台的概念类似框架，但又结合的架构的考虑，它是更高层面上的“框架”，准确说是一种应用。它是针对企业用户，为解决企业业务需要而形成的产品。
]]>迭代是不能并行的，迭代的并行是指迭代任务，比如从3.1-3.31号是一个迭代计划，该迭代计划需求人员可以分析功能点5-功能点10，设计人员可以做功 能点3-功能点7的设计，开发人员可以做功能点2-功能点4的开发，测试人员可以做上个迭代周期发布的代码。 迭代的并行是指工作流的并行。
大家看到迭代计划是比较复杂的，因此对项目经理的经验要求很高。
增量模型一般是指具有底层框架和平台的项目，在该稳定的框架和平台上，来开发和增加具体的业务功能。每个增量之间相对独立，各个增量可以并行开发， 比如：3.1-31号实现增量1（包含5的功能点），3.20-4.15开发增量2（包含另外的4个功能点）。增量内部是瀑布模型。
两种类型的区别在于迭代是基于IBM的RUP的以架构为核心，用例为驱动，角色职责划分不同，在同一时刻项目内部需求、设计、编码、测试的活动都在发生。迭代适合需求不明确、架构风险大的项目，增量适合需求比较明确，架构比较稳定，而且增量功能的实现基本不影响架构。
还有一个不同就是迭代计划是基于角色的，增量计划是基于任务的。
两种类型的相同之处，每个迭代和增量结束后都有产品发布。
]]>