作为从事互联网工作的一员，不防会遇到一些客户过来咨询项目的事。在众多客户当中，一些客户说，我有这么个创意的想法，开发需要多少钱？等等诸如此类的问题。飞创数据的小编认为拥有创意的想法，还需要明确的商业模式，竞争环境分析，规划和验证等。

可以说一个项目的完成需要投入很多的心思，其过程其实并非容易，有时甚至会让人感到沮丧万分。但是，这只是万里长征的第一步。以下来说说需求分析是怎么做的。如何确认项目的功能需求，从而确定开发周期才能确定项目的费用等。

需求分析是怎样做的？

需求分析是软件开发的一个重要过程。 一般，把需求类型分成三个类型：

1、业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。

2、用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。

3、功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

首先，业务需求和用户需求是软件需求分析的基础，也是软件开发的前提。系统分析员通过对业务需求和用户需求的分解，将其转换成可以形式化描述的软件功能需求。飞创数据的小编认为开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发过程中不断地与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。

然而，飞创数据的小编觉得客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。软件开发商经常陷入客户自己的矛盾之中。 飞创数据的小编认为 客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。

最后，飞创数据的小编认为良好的需求分析是软件成功的基础。以上是飞创数据的小编对需求分析工作实践的一次总结以及综合性的思考，是对需求分析本身所做的一次分析。在此基础上，飞创数据的小编建议软件开发商还可以提出逆向沟通的设想，即项目经理主动进行沟通，提出引导性建议。当软件融合了客户和软件开发商双方的智慧，其项目的实施与质量将会进一步得以提升。

甲方的需求观

甲方与乙方开发人员交流之间的交流是很有必要的。交流的效果，对项目交付成功有直接的帮助。下面建议的20条方法，甲方的需求人员和乙方的开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

1、分析人员要使用符合客户语言习惯的表达

需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语(例如：采价、印花商品等采购术语)教给分析人员，而客户不一定要懂得计算机行业的术语。

2、分析人员要了解客户的业务及目标

只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s

3、分析人员必须编写软件需求报告

分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、要求得到需求工作结果的解释说明

分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值;虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5、开发人员要尊重客户的意见

如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

6、开发人员要对需求及产品实施提出建议和解决方案

通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效;在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

7、描述产品使用特性

客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

8、允许重用已有的软件组件

需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

9、要求对变更的代价提供真实可靠的评估

有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

10、获得满足客户功能和质量要求的系统

每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

11、给分析人员讲解您的业务

分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标;不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

12、抽出时间清楚地说明并完善需求

客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

13、准确而详细地说明需求

编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

14、及时作出决定

分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

15、尊重开发人员的需求可行性及成本评估

所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

未完待续

补充的5条建议和最后“需求确定”的注意事项

大牛回顾了第二课的内容：“在需求分析中用到三种类型的模型，分别是数学模型、描述模型和图形模型。需求分析中诸如数据分析、统计、计算一般用数学模型建模，图形模型较多用于业务流程建模，描述模型一般用于功能列表、输入列表、输出列表、事件等列表的建模”。

小白：“在需求分析中，有没有标准化的、成熟的模型可以使用呢？”。

大牛：“当然有，不过软件建模不是从来就有的，而是随着软件工程的发展不断成熟和完善起来。在需求分析阶段，系统分析员经常使用逻辑模型来建立需求模型”。

小白：“什么是逻辑模型？”。

大牛：“逻辑模型只是定义了系统需求，并没有局限于某一具体技术，逻辑模型的具体细节后面会讲到，本课主要是对需求分析阶段用到的逻辑模型做个简单介绍”。

大牛在黑板上写下了本节课的学习内容。

● 需求分析阶段常用的逻辑模型

大牛：“有很多种类的逻辑模型用来定义系统需求，这是一些经常使用的模型”。

大牛边说边在黑板上写下了常用的逻辑模型。

■ 事件列表

■ 数据字典

■ 数据流图（DFD）

■ 实体关系图（ERD）

■ 流程图

■ 类图

■ 用例图

■ 时序图

■ 协作图

■ 状态图

小白：“太多模型了，需求分析中都要用到吗？能不能简单介绍一下每个逻辑模型的用途？”

大牛：“在需求分析中，上面所列的模型不一定都要用到，可以根据项目规模和项目要求选取合适的逻辑模型来建模，一般建模都是从事件列表开始建模的”。

小白：“事件列表是不是记录系统发生的事件呢？”

大牛：“对，所有系统的开发方法都是以事件概念开始建模的，事件发生在某一特定的事件和地点，可描述并且系统应该记录下来”。

小白：“记录系统发生的事件对需求分析有什么作用呢？”。

大牛：“例如，我们对Windows操作系统都很熟悉，Windows操作系统本身就是由事件驱动的。你点击一个程序图标、滑动鼠标、按下鼠标左键等操作都是在触发一个事件，操作系统接收到事件，并对事件进行相应的处理”。

大牛：“Windows操作系统的所有处理过程都是由事件来驱动或触发的，当你定义系统需求时把所有事件罗列出来并加以分析是非常重要的”。

小白：“哦，明白了，所有的系统需求分析都是先从事件分析开始的，事件模型就是记录事件分析的结果”。

小白：“数据字典呢？这个概念有点抽象”。

