管文档｜需求分析的“六韬三略”

一个段子：

外星人产品经理来地球，考察一周后，给上司写了一份需求分析报告：

主宰地球的是汽车。它们喝汽油，靠四个轮子滚动前进，嗓门极大，双眼在夜里能射出强光……

有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”

这个笑话可以看出，分析人员缺乏知识的专业性，必然会造成需求分析的误解和失败！

也暴漏了需求分析这个最日常的小事，但其实很难！

本文就要治一治这个“难”！

1

重点监控需求分析办法

由于产品的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，需求分析的重要性是不言而喻的。

第二个段子：

情人节要到了，你女朋友想让你送项链，但是她不说。

等你送了一束花以后，她生气了，这个时候你为了哄她开心，要带她去吃大餐。

她说要去吃火锅，结果半路上看到烧烤，拉着你非要过去吃。

你女朋友想要口红不跟你说，迎合了用户知道自己要什么但是不说这个特点,女朋友说去吃火锅结果去吃了烧烤，迎合了用户自己也不知道要什么这个特性。

而导致需求分云里雾里的原因，基本是这些情况：

1、用户说不清楚需求

有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。

例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设时，客户方的办公人员大多不清楚计算机网络有什么用，更缺乏IT系统建设方面的专家和知识。

此时，用户就会要求产品分析人员替他们设想需求产品工程的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。

2、需求自身经常变动

根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。

事实上，历史上没有一个产品的需求改动少于三次的！

所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将产品的核心建筑在稳定的需求上，同时留出变更空间。

咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。

3、分析人员或客户理解有误

需求分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。

如果分析人员理解错了，可能会导致以后的开发工作劳而无功。

这时，就必须根据实际的项目需求调研计划，提醒承建方加强业务了解程度和注重沟通技巧。

2

需求分析【三步法】

需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。

1、“访谈式Visitation”阶段

这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。

建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。

实现手段：访谈、调查表格

输出成果：调查报告、业务流程报告

2、“诱导式Inducement”阶段

这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面。

同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。

用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。

实现手段：拜访（诱导）、原型演示

输出成果：调研分析报告、原型反馈报告、业务流程报告

3、“确认式Afirm”阶段

这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。

用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。

实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统

输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）

整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。

当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。

3

需求分析工具

我们根据用户需求，通过反复讨论、分析，最终明确一个唯一性的用户需求，这个结果其实就是我们的需求分析报告。一般我们采用Word、PowerPoint、Visio、ProntPage、Excel等Office工具，同时可能采用一些开发工具，如VC或BC等，同样也会使用一些图形工具，如Potoshop、调色板等画图工具。

使用各种工具表达需求分析，其具体表达手段可以分为：

（1）效果图描述。主要是用户UI界面的描述反映用户需求功能；

（2）逻辑图描述。根据用户需求功能，使用抽象化理论，以及需求分析理论，对用户需求功能进行全面的分析，建立功能性逻辑关系图，流程逻辑关系图等；

（3）关系图表描述。主要是对信息关系、数据库表格、接口函数等描述；

（4）工程数学描述。分析用户需求，分析用户需求信息，运用工程数学进行算法推导，进行合理化需求分析推导；

（5）甘地图描述。主要是软件项目工作安排，开发周期预估；

（6）其它方法描述。保证完整性合理性的有效描述。

4

需求分析【六评估】

需求分析评估是为了检查我们进行需求分析工作，保证需求分析工作正确性、完整性、有效性、合理性、可确认性、可实施性，完全保证用户所需求的功能。

1、组织结构与责任管理

我们对组织结构与责任管理的评估主要有：参与人员任务和责任界面的明确；安排计划按时完成状况；相互间的协调能力状况。

2、满足用户需求的功能

我们进行需求分析的目的是完整、准确地描述用户的需求，跟踪用户需求的变化，将用户的需求准确地反映到系统的分析和设计中，并使系统的分析、设计和用户的需求保持一致。

需求分析的特点是需求的完整性、一致性和可追溯性。

完整性：是准确、全面的描述用户的需求。

一致性：是通过分析整理，剔除用户需求矛盾的方面，规范用户需求。

可追溯性：有两个方面的含义，整理和规范的需求，其一，需要不断的和用户进一步交流，保持和用户最新的需求一致。其二，和系统分析（设计）保持一致。

因此在需求分析之前我们必须建立需求分析技术层面的基本框架，从技术上保证需求分析的要求，在此基础上我们进行的需求分析才能满足项目对需求分析的要求。

3、保证可实施性

我们必须以用户需求为依据，以求实的态度详细的、准确的、完整的编写需求分析，避免空想世界，空中楼阁的想法；避免无逻辑性、无核心的描述；避免无量化思维，无实际空间概念。

4、需求分析评价指标

主要有这么几个指标：功能性、完整性、正确性、逻辑性、表现性、合理性，可实施性等。

5、工作周期

评价人员投入，以及费用支出的合理性问题。正确制定工作周期，保证软件项目的顺利完成。

6、需求不确定更改与可确认保证

可确认需求功能是实现用户需求的基本保证，如果不可确认的、不确定更改存在，将会阻碍产品实现，或者软件设计存在着不完整性缺陷，或者存在着不可实施性问题，我们必须区分是功能性障碍问题，还是未来性问题。

如果不能够明确是未来性问题，则必须调整功能需求，化解不确定更改的问题。因此，判断不确定性更改是一个非常重要的问题。