很久没有在博客园写随笔了，今天补上，O(∩_∩)O哈哈~。
需求到底是什么？特别是对于软件开发来说，需求是最为关键也是一个项目能否成功的判定标准，然而，正式这个标准，让需求背负了太多的东西。
为什么从CRM定义想到需求到底是什么这个问题，只是因为最近项目做的是CRM，对CRM的定义，似乎就是原始的需求意向，然而就是这个定义，却更让需求无所适从。
CRM：客户关系管理系统。
关键字：客户，关系，管理。
那么就从这些关键字说起。
一、客户：
什么是客户？客户是我们的工作动力和目标；是给我们为其服务的机会而给予我们的恩惠；是我们为其服务，使他们和我们都得益，实现客户利益和企业效益的“双赢”。
那么对于一个CRM来说，搞清客户的具体定义就变得尤为重要，那么，上面对客户的定义如何？很显然，无法直接变为数据库中的字段。那么，我们需要细化客户。
通用来说，客户可以以个人和集团为单位，到了这里，似乎可以为CRM中的客户定义数据库中的字段了，但是，忽略了一点，集团是由个人组成的，那么，能不能把个人归入集团呢？或者说就是一个人的集团，那么程序的设计和编码工作似乎只需要考虑通用就可以了。好，那么，我们先这样做。
二、关系：
什么是关系？这个概念可能太大，那么我们集中注意力到客户这个关键字，这里所说的关系是客户关系，这样，我们将这里的关系狭义化。客户关系是什么？是企业和客户之间实现客户礼盒企业效益“双赢”的纽带。
那么回归到CRM来说，我们需要为这个关系定义，同样的问题出现了，无法直接将定义转化为数据库中的字段。那么，我们需要细化关系（以下关系特指客户关系）。
关系即纽带，那么是通过各种各样的方式来进行。首先，沟通首当其冲；次之，产品或者服务；最后，其他因素（例如客户的兴趣爱好，宗教信仰等）。
到了这里，似乎可以进入将定义数据库中字段的时候了，ok，先从沟通开始，沟通？怎么沟通，方式方法……等你罗列出来的时候发现这个问题太严重的，好，考虑通用性。选择一个沟通方式，然后给一个类似于详细描述的字段。
接下来，照猫画虎，似乎问题也不大，先这样。
三、管理：
什么是管理？这个概念也似乎太大，还是集中注意力到客户、关系这两个关键字，这里所说的是客户关系管理，同样，我们狭义化。客户关系管理是什么？客户关系管理(Customer relationship management，CRM)，是指企业为了赢取新顾客、保持老客户，以不断增进企业利润为目的，透过不断地沟通和了解客户,达到影响顾客购买行为的方法。
定义出来了，上面的问题同样出现了，而且问题的严重性更加显现了出来。还要继续说下去吗？我想没有这个必要了。
给开发人员这样的一些东西，步入开发？然后等着出产品？
其实到这里，大家似乎已经明白了，需求到底是什么，是目标，那么这个需求和开发所需要的需求并不是同一个需求，混淆了这个概念，那么需求是什么都不重要了。或者说这样的需求是需求意向，而开发人员需要的是开发文档。
这个转化的工作通常是需要介入需求分析师和系统架构师来协助完成的，而主体是什么，客户的需求，即需求意向，需要客户来参与，而且应该以客户为主。
需求的转化过程大致如下：需求意向-》需求框架-》需求大纲》需求文档
但是这里，问题继续产生，客户的需求，即需求意向从何而来。CRM概念如此之大，包罗万象。那么先撇开这些不说，要做个通用的CRM，可以不可以，可以。先这样做。
继续进入需求框架，这个时候问题继续产生，必须考虑管理这个问题了，毕竟核心是管理。那么CRM管理需要实现哪些功能？
分析吧，这个时候就要细化了，首先，什么样的管理？这个问题牵扯到了营销管理。
继续细化吧，找个方向总没有错，如果选定了一个方向，好，那么我们看客户的问题。
将客户视为有价值，那么才可以实现所谓的“双赢”。
客户价值：客户对公司价值的识别、评价（TP）
客户价值=当前的利润贡献+潜在的利润贡献+需求贡献
接下来，客户分类，提到分类，那么就应该有分类规则，上面说到的分类（个人或者集团）是以实际营销对象形态分类的，那么真正企业对这个分类的敏感程度有多大？估计一下，通用一下？都不行，那么，用理论支持一下，情境理论分析吧……
其实，客户关系管理对客户的分类重点是客户的忠诚度（这里只是列举一些）：
1、过客：可能发生消费的客户，具有机遇性。
2、消费者先锋：在可能发生消费的客户中最有可能成为客户的客户。
3、常客：经常发生消费的客户。
4、种子客户：带来客户的客户。
……………………………………………………
……………………………………………………
————————————————————————————————————————————————————
好了，到了这里，下面的事情似乎分析下去已经没有什么必要了。
这里其实忽略了一些问题，CRM的需求来源问题，这个CRM是谁在用？
回到我们的需求，需求的目的是什么，CRM的目的是什么？创造价值！那么是为谁在创造价值？
问题的关键就在这里了！
以前曾经在 千寻(qianxun.com)，2年了 和 激情、优雅 and coding 对需求的变动和不稳定提出了很多很多的问题，认为问题很严重，对于开发来说，和现在这个另一个需求问题来讲，就显得小巫见大巫了。
需求到底是什么？似乎到了这里更说不清除了。那么，至少我们应该清醒的认识到需求来源，为谁，为什么？
其实归结到最后，往往可以提炼出一个通用的模型出来来适应所有的这些，这就是营销管理上面所说的营销模型，再大一点，市场的定义。但是，这些其实已经是一些抽象了好几个层面的东西，实际运用性的问题也因不同的情境有所不同。
说了这么多，回到我们的老本行，Coding上面吧！
我们也在做同样的事情，抽象化，模型化，于是有了设计模式，也有了Framework。方便了大家的开发和减少了开发的代码量。但是，却在一定程度上限制了大家。这是一把双刃剑！
好了，到了这里，对于程序的抽象化和模型化，大家似乎都有共识，那就是功能封装多于逻辑分装。大部分封装都是基于功能的封装，类似于.net Framework或者Java，也有一些封装和逻辑打了擦边球，例如工作流，可是，当我们深入利用的时候，才发现这些逻辑分装还是对于功能的分装，为什么这么说，很简单，只是让大家不用写重复的判断代码，而判断，是逻辑还是功能？似乎说不清了。
再来看看现在已有的CRM，首先看看IBM的CRM实现，由于没有实际的参考，所以只是猜测，但是却看到IBM对CRM按照行业进行了细分，而且还提供一定程度的适应性修改。很大程度上，缩小的CRM的为谁这个问题，然后用CR适应性修改再次缩小为谁这个问题。
再来看看用友，按照行业做了细分，…………
————————————————————————————————————————————
其实需求是什么，这个问题到了这里还没有答案，因为我们没有需求的来源确定，那就是为谁，或者说谁的需求。
当我们都在说通用的时候，有谁细细坐下来想过通用就真的行得通？
当然，我们也可以先做一个通用的，然后根据客户的需求不停地添加判断，但是到了那个时候，这个通用其实已经成为一个绊脚石，限制了扩展。或者说留有余地，来个virtual，再来个override。
最后，还是告诉大家需求的定义吧！不卖关子了。
需求的定义为“系统必须符合的条件或具备的功能”。
- 用户为解决某个问题或达到某个目标而需具备的条件或能力。
- 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。
- 上述第一项或第二项中定义的条件和能力的文档表达。