大牛：“数据字典是用来描述模型数据的，是对模型涉及到数据进行定义和描述。举个例子，电话在线订餐系统的事件模型中可能会记录用户拨进电话这个事件，这个事件需要记录拨进的电话号码、区号、时间等数据项，你可能需要描述这些数据项的长度、数据类型、用途或预先定义的默认值，给系统设计师提供参考数据，这些描述数据称为数据字典”。

小白：“哦，数据字典就是模型中用到的一些数据，需要另外的数据来定义和描述”。

大牛：“不错，理解很快。我们再来看数据流图”。

随即大牛将一张图片投影到屏幕上。

大牛：“你看这张图，这就是数据流图，数据流图描述了数据从输入到输出的整个过程，数据流图以数据为中心，展示数据的流向和数据的处理节点，通过数据流图可以清晰地看出从接听电话开始到取餐结束，完整订餐信息流的处理及变换”。

小白：“真是一张图胜过千言万语啊，电话的订餐过程一目了然。不过，怎么判定数据流？怎么区分数据流和数据的处理过程呢？”

大牛笑了笑：“别急，现在只是让你了解一下需求建模的常用模型，后面的课会详细讲述如何建模”。

小白：“哦，好”。

大牛：“我们再来看实体关系图”

随后大牛将一张图片投影到屏幕上。

大牛：“你看这张图，这就是实体关系图。实体关系图反映了系统实体及实体间的关系。例如：在电话订餐系统中，涉及到的实体有客户、接电话人员（客服）、备餐人员、订餐单据。图给出了这些实体间的关系，图中N:N的意思是一个客服可以对应多个客户，一个客户也可以对应多个客服”。

小白：“这么说，实体就是系统涉及到人和事”。

大牛：“基本可以这么说，实体一般都有存储数据的需求，如果事物没有存储数据的需求，就不能当作实体看待”。

小白：“明白….”。

大牛：“接着是流程图，流程图很简单，基本都见过，这里就不说了，再看下面的几个模型”。

大牛：“类图、用例图、时序图、协作图、状态图都是UML建模语言提供的模型，类图用于在需求分析中为识别的实体建模；用例图用于系统功能建模；时序图用于实体间交互行为发生的时间顺序建模；协作图也是描述实体间的交互行为，与时序图不同的是，协作图更强调实体之间的相互关系及协作而忽略时间的约束；状态图用于描述实体状态的变化及事件发生时实体的变化情况”。

小白苦笑了一下：“脑子有点打浆糊了，刚才说的类图、用例图、时序图、协作图、状态图都没太听清楚”。

大牛：“现在不清楚没关系，后面我们都要详细讲述”。

小白：“哦，那太好了”。

大牛：“这节课主要是讲述了需求建模常用的模型，对常用的模型先大概了解一下，后面会详细讲述。下节课的内容，我们会探讨事件的概念，因为任何系统需求分析都是从事件开始的”。

大数据在很多的 行业和企业得到了应用  对大数据的研究和分析也得到了很多的学者的青睐  在未来的商务活动中  大数据会发挥自身独特的优势  带给我们更多的方便和便捷  

预测：精确的需求预测。需求预测是整个供应链的源头，整个市场需求波动的晴雨表，销售预测的灵敏与否直接关系到库存策略，生产安排以及对终端客户的订单交付率，产品的缺货和脱销将给企业带来巨大损失。企业需要通过有效的定性和定量的预测分析手段和模型并结合历史需求数据和安全库存水平综合指定精确的需求预测计划。

资源获取：敏捷、透明的寻源与采购。为新产品、优化成本而寻找新的合格供应商满足生产需求；同时，通过供应商绩效评估和合同管理，使采购过程规范化、标准化、可视化、成本最优化。

协同效率：建立良好的供应商关系，实现双方信息的交互。良好的供应商关系是消灭供应商与制造商间不信任成本的关键。双方库存与需求信息交互、VMI运作机制的建立，将降低由于缺货造成的生产损失。采购订单与生产订单通过各种渠道快速、准确的反应能力在当前集团化、全球化，多组织运作的环境下尤为重要。订单处理的速度在某种程度上能反应出供应链的运作效率。

供应链计划，与物料、订单同步的生产计划与排程。有效的供应链计划系统集成企业所有的计划和决策业务，包括需求预测、库存计划、资源配置、设备管理、渠道优化、生产作业计划、物料需求与采购计划等。企业根据多工厂的产能情况编制生产计划与排程，保证生产过程的有序与匀速，其中包括物料供应的分解和生产订单的拆分。在这个环节中企业需要综合平衡订单、产能、调度、库存和成本间的关系，需要大量的数学模型、优化和模拟技术为复杂的生产和供应问题找到优化解决方案。

库存优化。成熟的补货和库存协调机制消除过量的库存，降低库存持有成本。通过从需求变动、安全库存水平、采购提前期、最大库存设置、采购订购批量、采购变动等方面综合考虑，监理优化的库存结构和库存水平设置。

物流效率。建立高效的运输与配送中心管理，通过大数据分析合理的运输管理、道路运力资源管理，构建全业务流程的可视化、合理的配送中心间的货物调拨以及正确选择和管理外包承运商和自有车队，提高企业对业务风险的管控力，改善企业运作和客户服务品质。

