云平台需求分析规格书

云平台需求分析规格书

目录

第1章整体方案 (3)

1.1 需求分析方案 (3)

1.1.1 需求分析标准和规范 (3)

1.1.1.1 需求分析定义 (3)

1.1.1.2 需求分析标准 (3)

1.1.1.3 需求分析规范 (4)

1.1.1.4 需求分析目标 (5)

1.1.1.5 需求分析方法 (5)

1.1.2 总体需求分析 (7)

1.1.3 非功能性需求分析 (10)

1.1.3.1 平台基础性需求 (15)

1.1.3.2 标准规范分析 (18)

1.1.3.3 应用体验需求分析 (22)

1.1.3.4 信息安全分析 (30)

1.1.3.5 系统响应需求 (31)

1.1.3.6 集成需求分析 (32)

1.1.3.7 系统部署需求 (34)

1.1.3.8 其他需求 (35)

第1章整体方案

1.1需求分析方案

1.1.1需求分析标准和规范

1.1.1.1需求分析定义

需求来源于客户的一些“需要”，将这些“需要”进行分析、确认后形成文档就是需求分析，需求分析的文档详细的说明了云平台数据管理升级完善及运维和机构改革软件服务项目必须或应当做什么。

1.1.1.2需求分析标准

需求分析通用评价标准包括：完整性、正确可行性、优先级、简明性、可测试。

1、完整性

完整性是指对需求的全覆盖，包括组织机构及用户分析、功能需求、性能需求、接口及集成等；

2、正确可行性

正确性和可行性是指保证需求和业务人员的目标相联系，使用用户语言和需求模型正确表达用户需求，同时保证在现有开发能力和系统环境下需求的可实现；

3、优先级

优先级是指需求的必要性，功能是否必须，优先级和重要程度怎样，是否能被推进或被削减；

4、简明性

简明清晰是指使用业务术语或缩略语，表达清晰明了；

5、可测试

可检测和可跟踪是指可根据需求设计测试目标和测试进度，可跟踪需求缺陷。

1.1.1.3需求分析规范

通常需求分析包括总体需求分析、总体架构需求分析、项目背景分析、云平台数据管理项目日常运维及优化完善需求分析、机构改革软件服务需求分析几部分组成。

●总体需求分析

总体需求分析从服从管理、质量保障、项目管控和上线控制、时间控制、系统优化和质量保障几个方面进行阐述。

●总体架构需求分析

总体架构分析指对招标文件中的应用架构进行分层描述。

●项目背景分析

项目背景从背景、税收业务发展背景、云平台数据管理建设情况以及机构改革背景进行阐述。

●云平台数据管理项目日常运维及优化完善需求分析

云平台数据管理项目日常运维及优化完善部分从需要日常运维功能、需要优化完善功能两部进行分析阐述。

●机构改革软件服务需求分析

机构改革软件服务部分主要从机构改革涉及的功能进行分析阐述。

●非功能性需求分析

非功能性需求分析从平台基础性要求、标准规范分析、应用体验需求分析、信息安全分析、系统响应需求、集成需求分析、系统部署需求和其他需求几部份展开进行详细的阐述；

1.1.1.4需求分析目标

需求分析的目标是：遵循总体规划，以云平台数据管理升级完善及运维和机构改革软件服务项目业务需求为基础，以全局技术需求为指导，依据招标书对云平台数据管理升级完善及运维和机构改革软件服务项目的具体要求，形成云平台数据管理升级完善及运维和机构改革软件服务两大类。对于云平台数据管理升级完善及运维，按云平台数据管理升级完善及运维和机构改革软件服务项目的特点，从平台层优化完善及运维、数据层优化完善及运维、功能应用优化完善及运维、数据治理、应用支撑、数据服务等多方面进行分析；对于机构改革软件服务，按云平台数据管理升级完善及运维和机构改革软件服务项目的特点，从初始化、数据层调整优化、应用层调整优化、数据治理调整优化及新增书籍分析五个方面进行分析。

1.1.1.5需求分析方法

