BI项目需求分析书模板.docx
- 文档编号:7251330
- 上传时间:2023-01-22
- 格式:DOCX
- 页数:23
- 大小:554.13KB
BI项目需求分析书模板.docx
《BI项目需求分析书模板.docx》由会员分享,可在线阅读,更多相关《BI项目需求分析书模板.docx(23页珍藏版)》请在冰豆网上搜索。
BI项目需求分析书模板
BI项目需求分析书-模板
一、前言
1.定义
这里的《某零售集团BI项目需求分析书》即软件工程中通常所提到的《软件需求规格说明》(SoftwareRequirementsSpecification),简称SRS。
具体标准参照了IEEE830-1998。
2.用途
软件工程初期的一般过程是,软件开发的计划,确定要实现的目标和进度等,然后就是《软件需求规格说明书》,该说明书必须要得到用户的审核、确认。
此后的开发过程,都是围绕着需求规格说明书做进一步地细化,直至开发出产品。
当然,测试计划中也要针对需求进行验证,看看是否满足了用户的要求。
二、BI项目二期建设目标
BI项目二期的建设目标是在一期试验性、应急式BI应用成功投入运行的基础上,结合某零售集团的当前业务运营管理需求与健康扩张(做大的同时,更需要做强)的战略,首次系统地设计与开发基于某零售集团各类关键基础运营(原始)数据的管理分析报表体系与相应的基础运营数据集中管理平台(以下称某零售集团信息仓库),从而使某零售集团的供应商管理、门店绩效管理、各业态商品品类业绩考核建立在可靠的业务数据基础上,使某零售集团的相关职能部门员工与管理者能够及时看到他们所关心的业务数据,从而为企业决策者正确决策提供准确、及时的依据,并使企业能更好地为供应商和顾客服务,进而提高企业的经营管理水平,提升企业整个供应链的竞争力。
本节将从总体上描述二期系统的功能目标,主要包括功能体系结构的说明、各模块之间关系的描述、基本系统界面形式的选择以及各个功能模块的设计目标。
本章所定义的内容,均为二期系统的总体特性,这些特性,将作为后面几节中所详细阐述的具体功能需求的基本参照。
1.系统的功能体系结构概述
二期系统将在两个层面上为某零售集团提供业务数据分析功能,即,日常业务报表与高度随机探索式业务信息展现(OLAP)。
在二期开发的同时,宏软将基于其长期积累的商业数据挖掘经验,为某零售集团的下一步深层次数据应用做一些准备与探索工作,但这个工作的系统展开将作为某零售集团BI三期的核心任务。
2.总体功能体系结构说明
二期系统的总体功能结构如图1所示:
1)日常业务报表
日常业务报表即那些在业务中使用比较频繁的、格式与内容固定的数据分析报表。
主要用以反映某零售集团日常经营活动中销售、库存、毛利率等三类主要因素对某零售集团业务指标的影响。
考虑到首次系统地设计业务模型分析,为了提高系统的使用率与节约软硬件资源,在此我们暂时集中精力先考虑这三种要素。
对每一类影响因素的日常业务报表均分为两个部分,即定制脱机报表、联机报表查询。
Ø定制脱机报表
即根据用户稳定的公共业务需求,系统自动生成,并可选择向特定用户或用户组主动发送的可用脱机方式浏览的定制报表,它可以EXCEL或其它大家习惯的文件形式独立于系统存在。
例如门店业务方面的中类销售报表,分为日、周、月报表三种格式。
比如:
中类销售报表(按中类汇总)
所选门店各中类的销售额、数量、毛利及同环比日报、周报、月报
Ø联机报表查询
即根据用户大量、经常性的业务查询需要,由系统对历史数据进行预先处理,处理结果在某零售集团信息仓库中以数据表的形式存在,以方便用户通过联机方式随时按条件进行查询得到,例如门店业务方面的大类销售连续性查询,用户界面上呈现的可以是柱方图或曲线图等多种信息表现方式。
比如:
销售连续性查询(按大类)
所选门店所选大类在所选时段内每日的销售金额
2)业务探索式分析(OLAP)
业务探索式分析功能即通常所说的OLAP(联机分析处理)功能,这是对日常业务报表功能的扩充,主要作用是给某零售集团业务分析人员一个从各个不同角度与因素组合了解业务现状的一个高效、易用的业务分析平台。
这样的需求是现有的一期系统所不能够满足的。
这个功能还可以减少大量的非频繁使用的定制性报表需求,有效地兼顾了大众化需求与少量深层次需求之间的矛盾,降低了开发工作量与系统资源消耗。
在一般的管理信息系统中,决策数据的不一致性突出,多个信息提供者对信息都不具备严格的定义,不同的业务系统对同一信息数据的理解和定义不同,甚至许多相同命名的数据所指代的业务信息并不相同。
这些问题给基于数据的业务分析与决策支持带来了巨大的困难。
因此在某零售集团二期系统开发中,为有效、可持续地实现上述业务探索式分析(OLAP)功能与其它非定制静态报表,首先必须对相关关键业务基础数据做抽取、清洗和整合(这些数据准备工作简称ETL)的ODS信息仓库建设工作,然后再根据具体业务探索式分析(OLAP)的应用需求,再次做更高层次的数据抽取、改造(含生成新的衍生变量)与整合工作,所以对整个BI系统而言共有两次ETL过程,在工作量上要予以充分评估。
3)KPI指标分析报告
作为对上述两种报表体系的一种应用,我们针对相关业务部门提出了一些基本的KPI指标,这些指标是基于某零售集团信息仓库的数学挖掘模型的示范性应用,作为抛砖引玉,为在下一期项目中建立更系统的KPI指标体系做好铺垫与引导工作。
考虑到系统的实用性,我们遵守的一个最重要原则是KPI指标个数绝对不能超过5个,否则信息过多,不利于决策者的快速消化与应用,就失去KPI的宗旨了。
KPI结果将在系统支持的前提下以用户方便的形式呈现。
表1二期系统功能模块一览
功能名称
解决的问题
主要输出结果
主要方法
备注
日常业务报表
业务现状况以及外部因素对业务指标的实际影响状况
分析报表
分析图形
借助于“分析框架”,对报表数据进行计算合并处理
包括:
定制脱机报表
联机报表查询
高度随机探索式业务信息展现(OLAP)
对业务数据多角度、多因素、更随机的多角度探索式分析
可供旋转、切片、钻取等处理的多维查询立方体及多维查询图表
基于相关某零售集团信息仓库与面向相关主题的数据集市生成业务探索式分析(OLAP)报表库或称立方体
KPI分析
指数化与简约化管理目标,量化关键因素对企业绩效的影响状况
KPI分析报告
借助于“分析框架”,对报表数据进行计算处理及统计建模
3.系统流程
1)系统总体流程
图2二期系统总体流程图
图2所显示的是二期系统的总体系统流程图。
系统的数据来源总体上可以分为某零售集团总部主档(即基础数据)数据库和A业务系统等外部业务数据源。
总部主档库中所保存的是某零售集团方面企业基础信息包括供应商主档、商品主档、门店主档、公司组织机构、业务人员主档等数据,A业务系统等外部业务数据源主要提供各业态、各销售单位等前一天的按单品聚合的明细业务数据包括销售、退货等数据内容。
对某零售集团业务部门提供的业务规则如“返利计算规则”等,得到后形成存储于系统中的“业务规则库”。
所谓“业务规则库”,就是进行业务分析处理时所需要的计算公式以及合并、抵消原则。
对总部主档库及A业务系统业务数据源进行人工的“关联关系分析”处理之后得到“关联关系库”,即各种外部因素与某零售集团业务指标之间的关联情况,包括相关性的判定以及关联函数形式,“关联关系库”是业务模型分析的基本框架。
二期系统某零售集团信息仓库数据存储部分包括两个部分即ODS库和OLAP库部分。
总部主档库及A业务系统业务源数据经过ETL(数据的提取、转换和装载)处理之后进入二期系统某零售集团信息仓库的ODS库部分。
该部分是二期系统数据存储的主体,其中所有的业务信息再经过第二次ETL的清洗和重新整合后,按照某零售集团信息仓库查询及模型分析所需要的多维形式存储即二期系统某零售集团信息仓库的OLAP库部分(即:
基于应用主题的数据集市与相应的Cubes)。
某零售集团BI二期系统的各种应用功能,都需要从某零售集团信息仓库中提取数据以作处理。
系统投入运行后,某零售集团信息仓库将在ETL工具的支持下定期进行动态更新。
业务规则库、关联关系库和某零售集团信息仓库构成了二期系统中所保存的主体数据内容,同时也是二期系统三部分功能的完整支撑平台。
2)日常业务报表处理流程
在日常业务报表处理流程中,系统首先根据业务规则库和关联关系库所提供的信息构建模型代数形式例如“返利计算规则”、“某零售集团总部商品品类历史主档与在用商品品类主档关联关系”等,随后从某零售集团信息仓库中提取数据,计算求出模型的各个参数,得到模型的具体形式,最后根据某零售集团信息仓库数据,以及用户所输入的查询参数,得到模型分析的结果。
模型分析结果以报表和图形两种基本形式展现(图3)。
图3日常业务报表处理基本流程
3)业务探索式分析(OLAP)处理流程
在业务探索式分析(OLAP)功能中,系统从某零售集团信息仓库中提取数据,根据查询的需要(选择主题、维度,输入维度参数,旋转、钻取指令等)对之进行组织,将结果以多维立方体以及多维分析图的形式展现出来(图4)
图4业务探索式分析(OLAP)处理基本流程
4.数据说明
在本节当中,我们将进一步对上述流程中所使用的各项数据内容进行描述。
1)总体数据说明
从图2的总体流程说明可以看出,某零售集团BI二期系统中的主要数据内容包括总部主档库、A业务系统与其它业务数据源、业务规则库、关联关系库、某零售集团信息仓库、模型分析结果、业务探索式分析(OLAP)查询结果及将在未来下一期BI项目中实现的数据挖掘应用八个大块(表2)。
表2二期系统总体数据说明
名称
内容
主要来源
保存方式
主档
某零售集团方面企业基础信息应包括供应商主档、商品主档、进价主档、门店主档等数据。
总部主档库
某零售集团信息仓库ODS(应包括历史主档、目前在用主档)
A业务系统等外部业务数据源
1,各销售单位及中仓进货清单
2,各销售单位销售清单
3,各销售单位及中仓库存清单
4,各销售单位要货清单
5,生鲜及中仓发货清单
6,各销售单位进货凭证
7,会员销售
8,单品销售
9,客流与折扣
10,单品毛利表
11,日结单
12,退、换货数据
13,理赔数据
14,其他描述性说明
第一次ETL
某零售集团信息仓库ODS
业务规则库
1,业务报表合并规则(板块内部合并和板块之间合并)
2,业务指标之间运算规则
3,KPI指标运算规则
4,其他业务规则
5,动态分析依据的假设条件
6,国家相关法律政策(如税率等)说明
计算机程序辅助下的手工整理
某零售集团信息仓库ODS
关联关系库
1,总部主档系统基础数据与A业务系统等外部业务数据源之间基础数据关联关系。
2,总部历史主档与目前使用主档之间数据关联关系。
3,某零售集团和供应商之间系统数据交换EDI标准与总部目前使用主档之间数据关联关系
计算机程序辅助下的手工整理
某零售集团信息仓库ODS
多维信息仓库
经过整合处理并以面向主题的多维形式组织的业务数据。
第二次ETL
多维信息仓库OLAP
日常业务报表
1,报表
2,报告
3,图形展示(交互式直方图、折线图等)
模型计算、分析处理
部分内容保存于某零售集团信息仓库ODS
业务探索式分析(OLAP)查询结果集
根据查询需要从某零售集团信息仓库中提取的多维数据
信息仓库,业务探索式分析(OLAP)处理
信息仓库的汇总表、物化视图
数据挖掘分析结果
数据挖掘分析得到的规律集合
数据挖掘处理
某零售集团信息仓库ODS
2)系统数据来源详细说明
详见需求文档《二期系统业务数据源详细说明》,待提交。
3)日常业务报表分析处理数据说明
表4模型分析处理数据说明
名称
内容
来源
保存形式
关联关系库
影响因素与指标之间的关联关系体系
关联关系分析
某零售集团信息仓库
业务规则库
业务计算分析所使用的公式和遵循的逻辑规则
业务规则分析
某零售集团信息仓库
形式模型库
业务模型的代数形式
模型形式构建
某零售集团信息仓库
多维信息仓库
经过整合处理并以面向主题的多维形式组织的业务数据。
第二次ETL
多维信息仓库
输入参数
用户输入的业务模型分析参数
用户输入
不保存
模型结果数据集
根据业务模型和输入参数计算得到的结果数据。
计算分析
不保存
日常业务报表
根据业务模型结果数据集构造的报表
展现处理
不保存
日常业务分析图
根据业务模型结果数据集构造的图形输出
展现处理
不保存
4)业务探索式分析OLAP处理数据说明
表5OLAP分析处理数据说明
名称
内容
来源
保存形式
某零售集团信息仓库
经过整合处理并以面向主题的多维形式组织的业务数据。
第二次ETL
多维信息仓库
主题、维度选择
需要查询的主题、维度内容
用户输入
不保存
OLAP结果数据集
根据主题、维度选择,从信息仓库中提取的数据块
信息仓库查询处理
不长久保存(缓存于信息仓库视图中)
OLAP查询报表
多维查询表格
展现处理
不保存
OLAP多维图形
多维查询图形
展现处理
不保存
5.系统界面基本形式
某零售集团BI项目二期系统将采用性能优越、易于扩展、易于维护的三层结构,即数据库服务器-应用服务器-客户端浏览器的结构。
这是一种基于WEB浏览器访问的系统结构,因此也可以称为B/S(浏览器/服务器)结构。
这种结构的优越之处在于:
首先,客户端无需安装任何软件,对系统的所有访问都可以通过Web浏览器来进行;其次,使用独立的应用服务器,使得软件逻辑的扩展变得十分容易,并且可以方便地加入负载均衡、容错等设计;再次,客户端的访问范围也可以很容易地根据授权得到扩展。
在这种形式下,所有对系统的访问都将通过WEB浏览器界面来实现。
经过数年来Internet的大发展,WEB浏览器已经深入人心。
因而对这一基本界面我们无需多言。
需要强调的是,原一期系统中选用的数据可视化工具Brio产品仅支持相对较为呆板的报表显示界面,对于探索式查询、互动分析与丰富的图形表现等需求并不能提供足够的支持。
因此,在二期系统中,我们将选用功能更全面、成熟的CognosBI产品,以满足用户对这类数据分析与查询方式的需要。
三、某零售集团BI系统运行环境
1.软件环境
1)软件环境配置图
图5软件环境配置图
2)软件环境配置说明
本系统的软件配置由五层组成:
Ø客户端软件
用户大部分应用通过浏览器(IE6.0或Netscape5.0)来实现联机查询,另外系统也可根据用户个性化需求,自动生成定制脱机报表及电子邮件Email,主动发送给用户通过Word、Excel及Outlook等常用办公软件采用脱机方式阅读。
ØBI应用
主要基于底层的中间件软件及一些独立服务软件,用以实现对数据的抽取、转换及加载,根据不同的应用主题,对某零售集团信息仓库进行联机报表查询、预处理自动生成定制脱机报表,多维数据仓库创建、管理及维护,图形报表的发布和在线服务等大部分的应用内容。
Ø中间件
主要为上层的BI应用提供一整套能够采集、存储、分析、报告数据并提供数据访问能力的组件和服务,解释和执行从这些应用软件发送的处理请求。
Ø数据库管理系统
DB2数据库是针对大型企业应用提供的数据库管理系统,为某零售集团这样一个已经很大并仍在快速发展期的中国零售业旗舰的,数据仓库建设和数据管理提供了一整套成熟的软件组件和服务支持,可以有效地适应未来系统扩展的需求,从而避免在业务发展很大时被迫更换数据库平台与开发工具,仅此一项就可以为企业降低不可估量的成本与风险。
Ø操作系统
作为最底层的系统,为所有的软件应用提供支持平台,在本项目中,根据企业应用需求及与硬件更好的兼容性采用了IBMAIX5.2。
2.网络与服务器环境
1)网络与服务器配置图
图6某零售集团BI项目二期系统网络架构
2)网络与服务器配置说明
某零售集团BI系统三台服务器都安装并放置在某零售集团总部机房,通过数据交换平台与总部主档库、各分支机构(包括区域、业态等)的业务系统(包括A业务、B业务等业务数据源)以及外部系统如供应商系统等相联。
另外,系统还设有Web应用服务器。
某零售集团总部、各分支机构等最终用户可分别通过浏览器访问某零售集团BI系统的应用。
Ø某零售集团信息仓库ODS服务器配置
表5IBMPSeries650配置
基本参数
处理器类型
POWER4+
处理器主频
1.2GHz
处理器缓存
每个1.2GHz处理器卡可配8MB
处理器个数
4
最大处理器个数
8
内存类型
ChipkillECC
内存容量
8GB
最大内存容量
64GB
存储设备
硬盘类型
SCSI
硬盘容量
2×36.4GB +6×146GB
软驱
3.5"1.44MB
光驱
CD-ROM
网络
网卡类型/数量
10/100控制器
接口与扩展槽
I/O端口
4个串口,2个端口连接p系列硬件管理控制台、键盘、鼠标
扩展槽个数
最多48个PCI热插/任意交换适配器(40个64位PCI-X;8个64位PCI),
电力特征
电源类型
冗余热插拔电源
是否冗余
是
电源个数
2N+1
软件系统
操作系统
AIX5L版本5.2
管理软件
HighAvailabilityClusterMultiprocessing(HACMP)
环境要求
工作温度
5–35(℃)
工作湿度
8%-80%
Ø某零售集团信息仓库OLAP服务器配置
表6IBMXSeries255配置
基本参数
处理器类型
IntelXeonMPProcessor
处理器主频
2.20GHz
处理器缓存
每个处理器配512KB二级缓存
处理器个数
2
最大处理器个数
4
内存类型
PC1600DDRSDRAM
内存容量
2GB
最大内存容量
24GB
存储设备
硬盘类型
Ultra320SCSI
硬盘容量
9×36.4GB+12×72GB
软驱
3.5"1.44MB
光驱
CD-ROM
网络
网卡类型/数量
10/100控制器
接口与扩展槽
I/O端口
4个串口,2个端口连接p系列硬件管理控制台、键盘、鼠标
插槽x托架总数(空闲):
7(7)x16(12)
电力特征
电源供应类型
110-220voltHotSwapRedundant2Std.
电源
370W
热辐射
1000W
声音辐射
6.5Bels
软件系统
操作系统
MicrosoftWindows2000AdvancedServer
环境要求
工作温度
5–35(℃)
工作湿度
8%-80%
Ø某零售集团信息仓库Web应用服务器配置
表7IBMXSeries235配置
基本参数
处理器类型
IntelXeonMPProcessor
处理器主频
2.80GHz
处理器缓存
每个处理器配512KB二级缓存
处理器个数
2
最大处理器个数
2
内存类型
PC1600DDRSDRAM
内存容量
1GB
最大内存容量
12GB
存储设备
硬盘类型
Ultra320SCSI
标准硬盘容量
6×36.4GB
软驱
3.5"1.44MB
光驱
CD-ROM
网络
网卡类型/数量
10/100控制器
接口与扩展槽
I/O端口
4个串口,2个端口连接p系列硬件管理控制台、键盘、鼠标
插槽x托架总数(空闲):
7(7)x16(12)
电力特征
电源供应类型
AutoRestart
电源
560W
热辐射
121W
声音辐射
65dB
软件系统
操作系统
MicrosoftWindows2000AdvancedServer
环境要求
工作温度
5–35(℃)
工作湿度
8%-80%
四、某零售集团BI项目需求分析的任务概述
根据项目建设目标以及6月24日项目组周例会精神,某零售集团BI项目二期系统需求分析任务将包括四个方面的任务:
1.对一期需求业务的重新整理、归类、筛选和补充
二期系统与一期系统相比,在硬件平台、操作系统、数据库软件以及开发工具方面都将有重大改变,因此与其说是一期系统的迁移,不如说是在二期系统全新架构下对一期需求业务内容的一种包容,相当于重新开发,并且是在新的软、硬件开发环境下进行的。
在二期系统开发中,我们将对一期需求业务进行重新整理、归类、筛选和补充。
例如:
对于一期系统中那些适合多维分析的业务,我们将采用OLAP技术进行优化,对一期中使用效果不好的报表将予以改进甚至废弃以提高系统利用率。
2.跨业态商流、物流分析
跨业态商流、物流分析的主要目标是针对定牌、联合采购以及生鲜等跨业态销售的商品进行专项主题统计分析,为相关部门进行业务分析、绩效考核与管理决策提供数据依据。
其中包括给出自动计算定牌商品占所在门店或经营单位销售总额的比例,包括给出简约的几个KPI指标来衡量联合采购的效果。
同时保留一期系统中对生鲜业态的主题分析。
3.决策支持系统
将开发专门针对公司领导的综合查询和决策分析系统,核心目标是:
通过信息深度加工与度身定做的信息展现与传递模式,提高决策者对信息的利用效率与利用度,提高决策者应用信息的积极性与应用效果。
该系统将针对不同领导提供个性化、高度简约的静态综合报表、动态KPI指数与业务宏观发展趋势等决策支持服务。
这样有利于解决一个制约公司管理水平的最大瓶颈:
公司最需要量化信息并做到“心中有数”的决策型管理者,往往没有时间消化信息,因为目前运营基础信息的积累速度太快,而传统的信息加工与展现方式太繁杂、消耗时间了,往往给出的是零碎的信息,而不是集约化的定量的概括性、总结式信息。
在与相关领导的需求调查后提供有关该系统的详细设计文档。
。
4.数据交换平台
某零售集团数据交换平台系统建设的目标是设计一个完整、实用、适合连锁零售业海量数据传输、交换及处理的平台。
根据某零售集团企业特点,该交换平台应是一个基于不同应用标准、组件化、架构良好、具有很好扩展性的多层的开放的软件体系。
为了满足某零售集团各业务系统以及与外部系统间数据传输需要,某零售集团BI项目二期系统建设中将根据某零售集团企业内部及外部系统应用的不同特点,确定数据交换所应采取的不同技术手段。
如企业与供应商之间的数据交换具有数据量相对较小,实时性、安全性要求相对较高等特点,可采用XML数据集成方式进行数据交换。
而BI系统与各业务系统间的海量数据交换用XML方式就显然不能适用了。
因此必须针对公司的各个职能部门、各个业态、各个地区的计算机系统、数据库系统、数据接口、业务流程、业务规则、数据分析需求进行全
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- BI 项目 需求 分析 模板
![提示](https://static.bdocx.com/images/bang_tan.gif)