网络设计与优化。对于投资和扩建，企业从供应链角度分析的成本、产能和变化更直观、更丰富也更合理。企业需要应用足够多的情景分析和动态的成本优化模型，帮助企业完成配送整合和生产线设定决策。

制造业各行业管理特点突出，在供应链管理上呈现行业管理差异。如汽车行业重点关注准时上线和分销环节、食品饮料行业关注的重点在冷链及配送环节、服装行业的供应链管理重难点在消灭链条上高库存等等。

风险预警，在大数据与预测性分析中，有大量的供应链机会。例如，问题预测可以在问题出现之前就准备好解决方案，避免措手不及造成经营灾难。还可以应用到质量风险控制，如上海宝钢，其生产线全部实现流水化作业，生产线上的传感器可获得大量实时数据，利用这些可以有效控制产品质量。通过采集生产线上的大量数据，来判断设备运营状况健康状况,对设备发生故障的时间和概率进行预测。这样企业可由此提前安排设备维护，保证生产安全。

电商要运用大数据，将数据分析转化为钢铁电商平台，必须做到以下三点：培养一种将分析融入方方面面的企业文化。支持所有员工根据大数据和分析做出决策，而不是依靠直觉和过往的经验。主动维护隐私和安全性以及开展监管活动。确保所分析数据的安全性和准确性。投资于大数据和分析平台，这种平台通过调整，可以执行各种用于处理所有数据和分析类型的任务，无论其形式和功能如何。

随着互联网时代的发展。大数据化时代的到来给很多企业带来本质的改变。在制造系统和商业环境变得日益复杂的今天，利用大数据去解决某些问题和积累知识或许是更加高效、便捷的方式。“大数据的目的并不是追求数据量大，而是通过系统式的数据收集和分析手段，实现价值的最大化。所以推动智能制造的并不是大数据本身，而是大数据的分析技术，”数据本身不会说话，也不会直接创造价值，真正为企业带来价值的是数据经过实时分析后及时地流向决策链的各个环节，或是成为面向客户创造价值服务的内容和依据。大数据技术的快速发展，也将用户的行为追踪变得更为便利。

大大神平台采用大数据庞大的用户基数和强大的数据处理能力，将需求方、供应方、资源方通过大数据技术全线打通。使得用户发布的软件需求平台可通过关键词利用大数据智能匹配出产品经理，让符合用户的产品经理从量级和精准度方面脱颖而出。 通过大数据分析精准了解需求者所想要做的软件一个领域和特点，并以此为依据，通过平台进行资源的精准匹配，并最终通过大数据分析精准细致的给出用户满意的效果。

智能匹配：

每一组数据和一个社会现象之间，都存在千线万缕的联系。比如，如果你所写的需求中多次出现商城类型的文字，大数据就会抓取多次出现的关键词，并通过各种数据模型的设计，去分析用户需求的所需要的是那一方面的产品经理。

抓住这一切入点，以“智能大数据”为核心驱动力，平台建立产品经理的专业领域标签、个人简介、擅长行业记录数据库，通过这些数据库预测需求者的所需。大数据时代让我们更容易获取对用户的洞察，当所有的行为和信息都被记下来以后，可能你所需要的产品经理可以被推荐和推荐平台上面的产品。大数据应用在个性化营销方面也可以让我们生活得更轻松。解决电商营销中“如何将推广信息与目标消费匹配”的行业难题。

大数据不仅可以实现需求和资源最简便的对接，实现丰富的智慧流通方式，还可以用更少的精力和成本，获得更优的闲置资产盘活和消费投资效果。

　　BI(BusinessIntelligence)即商业智能，越来越多的智能软件供应商推出可视化数据分析工具，应对企业业务人员的大数据分析需求。然而如果你觉得不是数据分析专业、没有挖掘算法基础就无法使用BI工具?NO，自助式分析工具已经让数据产品链条变得大众化。为了更好地帮助读者选择分析工具，重庆IT培训的老师将为大家介绍数说立方、数据观、BDP等11款BI-商业智能产品，排名不分先后!

　　1、数说立方

　　数说立方是数说故事新推出的一款面向数据分析师的在线商业智能产品。最重要的特点是配备百亿级社交数据库，同时支持全网公开数据实时抓取，从数据源端解决分析师难点;另外数说立方搭载了分布式搜索、语义分析、数据可视化三大引擎系统的海量计算平台，实现数据处理“探索式分析”和“秒级响应”的两个核心功能。同时数说立方是数说故事三大主打产品之一，并与其他两大产品数说聚合和数说雷达实现从数据源、数据分析、到数据展示完整的数据解决方案。

　　优点：

　　即便是个人免费版，体验和功能仍然非常好;

　　与自家产品“数说聚合”的无缝接入，支持定向抓取微信、微博等数据;

　　功能完善，集数据处理、特征工程、建模、文本挖掘为一体的机器学习平台;

　　可视化视图展现、友好的客户感知页面;

　　支持SAAS，私有化部署，有权限管理;

　　缺点：

　　产品新上市，操作指导页不太完善;

　　体验过程中有一些小bug;

　　2、数加平台

　　数加是阿里云发布的一站式大数据平台，可以提供数据采集、结构化、加工到展示分析整套的一站式数据服务。 可采集不同系统及物理存储的源头数据，在分布式计算平台上进行数据的深度整合、计算、挖掘，将计算的结果通过可视化的工具进行个性化的数据分析和展现，也可直观的展示分析现有云上业务系统的数据库数据。