云平台数据管理升级完善及运维和机构改革软件服务项目需求受应用环境、项目制约因素、非功能性需求、标准规范、工具要求、云计算支撑平台、大数据支撑平台、数据平台建设、治理体系构建、主体画像、全国视角纳税人遵从分析、税收动态展示等制约，如下图所示:

本项目的需求分析将应用环境、项目制约因素通过应用架构需求分析章节分析，云计算支撑平台、大数据支撑、数据平台、治理体系平台、主体画像、全国视角纳税人遵从分析、税收动态展示、工具要求通过云平台数据管理项目日常运维及优化完善需求分析、机构改革软件服务需求分析两章节分析，其他部分在本章节分析进行分析。

下面具体说明：

1.1.2总体需求分析

云平台数据管理项目以云平台为基础，以云服务器软件、负载均衡软件SLB、对象存储软件OSS、大数据计算服务软件ODPS、数据可视化引擎DataV等18款大数据产品为依托，构建了以数据治理为核心、以一体化云平台为载体、满足各类用户需求的税收大数据平台。主要完成平台层、数据层、应用层的建设：

1.平台层建设。主要包括计算存储和网络设备、系统软件工具集、安全及运维监控管理的建设，从硬件和技术层面有效解决传统技术结构不足以支撑海量数

据及非结构化数据分析应用需求的矛盾，搭建灵活、可随时调用计算资源的数据云环境，并构建完整的三层服务模式。通过建设IaaS层，为全国数据大集中环境提供包括CPU、内存、存储、网络、操作系统等基础设施资源，提高资源的利用率，降低采购成本；通过建设PaaS平台，基于IaaS提供的能力，以服务的方式提供计算平台和软件组合，为最终用户提供云环境下的应用开发、部署和运行平台，解决应用软件开发的规范化问题，降低系统运行维护成本；通过建设SaaS 层，全国数据大集中环境为总局、省局、纳税人、相关部门提供个性化的数据服务。

2.数据层建设。通过构建数据治理体系和开展数据分析处理，将云平台和工程规划范围内的其他数据平台集于一体，使金三生产系统数据、总局保留软件数据和多来源的外部交换数据相互贯通，实现各类数据的集中定义和管理，为建立统一数据视图、数据集市、各类分析业务的定义、指标和规则定义以及数据集成定义提供语义基础，同时提供对各类数据的审核管理和维护机制，维护数据的完整性、准确性以及一致性，实现数据生命周期管理、数据标准、数据审计等各项功能。通过数据治理过程，使得数据标准、数据内容以及数据质量都能够得到持续的提升，保证数据资产的长久价值。

（1）基础层完成了对税务数据、外部数据和互联网数据三类数据的集成，共集成了六千余张表，同时完成了数据清洗、数据标准化以及非结构化数据转结构化数据等操作。

（2）中间层完成了四大主题库和标签体系的建设。四大主题库分别是：组织库（法人和法人分支机构），涉及模型近200个；自然人库，涉及模型近百个；税务机关库，涉及模型近200个；关系库（单位纳税人之间、单位纳税人与自然人之间），涉及模型几十个。同时构建了企业、自然人、税务机关标签体系，包含：企业标签（一般纳税人标签、小规模纳税人标签、千户集团标签）、自然人标签、税务机关标签。

（3）模型层完成了面向应用的数据模型构建。在建设模型层的过程中，以构建面向应用类数据模型和构建分析挖掘类分析模型为原则，基于税收动态监控、票流分析、关系云图、增值税发票查询分析系统等应用共设计数百个数据模型，上千个指标口径。

3.应用层建设。基于全务数据，建立多层次、多类型、多渠道的数据服务体系，为总局各司局和省局不同类型用户提供多维数据服务，满足各级税务机关在决策、管理、执行、研究等方面的工作需求。应用层前期建设立足于税收业务特点、现状和需求状况，重点选取部分应用进行验证性和示范性开发。已开发用户画像、票流分析、纳税人关系云图、纳税人关系分析、增值税发票查询分析系统、风险情报系统、单管户查询、企业信息自助查询、数据资源需求管理、数据质效考核、税收动态监控大屏版、税收动态监控桌面版、云平台访问监控以及涉税专业服务动态监控等应用。

