关于需求分析

   实习阶段也算是快要完成了， 在这里没有做到很多需求分析上面的锻炼，可是学到了不少关于实践真正需要的东西。

   在学校里面学的东西都太流于表面了，并为去想这种步骤是否必要， 这种步骤可以为项目带来什么样的好处，这样的好处和我要付出的代价是否超值。这种观念在《走出软件作坊》里面学到过，不过现在更加真实的见识到。项目中成本的控制是很大的关键。 完成一个项目，达到更高的利益，就是有效的工作，降低成本，减少风险，预知扩展点。

  电信的幼儿园项目，刚开始并没有参与需求的分析， 只是大致完成大概的要求，主要负责了后期的维护，一些小功能模块的扩展。 在和客户打交道的时候，感觉到业务领域，客户是高手，在需求阶段要真正的去了解用户需要的是什么。了解用户所要求的重点在哪里。 可是有时客户也不知道自己想要的是什么，所以要去引导用户。引导的方式，理解的方式，沟通的方式，是重中之重。

   项目用来做什么的，通过什么样的方式，要达到什么样的效益，项目可能出在的变动在哪里。

  

   需求分析就是将客户提出的一大堆要求，归纳整理出来，慢慢成形，再慢慢变形，进行技术的架构分析。需求分析的成果，变形到架构分析，这个成果某种程度上是业务领域到技术领域的过渡。需要什么样的形式。这是个重点

 

 

   一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。
S={D1，D2，D3，…Dn}
问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。
Di={P1，P2，P3，…Pm}
问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。
Pj={F1，F2，F3，…Fk}

  

  明确的，清晰的归纳思维方式。保留着。。

 

需求分析方法论　　
根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。

第一阶段：“访谈式”（Visitation）
这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。
实现手段：访谈、调查表格
输出成果：调查报告、业务流程报告
第二阶段：“诱导式”（Inducement）
这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。
实现手段：拜访（诱导）、原型演示
输出成果：调研分析报告、原型反馈报告、业务流程报告
第三阶段：“确认式”（Afirm）
这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。
实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统
输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）

 

整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。

 

看起来有点繁琐，麻烦，重点也是在 需求的明确。如果是简单普遍都做过的东西，并未存在个性化定制的东西。这么繁琐无必要。