　　优点：

　　有完整的产品规划，功能完善;

　　图形展示和客户感知良好;

　　提供SQL查询;

　　缺点：

　　需要捆绑阿里云才能使用，一般用户还不能真正使用起来;

　　部分体验功能一般，有一定的学习成本;

　　3、Tableau

　　Tableau是目前市面上较为成功的BI工具。产品既有针对性，又有普适性。拖放式界面，操作简单。数据兼容性强，适用于多种数据文件与数据库，同时也兼容多平台，windows、mac、Online均可使用。而且重要的一点是免费为用户安排现场培训或按需求进行在线培训。

　　优点：

　　处于行业领导者地位，功能完善;

　　有较好的图形展现与客户感知;

　　新产品开始支持云端展现，但是需要客户端支持;

　　缺点：

　　相比于商业智能BI，更像一个基于数据查询的数据展示工具;

　　处理不规范数据、转化复杂模型比较难;

　　无法处理大量数据;

　　国内网络连接Online版速度较慢;

　　4、Qlik

　　QlikView只需轻轻单击几下，就可以对所有数据源进行合并、搜索、可视化和分析，可在不影响性能的前提下连接到多个数据源;其次视图种类丰富，界面简洁，互动性强，总体来说是一款简单易用的BI产品。Qlik用户可通过各类可视化效果，将Qlik扩展到任何应用程序中。另外用户也可以通过使用标准的和最新的网络API，可将可视化效果数据嵌入网站或应用程序。

　　优点：

　　产品功能完善，图形展现和客户感知良好;

　　支持SAAS，有权限管理功能;

　　缺点：

　　有一定的学习成本;

　　报表规范性要求很高;

　　数据抓取功能都非常弱，需要有非常好的数据仓库作为基础;

　　5、Spotfire

　　Spotfire服务对象是一线工作人员和日常决策人员，其交互界面形象易懂，无需写脚本语言和编写程序就可以对数据进行添加、分离操作。内置搜索引擎，可以随意查找任意信息。支持R、S+等统计、挖掘功能;有丰富、开源的R模型。标记有自身特色，提供了过滤、钻取等功能，多个标记同时还可以实现图形化的集合运算。

　　优点：

　　交互界面形象易懂，即使是普通的业务人员也能轻而易举地进行复杂的数据分析;

　　不一定要建数据仓库，还可以直接从多个异构数据源提取数据进行分析;

　　支持SAAS，有权限管理功能;

　　缺点：

　　SAAS版只支持30M，由于是国外服务器所以上传很慢;

　　不适合中国式的固定报表;

　　进军中国市场较晚，国内案例较少;

　　工具的适应性范围广，但是难易跨度大;

　　6、神策分析

　　神策分析的产品有完整的使用文档，每个模块都有详细的使用说明以及示例，降低了用户的学习成本。而且支持私有部署、任意维度的交叉分析，并帮助客户搭建专属的数据仓库。目前提供事件分析、漏斗分析、留存分析、数据管理等功能，未来预计会增加用户分群、用户人群分析、推送和异常维度组合挖掘等，工具需要付费使用。

　　优点：

　　专注于用户行为数据分析，不追求做大而追求做全;

　　有详细的产品使用文档以及案例;

　　提供SQL查询;

　　缺点：

　　更多的是demo示例，不能开箱即用;

　　纯dashboard展示，并不能对单独一块数据作自定义分析;

　　7、BDP

　　BDP个人版使用免费，只需导入数据，设定分析维度，即可实时得到图表分析结果。产品示例和视频教学很细致，交互页面很友好。每次数据更新，对应的图表也会自动更新，可以免去一些重复分析、制作图表的数据工作。另外，分享环节也很贴心，数据仪表盘可以一键导出，也可直接生成链接分享给他人或分享到微信、微博等社交平台。

　　优点：

　　产品支持移动端;手机同步呈现最新数据

　　用户可以免费使用工具，还有免费公开的数据源;

　　操作体验流畅，界面友好，功能全，总体来说是一款不错的产品;

　　即便是个人免费版，体验和功能仍然非常好;

　　数据可以同步更新，免去了重复劳动的工作;

　　缺点：

　　官网的介绍比较简单;

　　8、永洪BI

　　永洪BI是一款可在前端进行多维分析和报表展现的BI软件。支持拖拽操作，数据源格式多样，提供不同级别的查询支持，支持跨库跨源连接。另外永洪提供了一款数据存储、数据处理的软件——MPP数据集市，可与BI打通，使得数据查询，钻取和展示的速度大幅度提高。不过其产品用户体验一般，拖拽过于自由，导致仪表盘布局不好控制;主题样式虽多但是给人感觉样式还是很传统。

　　优点：

　　商业流程完善，给人专业的感觉;

　　产品定制化的版本效果不错;

　　支持的数据接入较多;

　　缺点：

　　SAAS版体验很差，有一定的学习成本;

　　UI的视觉效果一般，整体可视化效果不够现代化;

　　9、数据观