4.数据治理。工作主要从五个方面开展：元数据管理、数据资产管理、数据标准管理、数据质量管理和数据安全管理。在数据标准方面继承了国家标准化内容，把控数据建设标准。同时结合业务需要积累并整理了核心征管系统业务表单和物理表的对照关系，形成了包含：核心征管系统、个税系统、防伪税控系统、外部交换系统、出口退税系统等业务系统的数据字典。在数据质量方面制定数据质量规则指标二百多项，推动全国数据质量持续优化。

5.数据服务。云平台数据管理项目运行一年以来，为总局多个业务司局提供数据加工服务；承接总局稽查局的选案工作；承接纳税服务司纳税信用等级评定指标调整测算工作，为信用评价指标调整提供数据依据等；开展新办企业预警模型、非正常户预警模型、进销不匹配模型等指标设计测算工作。

云平台数据管理项目实现了税收征管数据的全国集中和规范管理，为各级税务机关提供了强大计算处理能力，有机整合大数据技术，全面集成内部数据、积极拓展外部数据、强化数据治理能力，实现了数据的过程监控；建立了税务数据的资产化管理模式，并以用户为核心提供差异化的数据服务，形成了开发协作的税务数据生态环境。同时，加强外部数据交换，实现了税务数据与外部门数据的有效共享整合，为国家信息共享化建设提供了税务方案。

云平台数据管理项目升级完善及运维和机构改革软件服务项目以云平台数据管理项目的建设内容为基础，根据的业务需求和国合并工作要求，对平台功能进行持续性升级完善，集中、拓宽和整合内外部数据资源，统一规范数据应用范畴，提升数据治理能力，为各需求主体提供更为全面丰富的决策和参考支持，并提供必要的基础运维，保障云平台正常运行。

因此，我公司做到以下要求：

一、我公司充分理解国家财税体制改革、税务系统服务与管理创新的要求，不断适应新技术的发展，充分考虑用户实际使用过程中提出的优化建议和要求，不断完善和优化应用系统。

二、工程各应用系统项目业务关系复杂、建设周期较长，在项目实施过程中面临多种部署方式、项目变更等风险，我公司对此充分认识，采取有效措施，规避风险，确保本项目按期按质完成。

三、我公司建立完善的项目管理机制，做好运维和优化之间的有效衔接，并就合同范围内运维和优化内容提供完整的文档资料。

四、招标人将不定期对项目实施情况和工作质量进行评价，我公司对工作评价中的意见和建议及时进行答复，并提出相应的改进方法和措施。

五、我公司遵守税收信息化建设的整体要求，满足税务系统业务、技术、数据、安全、运维和项目管理等各项要求，服从招标人的管理。

六、我公司严格按照招标人要求完成运维保障和优化完善工作，招标人有权根据实际情况对工作计划进行调整。

七、一般情况下，对超出工作量的情况，招标人不再另行支付费用；如遇重大业务和信息化变革需求，招标人另行安排，不纳入本项目范围。

八、我公司在投标文件中针对以上需求提出具体的系统运行维护和优化完善方案。

九、时间要求：合同签订12个自然月内按照需求要求完成项目优化及运维实施、故障综合分析及应急处理、性能持续优化等工作；自机构改革实施后，按照国家时间要求，重新进行全国数据加载、归集、对云平台数据层、应用层进行调整优化，及时准确集成数据至云平台，并按照机构合并并要求展示和供应数据，保证云平台平稳运行。招标人有权根据实际情况对上述计划进行调整；项目验收前完成优化和质量保障工作。

十、招标人有权根据政策变化、项目执行效果及评价结果等情况提前终止合同。

1.1.3非功能性需求分析

非功能需求规定了系统必须满足的服务水平、系统非运行时间的属性以及系

统必须遵守的约束。非功能需求适用于整个系统、系统的几个部分或特定的用例。

