项目建设的需求分析阶段的IT监理工作机制和方法论
1、需求阶段监理的定位
原则上尊重承建方的项目管理和项目分析能力，在具体的任务开展上，以不深入、不干扰承建方的自主权为主，但是如果在项目合作过程中发现中软项目管理以及项目分析能力在本项目的进行上存在很大的差距和不足，为了保证项目的成功顺利开展监理内部必须加强项目管理能力和项目分析能力，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。
2、需求分析的进展方式及监理角色的把握
需求分析是一个项目的开端，也是项目建设的基石，在以往的建设失败的项目中80%的是由于需求分析的不明确而造成的，因此一个项目的成功的关键因素之一，就是对需求分析的把握程度上，项目的整体风险具体表现方式在需求分析不明确、业务流程不合理上，用户不习惯或者不愿意去用承建方的软件，或者很难去用，造成了项目失败。因此作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研。同时监理方也应深入具体的需求调研中去，只有这样才能切切实实的把握用户的需求和方向，才能在将来的功能界定、开发范围上有发言权。
2.1、为什么咨询监理方要对需求分析进行重点监控
由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，所以在整个软件的开发周期中，需求分析的重要性是不言而喻，需求分析难做的的确确难做，这是基本是由于以下几种原因造成的：
（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。
2.1.1客户说不清楚需求
有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设，客户方的领导和办公人员大多不清楚计算机网络有什么用；缺乏系统的IT建设方面的专家和知识。这时间就会要求软件系统分析人员替他们设想需求。工程的需求存在一定的主观性，为项目建设埋下潜在的风险。
2.2.2需求自身经常变动
根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的整合提高，会在不同的阶段和时期对项目的需求提出新的要求和需求变更，其实在历史上没有一个软件的需求改动少于三次的，所以必须接受“需求会变动”这个事实，所以在进行需求分析时就要防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。
2.1.3 分析人员或客户理解有误
软件系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作劳而无功，记得一则笑话“有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：”主宰地球的是汽车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。‘“所以分析人员的知识的专一性也会造成需求分析的误解和失败。这时间咨询监理公司就必须根据实际的项目需求调研计划，提醒承建方加强业务了解程度和注重沟通技巧。
2.2咨询监理公司如何进行需求分析
需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题，
一个应用软件系统（记为 S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。
S = { D1，D2，D3，… Dn }
问题域Di 由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。
Di = { P1，P2，P3，… Pm }
问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。
Pj = { F1，F2，F3，… Fk }
按图4.1结构写成的需求说明书，对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时还应该注意两个问题：
（1）最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。
（2）需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。
2.3咨询监理公司需求分析方法论
根据以往的工程经验基本认为需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。
首先：“访谈式”，这一阶段为和具体用户方的领导层、业务层人员的访谈式沟通上，主要目的基本是从宏观上把我用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息。建立起良好的沟通渠道和方式，针对具体的职能部门以及各委办局最好能指定本次项目的接口人。
实现手段：访谈、调查表格
输出成果：调查报告、业务流程报告
第三阶段：“确认式”，这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰的向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表；操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受审查过的报告、文档签字确认。
实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统
输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）
整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户、承建方来讲，都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式后，需求分析的工作会一直进行下去，在后期的需求改进中，基本是处于以后两个阶段。