大数据应用的需求分析方法

张靖笙

传统方法在大数据需求面前遇到问题

       需求分析阶段关系到一个软件开发的成败，这已经得到了普遍的认识,然而，根据作者实战经验，在大数据应用项目中，按照传统软件工程规范要求的需求分析往往是一个非常尴尬的过程，为什么呢?

根据笔者在实际工作中的经验,问题主要来自以下方面：

1.需求分析本身的难度。需求的任务是了解和描述软件用户对软件的需求，即明确做什么。但在实际的软件开发中，用户了解他们的专业领域，但计算机知识，特别是软件知识往往比较薄弱,而开发人员与此恰好相反，而在需求分析的过程中，双方面对的往往不是一个可见的产品，而只是头脑中的构思和想象，由于专业的差异和沟通的有限，用户的许多需求对开发人员来说往往是难于理解的和准确把握。

2.传统软件工程规范在需求分析的严格执行有实际管理上的难度。在广大的应用软件开发部门，软件开发工作的地位往往只是本单位业务的辅助，一般没有专职的而且非常有经验的系统分析员，需求分析往往由主管经理和开发程序员简单进行，而领导往往重成绩多于重过程，对于一个没有显效的需求分析过程，领导的耐心往往有限，这就造成了对需求分析缺乏严格的管理和要求。

3.严格按照软件工程规范要求进行需求分析在时间和开发成本的限制。由于用户对软件技术的认识水平，他们对软件的开发在时间上往往要求过高，特别当用户是单位的上层领导，他们往往觉得这种对他们而言空洞无物的分析是开发人员的纸上谈兵,时间一长不免就会流露出不满。这令开发人员非常尴尬，往往非常严重地打击他们的自信心和士气。

综上所述，传统软件工程规范中需求分析理论在实践中的矛盾是成本，效率和规范要求间的矛盾。而忽略规范要求的代价也是惨重的，那我们能找到一种方法解决以上矛盾吗？

大数据应用的需求特点

 数据库技术的核心思想是数据的独立与共享，所以开发数据应用，就是利用云计算、数据库、数据分析等技术来组织、管理和使用信息。不同形式的数据应用可谓多种多样，但功能需求的核心是围绕着数据分析需求来展开的。笔者曾开发过多个不同应用领域的数据应用，我发现在数据应用中虽然功能很多，许多功能在逻辑上相似，往往只是处理的数据不同，所以，笔者认为数据应用需求分析应该围绕数据(信息)，而不是软件功能展开。这与传统的需求分析中以软件的功能需求为核心有明显的不同。从这个意义上，如果传统需求分析阶段是“做什么”，在数据应用需求分析阶段就是先要解决“有什么”，然后再明确“做什么”。

大数据需求分析工作方法

 需求分析作为软件工程的第一阶段，是整个软件开发项目进行设计和实现的基础，决定了一个项目的成败。但是需求分析不能只看成是一个独立的阶段，对需求的了解贯穿整个项目的始终，了解需求的过程是一个逐步细化，逐步深入的过程，整个项目自始而终都需要与用户交流。

 既然大数据应用需求以数据为中心，在需求分析阶段就强调数据和数据结构的分析一点也不过分。围绕数据应用的需求分析大体上分为以下几个阶段：

1)场景需求分析(总体设计)

2)概念需求分析(概念设计)

3)细节需求分析(详细设计)

4)界面需求分析(界面设计)

 这些需求分析贯穿整个项目的各个环节中，与设计是穿插在一起。

大数据需求分析过程活动

1)场景需求分析

 这个阶段体现了系统的总体构思与设计，任务是了解系统的组织形式和功能需求概貌，解决“是什么”的问题。我认为场景需求分析主要任务是用户应用场景的定义，需要明确用户将来是用何种方式、在什么条件下、如何用哪些数据解决什么问题的场景，这当然也会涉及到硬件，用户环境，系统功能等多方面的全局考虑。如界面是手机APP应用还是Web 应用，如何进行功能的分层。这些都需要在场景需求分析过程中决定。

 场景需求分析工作是大数据应用项目的早期分析，所以对功能的描述应该有高度的抽象性，在理想的情况下，一个系统最好由一张纸内直观图形化描述，便于开发人员对系统目标的整体把握，也保持了与用户交流的灵活性和一致性。所以在项目初期，我不赞成用功能模块图对功能需求做太多层次的金字塔式罗列，特别如果是系统的分布式分层设计，详细的功能模块图在项目早期没有什么实际意义，反而容易舍本求末。如对大数据应用场景中数据范围的分析中，可以用笔者前文所介绍的商业模式分析方法，从商业模式的角度对于数据范围做明确的界定。