非功能需求虽然不直接影响系统功能，但在用户和系统支持人员对该业务系统的认可方面具有很大的影响。

非功能需求包含许多方面。主要的非功能需求包括以下几方面：

●系统性能

●可靠性

●可用性

●易用性

●可维护性

●可扩展性

●可伸缩性

●可移植性

●可重用性

下面进行具体介绍。

●系统性能

交易可以定义为：一个交易是当一个单一角色跨越系统边界触发一个事件并执行一定数量的处理和数据库访问，它将影响架构中的所有服务器层。交易响应时间指完成目标系统中的交互或批量处理所需的响应时间。根据业务处理类型的不同，把交易划分为三类：交互类业务、查询类业务和大数据量批处理类业务，分别给出响应时间要求的参考值，包括峰值响应时间、平均响应时间。

?交互类业务

日常交易指传统的交易业务处理，具有较高的响应要求。

备注：以上交易如果涉及与其它系统之间交互，响应时间应包括系统之间交互的时间;以上给出的响应时间为参考值。

?查询类业务

查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要

根据具体情况而定，在此给出一个参考范围。

备注：业务处理过程的交互操作的响应时间参见上面交互类业务的相关指标。简单查询如登记资料查询、业务清册、申报表查询等。复杂查询如多表数据关联统计分析查询类报表等等。

如有特殊要求，可以在具体用例文档中单独给出响应时间要求。

?大数据量、批处理业务

批量交易指一次完成多笔业务处理的交易，如批量扣缴等，由于批量交易的数据量不确定，需要根据具体的情况确定响应时间。

?复杂的分析类业务

复杂的分析业务如复杂的预测、评估类分析业务。

●可靠性

1、最大宕机时间

?公共数据分析支撑平台：最大宕机时间 1 小时。

?指标管理平台：最大宕机时间 1 小时。

?数据治理平台：最大宕机时间 1 小时。

?数据集成平台：最大宕机时间 1 小时。

?征管状况分析查询统计：最大宕机时间 1 小时。

?风险管理及政策评估：最大宕机时间 1 小时。

?知识管理：最大宕机时间 1 小时。

?绩效管理：最大宕机时间 8 小时。

?核算：最大宕机时间 1 小时。

2、系统备份

提供备份系统和无单点故障。

3、灾难恢复备份

遵循工程容灾设计方案。

●可用性

业务系统应满足 7×24 小时可以使用。

●易用性

1、易理解

?系统所有的业务功能界面风格和操作流程一致；

?业务表单尽量做到所见即所得；

?界面美观、简洁、高效；界面各部件的布局应该保持合理性和一致

性；

?界面风格一致，颜色调和、提示清晰、窗口大小适当，使用方便;

?在选择快捷键、缩写、暗示和图标时应符合税务行业为习惯。

2、易操作

?常用操作有快捷键支持，大部分操作能够在小键盘内完成；

?信息录入能够完全通过键盘完成；

?无论逻辑步骤还是操作步骤都应避免繁杂。

3、易学习

提供在线帮助，系统关键业务操作应提供在线帮助文档和提示信息，使操作人员能够快速直观的利用这些信息进行相应的业务操作，并对各种状态和操作结果进行及时的反馈和提示。提供符合税务行业习惯，详细、易读、易理解的操作使用手册。

4、需遵循“”工程的界面集成标准规范。

●可维护性

1、可配置

人员机构的可维护系统应具备人员/机构等基础信息的维护功能，系统应该能够快速的对人员/机构信息进行维护和调整操作。

?岗位权限的可维护性

系统应具备岗位权限的维护功能，系统应该能够快速的对岗位权限进行权限赋予和回收等维护操作。

?业务流程的可维护性

系统主要业务流程应具备维护功能，可根据业务规则的变化快速的对业务流程进行调整维护操作。

?服务接口的可维护性

系统主要业务功能应提供标准的服务交换接口，可通过开关配置快速的提供对外服务能力。

?参数指标的可维护性

系统应具备规范、完善的参数指标的管理功能，具备针对系统运行基础性能参数进行配置和维护的功能。