　　数据观的功能设计理念是极简、无门槛，所以它最大的特点就是简单。数据观数据来自云端，如：百度 网盘、微盘、salesforce等。数据上传后，马上有推荐图表，引导明确。另外产品的使用没有技术门槛，无需专业IT知识，同时适用于非专业分析师出身的业务人员，可以快速将数据转化成直观的图表，适合一开始接触数据分析工具的非专业数据从业人员。

　　优点：

　　注册只需填写邮箱，且支持明道账号登陆;

　　使用引导明确，支持salesforce、百度云数据导入;

　　分析结果支持链接分享，大大降低用户的沟通成本;

　　缺点：

　　不支持超过20MB的数据上传;

　　数据导入后，数据分析体验方面存在bug;

　　产品的使用以点击为主，不支持拖拽操作;

　　10、FineBI

　　FineBI分为数据处理、可视分析和分享公用三大功能模块。支持多种数据源，图表风格清爽美观，可选择任意维度分析。分析页面由控件和组件组成，控件和组件的数量是可以添加至任意多个，但是布局的交互比较僵硬，且使用逻辑有点乱，引导不明确。需要安装本地客户端才能使用。

　　优点：

　　有较为详细的行业案例与技术方案;

　　产品演示和资源中心也较为清晰

　　缺点：

　　需要使用客户端，增加了使用的不便利性

　　只有仪表盘展示，BI报表需要另一款产品;

　　无法处理大量的数据;

　　11、魔镜

　　魔镜支持自动拖拽建模，同时可视化效果库十分酷炫。用户可以邀请团队成员到自己的项目，合作进行探索分析，并且按照需求有效控制访问数据的成员权限。产品模块规划完整，有基础企业版到hadoop等5种选择为，而且可以支持定制化服务。但是可能是云平台版的缘故，使用过程中出现不少BUG，企业版的体验可能会相对好一点。

　　优点：

　　产品模块的规划比较健全，其中包括数据源导入、数据分析、仪表盘、数据挖掘和数据工厂;

　　官网的设计不错，模板选择性大，颜值控可能会喜欢;

　　工具使用指导清晰，使用篇和方法篇等比较详细;

　　缺点：

　　产品存在较多的BUG，UI和功能相对其他产品来说较简陋;

　　部分产品模块并不能切实用于数据分析;

　　选择一款适用的BI产品，能够大大简化数据分析的繁杂工作，提高分析效率与质量。当然，以上每个工具各有优点，工具地址都给大家了，接下来就是轮到你动手的时候了，找一个自己喜欢的工具，开始吧!

奶爸有10多年面向企业级的软件需求管理经验，作为需求人员最核心的三个技能就是需求收集、需求分析和需求说明书编制，今天先谈一谈如何完成需求收集工作。

1、需求来源

需求收集的目的是获取用户需求，收集的结果应该详实、全面，可以保证需求分析工作顺利开展。

用户需求按照反馈渠道可分为：用户代表反馈需求、流程与信息化部反馈需求、运维人员反馈需求（包含用户方运维人员设和我方工程人员）。针对后两类需求，需求人员获取需求后需进一步与反馈人沟通明确需求的用户代表。

反馈人一般通过电话、邮件、项目例会、运维日报等方式反馈需求，若反馈的需求无法支撑下一步需求分析工作，需求人员应与需求反馈人及用户代表进一步收集需求。

进一步收集需求时，需求人员可参考采用如下需求收集方法：用户访谈、调研问卷、文档考古、现场观摩。以上需求收集方法可单独使用也可混合使用，需求人员根据实际情况选择使用。

2、需求访谈

需求访谈：需求人员在进行需求访谈时应遵循如下方法：

（1）需求访谈是最常用的需求收集方法，需求人员在访谈前需制定访谈计划，明确访谈人、访谈时间、访谈主题，并根据不同访谈人提前制定访谈提纲。访谈计划和访谈大纲应提前发用户，以便客户提前准备。

（2）不同层级用户访谈目标不同，高层领导主要探讨目标和范围、中层领导主要探讨流程和管控要点、操作人员主要探讨业务活动的执行细节，需求人员在制定访谈提纲时应注意访谈用户的层级。

（3）需求人员记录访谈纪要建议采用“记录要点+确认+事后纪要”的方式，每个要点记录后和用户确认，事后整理访谈纪要。同时通过录音的方式作为访谈记录的辅助方式。

（4）为避免用户的非正式访谈心里，保证用户访谈时间可控需求人员应建议用户在会议室或洽谈室这样的封闭空间进行访谈。

（5）有些用户在访谈时言过其实，这种情况需求人员应找相关用户在进行一次访谈进行确认，将差异结果分析整理后提交信息化管理部门用户或领导仲裁达成共识。

（6）有些用户对访谈有抗拒心理，这种情况需求人员建议多倾听用户抱怨，化敌为友。

（7）针对用户推卸责任的情况，需求人员可通过讨论工作场景的方式进行沟通，若还是不配合则需要由信息化管理部门协调解决。

（8）用户访谈过程需求人员应该掌握的几个沟通技巧如下：

不要一次问多个问题，应该将多个问题拆分成多个递进性的子问题；

若用语言无法达成共识可采用绘制草图的方式，每个需求人员都应随身携带笔和纸质笔记本；

多听少说、不强制打断用户讲话，一定要等被访谈者讲完后再说话，需求人员与被访谈者的说话时间控制在1:2以下比较合适；