2)概念需求分析

 概念需求分析的任务是对系统中涉及的概念、数据范围和内容等进行调查和分析，分析有什么信息、从什么地方可以可靠获得，如何组织和描述数据，数据由那些数据项组成，各数据项是什么含义，数据的走向是什么样的？概念需求分析的目的是建立系统的概念模型，主要是建立描述数据的静态模型和描述系统运行流程的动态模型，解决“有什么”问题。

 当完成模型需求分析后，就要进入到概念需求分析。做概念需求分析，首先要收集原始资料，然后请用户讲述手工的工作流程，根据用户提供的原始资料和对工作流程的了解的基础上，我们才可以着手进行概念设计。

3)细节需求分析

 细节需求分析要在进行了概念设计之后进行，这个阶段是分析如何具体实现用户需求,就是解决“怎么做”的问题。这个阶段要对用户的需求完整而清晰地确定下来，所以与用户的交流比前两个阶段多，交流的内容应该更加具体。

 细节分析的具体任务是要根据概念设计定义的概念模型制定具体的实现细节。对于静态模型，要给出详细的数据字典，包括了表，数据项，数据项限制条件等详细信息。对于动态模型，要给出具体的状态定义，事件定义，状态改变的流程，对数据所有操作的定义等等详细的设计信息。要求根据细节需求分析的成果应该能成为编码和建库的依据。

   对于大数据应用，可能还要明确的是采用怎样的大数据技术架构（例如Hadoop）和数据挖掘模型，随着开源技术的普及，目前成熟的大数据工具和数据挖掘模型选择已经很多，实际上很多数据应用的开发工作就是在现有的一些大数据分析工具的基础上结合应用场景需求来做些配置性的简单编码就可以了，没有必要做一些重新发明轮子的事情。

4)界面需求分析

 用户能否用好软件最终决定项目的成败，良好的用户使用界面是不可忽视的。用户界面的好坏并不是追求界面的花巧(这是程序员经常犯的毛病),而是界面的设计是否能提高用户使用软件的效率，这需要了解用户的使用环境，操作水平，操作习惯，个人喜好等多方面。输入输出需求分析要做到界面设计和概念设计的相互独立，不能因为界面的表示影响概念设计的稳定，同时也要保持能适应用户各种不同操作要求的灵活性。具体可以先和用户共同草拟一些界面设计大纲，在开发过程中邀请用户试用软件，根据反馈意见不断改进和修改。

大数据需求表达工具的考虑

 我们分析“有什么”信息，传统的需求分析理论用数据流图和数据字典来表达“有什么”信息对大数据应用可能不是特别合适。传统的数据流图核心是面向软件功能的，而在许多大数据数据库应用系统开发初期，在没有清晰完整的大数据信息内容构成分析前，功能的需求往往难以稳定。在大数据应用的需求分析初期，我不提倡使用数据流图，因为在大数据应用中，数据流图往往不能令人满意地说明信息构成问题，而且随着数据的增加，功能流程的变迁需要经常修改早期的设计，这会造成工作的反复。数据字典可以表达数据的构成，但却没有定义数据的类型。在一个大数据应用中，数据的类型的通过字段类型表达，有开发经验的人应该知道，清楚每一个数据字段的含义和类型在开发数据库应用中有重要的意义，试想一下，如果一个数据格式是视频或者图像，对数据的功能需求不言而喻。而传统的需求分析过程不要求确定数据的具体类型，而在开发一个数据应用时，需求分析阶段忽略了这一步就会毫无疑问地造成对需求理解的模糊，并使得需求分析变成空洞无物的纸上谈兵。所以，对于数据应用需求分析的表达，最好还是和业务场景的分析结合在一起，笔者推荐使用质量管理大师戴明(Deming)博士发明的SPIOC方法。

   SIPOC模型是一代质量大师戴明提出来的组织系统模型，是一门最有用而且最常用的，用于流程管理和改进的技术。是过程管理和改进的常用技术，作为识别核心过程的首选方法。

   为什么笔者推荐这个貌似是跟IT界不太搭边的管理学方面的模型呢？从接下来的示例可以看到，在SPIOC里面，我们可以看清楚两方面的数据需求，一方面是业务流程工作本身要处理的数据，另外一方面是更有应用前景的分析业务过程效率中的条件测量指标（KPI）和成果测量指标（KPO）数据，这两个指标性数据是支持不断优化业务流程、最终达到精益目的的必要手段，数字孪生理念之父Michael Grieves说得好：“信息是被浪费的物理资源的替代品;在精益的理念世界里，我们最终能实现用最少的资源数生产产品的目标”。没有数据支撑的精益是无法落地的，这样数据应用的价值就不言而喻了。

产品光有精益是不够的，产品也必须是创新的，不仅要减少资源的浪费，同时也要创造新的信息和知识，使得创新产品成为可能。从这个方面来说，今天做业务的过程也是一个不断积累数据资源的过程，这样才能为创新奠基大数据的基础。

（本稿完成于2018年9月30日，如需要引用，请注明出处）