2、可监控

?提供日志审计功能

系统每个组件应具备规范、完善的日志管理功能，具备多级日志搜集开关、有效/失效开关、性能指标搜集开关以及开配置参数表。

?业务流水机制

为保证关键业务一致性，建议考虑采用流水机制。

?标准监控协议支持

符合业界主流监控软件的接口规范，能够将监控数据方便的接入到监控软件中，便于集中监控和管理。

3、可读、易于修改

要求在系统的建设过程中要有规范、清晰、完整和详细的文档。如业务需求阶段要有业务用例模型、业务活动图、业务规则、表证单书等；系统需求分析阶段要求有系统用例模型、用例文档、规则说明等；概要设计阶段要求有宏观设计文档；详细设计阶段要求有类图、时序图等；编码阶段要求有程序设计说明、变量定义说明等；测试阶段要有测试用例、测试记录等。

4、易于升级

要求数据库、应用服务器、开发工具能方便地进行版本升级，具有向下兼容性；易于升级也要求客户端的升级工作量较小，要求采用浏览器客户端而不是

GUI 客户端。

●可扩展性

在设计上必须具有适应业务变化的能力，当系统新增业务功能或现有业务功能改变时（如界面的改变、业务实体变化、业务流程变化、规则的改变、代码改变等），应尽可能的保证业务变化造成的影响局部化。系统应提供一个弹性的架构，支持使用配置而免编程的方式对业务流程、业务表单、查询统计等功能的定制与调整。

●可伸缩性

当系统容量发生变化时，应能通过各个层次的扩充，保证系统合理的响应时间和吞吐量，支持负载的划分与均衡。

●可移植性

应用系统应具有硬件平台无关性，支持主流的硬件平台和操作系统。

●可重用性

可重用性主要是指软件产品在不同的系统建设中可以被重复利用的程度。要提高系统的可重用性，应采用构件化的设计思想，即在提供标准化的服务接口的前提下可以替换各种可选的实现，而不会影响系统其他部分的实现，以此将系统可重用部分可能的变更充分的局部化。

1.1.3.1平台基础性需求

云平台数据管理项目在部署，基于全国统一的网络环境运行，近百万的用户群体，业务应用繁多，灵活性较高。为高效实现业务应用，云平台数据管理平台建设满足以下基础性需求。

一、建设全国统一的数据项、指标、维度等标准体系

数据项、指标和维度的标准化管理，保证基本语义的规范、业务处理的规范以及未来系统良好的可扩充性，成为征管操作型业务与云平台数据管理型业务自身良性发展的重要基础，为全国数据应用的规范性创建、大范围复用提供统一的数据环境。

（一）建立全国统一标准的数据标准和数据模型

根据现行税收征管业务状况，以全国统一标准的《税收征管业务数据项清册》（以下简称《数据项清册》）为基础，建立云平台数据管理平台的数据标准、数据模型和数据架构，并将其纳入系统，随系统应用不断发展完善。

《数据项清册》是对现有数据项的归集和汇总，主要目的是为了规范统一及方便查询。《数据项清册》主要包括：序号、业务类别、数据来源、数据项名称、数据项代码、数据类型、关联代码表、数据项涵义（基本语义、特殊语义）、有效标志、修改记录、备注等项目。

（二）建立全国统一标准的指标体系

根据税收征管业务需求和云平台数据管理业务需求，建立全国统一标准的《税收征管业务指标体系》以下简称《指标体系》），并予以实现，随系统应用不断发展完善。指标体系》不仅由总局维护，同时也可以由各地根据实际需求自行拓展。

《指标体系》主要包括：序号、业务类别、指标名称、可分维度、时间属性、指标涵义（基本语义、特殊语义）、取数范围、推荐算法、鉴定级别、有效标志、修改记录、备注等项目。

（三）建立全国统一标准的维度清册

根据税收征管业务需求和云平台数据管理业务需求，建立全国统一标准的《税收征管业务指标维度清册》1.0 版（以下简称《维度清册》），并予以实现，随系统应用不断发展完善。《维度清册》主要包括：序号、业务类别、维度名称、维度涵义、维度内容、有效标志、修改记录、备注等项目。