合理使用黄金静默，被访谈者回答完一个问题后静默3秒钟，被访谈者可能会继续补充回答需求人员提出的问题；

采用业务语言而非技术语言与被访谈者沟通业务需求；

在访谈过程中遇到专业术语不要不懂装懂，一定要弄明白业务术语的含义，避免理解偏差；

多问几个为什么以便深刻理解需求，最常见的问题就是这个需求要解决什问题，达成什么目标；

访谈结束后与用户逐个确认记录的要点以免遗漏或理解偏差；

站在用户的角度为自己着想，拨开立场，寻找共同利益诉求点；

需求人员在沟通过程中可使用转换和比喻的技巧方法消除矛盾；

3、调研问卷

调研问卷一般作为用户访谈方法的补充，其核心目的是为了避免用户访谈的片面性，一般调研用户样本比较大或存在跨地域用户时会考虑使用调研问卷的方法。调研问卷问题制定时应遵循如下原则：

（1）问题应按照先易后难的顺序排列；

（2）问题排列应注意逻辑相关性；

（3）尽量让封闭式问题出现在相关半封闭和封闭性问题之后。

4、文档考古

文档考古恰好填补了用户访谈、调研问卷在数据需求上的不足，它是分析细化数据需求的主要手段，需求人员在使用此方法时需注意三点：

（1）收集到的表单，尽可能让用户提供带有真实数据的样本；

（2）需求人员应根据需求分析情况主动收集相关文档而不是被动接收用户给的大量文档；

（3）收集到的相关文档也是后续定义业务术语的数据来源。

5、现场观摩

现场观摩是一种比较生动的需求收集方法，常见的是系统演示和任务示范，在需求人员对相关需求业务不太了解或涉及系统集成、需求本身由现成的系统参考可通过此方法进一步明确需求内容。

需求收集的内容应包含但不限如下内容：需求反馈人、需求提出人、需求提出部门、提出时间、需求关注层级（部门/中心/集团领导）理由、需求类型（个性需求、公共需求）、要求完成时间、需求描述、相关参考文档。

今天公司的高级顾问刘博士与产品经理们进行座谈，以提问回答的形式以点带面来解答、探讨大家在平时工作中碰到的一些问题，主要是针对软件方面。过程中，我向刘博提出两个问题。

今天公司的高级顾问刘博士与产品经理们进行座谈，以提问回答的形式以点带面来解答、探讨大家在平时工作中碰到的一些问题，主要是针对软件方面。过程中，我向刘博提出两个问题。

一、如何更好地做好需求落地？

背景：来公司这1年多时间里，负责做了大大小小五、六十个项目的需求分析，大多都是各业务大区提过来的项目需求，在这过程中面对不同项目的需求，不断地锻炼需求转化能力，关于如何更好地让需求落地看能不能从牛人身上学习到更好的方法论。

回答：

产品经理在日常的工作中，既要面对客户也要对接研发人员，在这中间充当着桥梁的作用，将业务需求与开发需求给连接起来，不同级别层次的产品经理，区别就在于“修”好这座桥的质量和效率如何。在拿到原始需求时，要有能力去甄别筛选它们，可以采用结构化方式对需求进行梳理，然后排好他们的优先级别，这样在心中对接下来要做什么事情有个比较好的认识。经过第一阶段的梳理，大概清楚要做什么事情后，接下来是将业务需求转化为系统功能的阶段，可以采用用例图（UML）的方式，将什么东西要做什么事情和如何去做给表达出来，一层层的剖析下去直至达到需求细化的程度。让开发人员知道怎么去研发。举个例子：（他拿起手中的iphone）现在我要对按下音量下键的这个需求去做分析，怎么做呢？首先我会识别出按下音量下键这个需求的合理性和必要性做个识别，清楚我为什么要去按音量下键这种场景？然后，将它转化为在系统中进行表现。在按下后，我会对软件的哪些模块进行数据的交互以及如何与用户进行交互?这就是产品经理对接开发的时候要去做的事情，同时也是让需求如何去做落地流程？

结论：

其实，过去的2年工作中，我一直都是在重复着刘博士回答的这个需求落地的过程。然后我跟他说明了这个情况后，问有没有更好的需求分析方法。比较尴尬的是，他直接回答说没有，软件的需求转化过程基本都是以这种方式进行，本质上没有太大的差异。

二、在评审过程中，如何衡量抉择最终的方案？

背景：

在日常进行需求评审的过程中，由于不同人员看待同样的问题方法会不一样，在评审过程中偶尔会出现开了N久的会议没有最终拍板的方案，作为产品经理面对这种情况，要如何去衡量最终的方案？

回答：

随机应变。无论怎么去讨论，其本质不能变的就是要满足用户需求。再有的是出现这种情况，几种实现的方式都已经可以满足用户需求，但实现的方式不一样。针对这点，产品经理要通过博弈的方式，识破出各种方案的破绽，来引导大家形成统一的共识，做出最终方案地敲定。

结论：

上面的问题其实更像是程序员与产品经理的日常撕逼。产品经理作为用户的代表，要多为用户争取更大的利益，在衡量抉择最终方案过程，多模拟应用场景来摆明依据。要是实在不行，只能这么说：方案就这么定，后果我来承担。担当的越多，责任越大，这应该也是一位成熟的产品经理在团队内的表现。

