需求(用户)与开发人员对业务的思考模式

在实际的软件开发过程中，我们常常可以看到这样的情形：一方面是开发人员指责需求人员不懂用户的真正的需求，讲解的需求和最后客户的要求想去甚远或指责需求只是客户的传声筒，拿到的需求不整理一下，就丢给开发人员开始做。另一方面是需求骂开发人员笨，对需求一点不理解，只懂机械的做。
这样的情况，常常导致系统不停的修改，bug不断。客户，需求，开发都筋疲力尽，然后就是项目延期，直到死亡。

       这样的情况，相信每个做企业系统的开发人员都遇到过，一提起这样的问题，大家只有摆脑袋，喃喃到“简直就是恶梦，太难了”
^_^（希望不要勾起你痛苦的回忆）

     其实出现这样的情况，大部分是应为需求人员和开发人员对问题的思考模式不同导致的。在业务语言和业务规则向计算机语言和系统模型转换之间有一个的过程。这个过程必须有一个衔接的人和模式来做这件事情。
     这个角色需要精通业务概念和系统实现方式。然后运用分析模式方式把业务概念转换为系统模型概念。需求人员理解业务总是自觉不自觉的把一些他们认为是常识的思维放进去，但是这部分只是不会出现在需求文档中。这就需要分析人员不断的和他需求聊天，不但的询问挖掘出来。然后写入概要设计和详细涉及文档中。
还有需求人员往往在写程序需要处理的逻辑的时候会不自觉的融入人类的思考模式，在其中加入一些智能判断，但是这部分逻辑往往用计算机实现比较困难。这就需要分析人员的洞察能力，找到客户的真正需求，然后转换方式来实现。

      例如：有这样一个需求是分析业务数据的。表中有27列，其中a，b，c，d，e，g，p，q，y，z为判断过程中所涉及到的数据项，各项之间的关系为：b列中的传输系统速决定z列中的最大时隙编号。如2。5G系统对应的最大时隙编号为16或8（保护）。10g系统对应的最大时隙编号为64或32（保护）。
      D列为与C列中站点相领的前向站点，e列为与c列中站点相领的后向站点。
      G列与p列或q列为－－对应关系，即唯一的一个端口对应当前传输系统的一个时隙。
      p列和q列在一行中不同时出现。即同时只有前项时隙或后项时隙，两者不同时存在。
      y列为版本号，1代表设计版，2代表工程版。当g列中相同的两个端口对应的z列不同的时隙时，以Y列为2的为准。

 
（一下为客户平时所用的人工分析方式）
分析过程：
1）首先根据系统名称中的2。5G可以判断出Z列的最大编号为16或8，对z列进行观察后得出最大编号为8。即存在8个时隙，编号分别为1~8.
2)  将c列为“杭环城北路”站点下所有z列的数据观察后可看出z列无5，6两个时隙，于是初步判断时隙在该站点为穿通。
3）c列为“杭环城北路”所对应的D列前向站点为“衢州网通”。在z列中查找所有c列为“衢州网通”所对应的时隙，发现5，6两个时隙编号，且p，q两列中仅q列有数据，说明该时隙为后向时隙。可得出5，6两个时隙的起始站点为“衢州网通”。因该时隙对应的Y列均有1，2两个数值，根据“各项间关系”，仅取Y列数值为2的数据为有效数据。
4）c列为“杭环城北路”所对应的e列后向站点为“宁波网通”。在z列中查找所有c列为“宁波网通”所对应的时隙，发现5，6两个时隙编号。且p，q两列仅p列有数据，说明该时隙为前向时隙，可得出5，6两个时隙的终止站点为“宁波网通”。因该时隙对应的Y列均有1，2两个数据，根据各项间干系,取Y列为2的数据为有效数据。
综合判断1~4不的判断过程，可以得出结论：编号为5，6的两个时隙以“衢州网通”为起点，途径“杭环城北路”以“宁波网通”为终点


可以看到这个分析过程很不利于计算机话
（一下为我的分析方式）



------推荐的方式



-------其他


(未完待续........)