二、集成通用数学统计、模型分析方法和支撑工具平台依据分主题业务需求，集成以下数据统计、模型分析方法和支撑工具：

简单统计和分析方法，如：求和、分类统计、平均数、中位数、极大极小值、计数、比率（含同比、基比、环比、比重等）、排序（单项排序、TOPN 分析、综合排序、累计排序等）等；

数据差异类分析方法，如：方差、标准差、离散系数等；数据的分布的形状，如偏态系数和峰态系数等；

数据分析或建模方法，如：相关分析、因子分析和主成份分析、聚类分析、80/20 集合分析、区间分析等；满足于横截面数据、时间序列数据、面板数据的

应用预测分析，如：一元或者多元线性回归模型、时间序列模型（指数平滑模型、分布滞后和自回归模型、ARIMA）；以及支持向量机模型、决策树、神经网络等；

常用的图表支撑包括：条形图、饼形图、直方图、散点图、折线图、仪表盘、趋势图等。

三、自主构建独立打包的各类主题数据应用方案

（一）查询分析报表方案打包发布

支持用户在自定义查询、自定义分析、自定义报表时调用封装完成的数据模型，支持用户把成熟的自定义查询、自定义分析和自定义报表功能发布为固定的查询，发布后的查询功能界面可以被其他用户在门户中直接使用。

该方案用于查询、征管状况分析和报表应用。

（二）分析模型方案打包发布

通过对数据项的管理、指标的管理、数学方法的引用，来构建每个数据应用，将业务描述和计算机处理打包成独立的方案，方案是实现特定的业务功能，是基于数据分析下的指标、算法的组合应用来解决具体问题。该方案用于征管状况分析、风险管理和绩效管理应用。

四、纳入知识管理体系实现数据应用方案全国共享

各地根据自己的实践经验，基于统一的数据应用平台将业务方案（数据分析方案）打包上传到知识管理平台进行共享。方案可以被其他用户提取并修改。其他各地可结合本地实际情况按照自己的需求自主学习，由于数据统一，下载相关的方案后只需进行个别参数调整，就可形成适合本地使用的业务方案（数据分析方案），直接进行测试应用。

系统自动记录每个方案的使用频度及详细情况，随着时间的推移，使用增多，使用频度较高的数据分析方案日趋成熟，得以保留，使用频度较低的方案则被系统自动淘汰，形成基于网络自发的迭代功能。一方面，按照系统点击量并由专业化团队构成的专家评审、大众评审对方案进行排序评价。另一方面对方案提供者、参与者进行网络激励、组织激励。通过评价和激励结合的管理方式，实现对方案的可靠性提供保障，从而促进方案的优化与提升，实现持续改进。

1.1.3.2标准规范分析

云平台数据管理平台的标准和规范，包含统一的数据标准和业务标准，统一的项目管理和开发规范，业界成熟的开放标准（协议），和自身特点定制自己的标准和规范。通过标准和规范的建立实现：

●信息共享和顺畅的信息交换；

●支持信息的高效、综合分析利用和决策分析；

●方便沟通理解，项目管控；

●需求、设计、程序、测试等技术成果共享和重复利用。

1.1.3.

2.1已有标准和规范

1.1.3.

2.2需要整体考虑的标准和规范

1.1.3.

2.3需要云平台数据管理建立的标准和规范

云平台数据管理平台除了遵循一些开放的标准和规范外，还需要建立的标准和规范，包括以下内容：

云平台数据管理系统的标准和规范，包含统一的数据标准和业务标准，业界成熟的开放标准（协议），和金三已有的开发及运维标准和规范。通过标准和规范的建立实现：

●信息共享和顺畅的信息交换；

●支持信息的高效、综合分析利用和决策分析；

●方便沟通理解，项目管控；

●需求、设计、程序、测试等技术成果共享和重复利用。

1.1.3.

2.4业界成熟的开放标准和协议