其他同事提出的问题：在您日常接触那么多产经经理过程中，觉得哪一点素质对产品经理是最重要的？刘博士答道：持续学习。社会瞬息万变，逆水行舟，不进则退。产品经理在做好分内的事情完，要再花时间去了解行业内的发展趋势，不断地学习其他优秀产品好的地方，吸其精华，弃其糟粕，不断地完善自己，与时代共成长。

刘博士建议，在产品团队中要建立起知识库，内部定期做技能、经验相关的分享。库是死的，通过分享的方式，可以让里面的知识活起来，形成产品圈特有的氛围和默契，让团队成员能够共同学习共同成长。

#声明#

本文由David原创，产品会转载发布仅用于学习交流，如涉及版权问题，请联系小编，~ 产品会~ MVP联盟~

对于软件开发团队而言，软件开发的全过程是：做什么 -> 怎么做 -> 做 -> 成果检验 ->交付部署；其中，“做什么”对应的是需求分析过程，“怎么做”对应于软件架构设计过程，“做”对应于开发过程，“成果检验”对应于测试，部署由运维团队执行后，如果达到用户的要求，则软件上线后进入软件的运行生命周期。

而在实际的软件项目开发中，“做什么”，“怎么做”和“做”是紧密结合在一起的，“做”，“成果检验”和“交付部署”通常也会是一个持续交付过程，“成果检验”的内容会受到“做什么”的影响，开展“做什么”阶段的时候，也要考虑到如何部署和交付。所以软件开发的全过程，都是紧密结合在一起的，如果刻意划分为独立的几个阶段，忽视其作为一个整理的综合影响，每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题，从而影响整体开发效率。

今天，我们首先来谈一下软件项目中，需求究竟该怎么分析？

正确的需求分析决定了我们产品的方向，需求分析搞错了，做再多都是浪费。只有方向对了你才能走出迷途，方向错了，你只能迷失！基于此，我们的需求分析可分为两个阶段，第一个阶段是收集需求，第二个阶段是处理需求。

收集需求

需求的来源有很多，需求的处理方式也不尽相同。有效的收集需求，将收集到的需求去伪存真，是产品设计环节中最重要的一环，如同大厦的地基，地基不坚实，大楼是盖不起来的。而且我们在收集到需求时，要第一时间与用户交流沟通，尽量走到用户中去了解他们的想法，深入了解目标用户在真实环境下的感受，尽可能地挖掘用户的原始需求，充分了解用户真实场景，才能真正更好地服务用户，打造出他所想要的产品。

1、还原场景

如果只是单独看用户提出的需求，你很难分析到用户的真实需求，就像有些英语单词一样，你必须放到那个语境下面去了解，才能找到用户背后真实目的。

我们可以从以下场景进行分析：

基于什么环境：地铁/办公室/室内/公共场合/走路/夜晚/户外......深入情景周围的细节中去。

基于什么用户：具备什么特征，比如身份、收入、区域.....

基于什么行为：行为或操作流程，比如购物流程、操作习惯、行为认知.......

场景分析也就是需要考虑具体什么环境（时间、地点、情境）什么类型用户的什么动机，想达到什么目标，以及人与人的关系。如实地分析记录下来，如果偏差或缺乏信息，之后的分析就会有所偏差。

2、多问几个为什么

用户需求的传递过程中总是存在着无法完全理解吸收的问题，导致所收集的需求不一定就是用户的真实需求，这时你需要做的是找到需求的提出人，多问几个为什么。这个需求提出人可能是用户，也可能是运营，也可能是技术，你多问几个为什么的时候，也就能发觉用户背后的需求。

3、数据分析

数据是客观反映产品的重要指数，也是收集需求的重要来源，前期收集的数据需要是可靠、客观的，而且数据是零散的，在进行数据分析前一定要有明确的中心，划定一个界限，收集同一个框架内的数，同时单独的数据是死的，有对比的数据才有意义。为了避免主观意识的影响，同一份数据可参考其他人员的分析结果。

4、多和别人沟通/头脑风暴

一个人的力量是有限的，当我们吃不准的这个用户需求的时候，可以把这个需求拿出来和用户讨论一下，进行头脑风暴一下，人多力量大么，当我们吃不准一个需求的时候，大家都认为的那个结果就是需求分析的结果。

处理需求

处理需求的阶段，也是产品经理将需求进行筛选，梳理业务流程，设计产品架构的阶段。

1.需求筛选、分类

尽管我们保持严谨的态度收集大量的需求，其中还是有很多需求是“伪需求”，甚至是不合理的，我们第一步就需要将这些需求进行“清洗”，择优去重、去伪存真。

2.设置优先级

一般来说，从需求类型来看，基本型需求>期望型需求>兴奋型需求；

从需求来源来看，战略性需求（用户提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）。需求优先级判断最常用的是用四象限法则去评定优先级，另外可以使用RICE评定方法，KANO模型等。

3.竞品分析

由于在这个阶段，产品经理不仅要定义目标用户、产品使用场景，还要确定核心功能，产品流程等等，因此通过竞品（如果有）来辅助处理需求是一种很有效的方法。

通过相似竞品的用户定位、功能反推竞品的需求，与自己的需求进行对比；将自己的需求代入竞品中，看流程是否符合逻辑；与竞品进行对比，分析需求的异同。

