-需求分析方法论

需求分析方法论
原则上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以
不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距
和不足。
为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同
化、贯彻的方法和手段。
其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％
是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而
项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用应用管理软件。
作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT
中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能
界定、实施上有发言权。

一、如何进行需求分析
需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。
一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域
对应于一个软件子系统。
S={D1，D2，D3，…Dn}
问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。
Di={P1，P2，P3，…Pm}
问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。
Pj={F1，F2，F3，…Fk}
需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术人员都合适。在写需求说
明书时应该注意两个问题：
1、最好为每个需求注释“为什么”，这样可让双方（IT中心、需求方）了解需求的本质，以便选用最合
适的技术来实现此需求。
2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。

二、重点监控需求分析
由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而
喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。
1、用户说不清楚需求
有些用户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进
行应用系统以及网络建设时，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就
会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜
在的风险。
2、需求自身经常变动
根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和
时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以
必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定
的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变
更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求
分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。
3、IT中心分析人员或用户理解有误
系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能
有不同的理解。如果分析人员理解错了，可能会导致以后的选型和实施工作劳而无功。记得一则笑话，有
个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是汽车。它们喝汽油，靠四个
轮子滚动前进，嗓门极大，双眼在夜里能射出强光……有趣的是，车里住着一种叫作‘人’的寄生虫，这
些寄生虫完全控制了车。”
所以分析人员知识的专一性也会造成需求分析的误解和失败。这时，IT中心内部专家就必须根据实际
的项目需求调研计划，提醒IT中心人员加强业务了解程度和注重沟通技巧。

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