4.需求评审

在这个阶段之前，作为产品经理对于产品应该有了一个完整的模型，但仅仅是理论上的模型，确保UI、UE、前端开发、后台开发、测试参与，从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看作是产品开发的初始化或者预开发。

需求分析是基于用户沟通、背景认知、人性理解，层层还原一个需求本源的过程。我们对一个需求的还原程度越高越准，越有机会在后续产品设计给出合理的方案。

写需求分析之前，要先了解需求分析的定义和目的。看看百科是怎么说的：需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

需求分析，可以理解为对用户/客户的需求的分析。也即是开发人员，要弄懂用户想要的是什么，重点在用户的需求。

需求分析文档名的命名格式，可以参考如下格式：需求分析说明书_某系统_版本号_日期

如：需求分析说明书_某网上商城服务系统_V5.0_20180119。

软件工程的需求文档，通常使用word来编写。

文章下面内容等，将从一个真实需求分析说明书着手解析。并非所有需求文档均需按此结构和内容。

需求分析文档主要应包含以下模块，对每个模块，主要需要编写的内容也将给出。

正文前：修订记录，目录，引言和引用文件

首先在这些之前，你还需要弄一个封面，封面内容是这个文档的名称，加上如日期，公司名称这些信息。

修订记录

列一个含版本号、修订人、修订时间、修订内容记录的表格，每一次进行较大更新时，都应进行记录。

目录

目录自动生成即可。每次更新内容，记得更新目录就可以了。

引言

引言中包含了“标识”、“数据库概述”、“文档概述”。

标识即是通过标识号，说明这个文档的属性。如图

数据库概述需要包含数据库的运行环境，如ORACLE11g。以及涉及到的数据管理问题，同时可以对数据库设备等做一个简单的要求描述。

文档概述顾名思义，对文档进行简单说明。参考如下：

“本需求分析说明书是通过规范文档的方式与客户方界定系统的开发范围，同时作为开发人员和测试人员进行系统分析、设计、开发和测试的依据。

本文对业务需求进行描述，在理解业务的基础上编写需求全景分析描述，提供活动图、业务用例图、及用例过程描述，用于系统建设前期达成统一的建设目标和实现方式”

引用文件

文档中涉及引用到的文件，都可以写在这里。而一般而言，你们的投标文件、总体技术方案、实施方案等自然是这里必备的内容。

业务概述

业务概述从目标、业务内容、运行环境、关键点、用户特点、技术约束几个方面来写。

目标

目标往往就是投标文件或是招标文件的建设目标，也就是这个项目需要完成的事情，需要达到什么效果。

业务内容

业务内容主要是对目标的一种详细化，简述目标中的子系统，每个系统包含的大体内容。如建设统一用户管理平台。

运行环境

运行环境可以根据内外网等不同进行划分。表达形式上可以参考下图。

关键点

关键点可以从业务关键点和技术关键点进行切入。如需要满足一定量的高并发、某些业务需要特定的流程等，都可以列条文字表达。这只需要对关键点进行简单罗列和说明即可，不需要写实现方式之类的东西。

用户特点

一般来说，用户为pc端，app端等。也有可能有的为自然人，有的人企业/团队，根据自己项目的特点，进行罗列，简单说明他们的区别。

技术约束

技术约束可以挑选使用的技术中会对系统进行一定要求的技术来写。一般可以写该技术的概述、基础服务、架构特性和平台约束、

前两点，根据自己使用技术内容，可以简单完成。后面的架构特性，则是一个从软件层面，一个从硬件层面来阐述。

下图为SSH下的软件架构可放的图。

硬件方面，可以列出的物理设备的清单。如数据库服务器的配置要求，台数、应用服务器的此类要求等。

功能需求

功能需求是这个文档的主要内容部分，应占文档篇幅的60%以上。毕竟我们需求分析，主要还是要分析用户的需求的。

在该大菜单下，需要对之前的建设目标进行分模块的编写。一般而言，除了列举目标中的建设子系统外，还需要加一个“应急系统”和“特殊说明”尾好。

对于每一种的图的内容，可以直接根据它的名字，在Visio中新建时，找到对应的图进行创建，参考网上搜索的样例进行创作。

下图为角色用例实现图（仅供参考）：

其他需求

其他需求这里虽然是列举为一点，但是还是要一个列一个大的菜单。可以含“接口及数据需求”、“计算机资源需求”、“数据需求”和“操作需求”。

接口及数据需求

这里根据实际情况，列举需要接口和数据要求即可。最好是两个分开。

计算机资源需求

这里分计算机硬件需求和计算机软件需求。下图为参考目录结构。

数据需求

数据需求则可以从数据量级、特殊数据的输入输出和数据预处理进行。这里需要根据自己项目情况，进行罗列和梳理。

操作需求

这里的操作需求可以是普通用户的，也可以是系统操作。如服务器维护，数据库维护等，都可以算是一种操作需求。

故障处理、算法说明等

这里的等，可以是下列内容：合格性规定、需求可最总行、尚未解决问题、注解和附录等内容。

这里的内容一般为可选内容，不过像附录和注解这些，一般都是要有的。而算法等如果有则写，没有也可以不写。

（如果觉得对你有帮助，希望可以支持一下哦，如需转载，请注明出处，作者：百家号：深海程序员）