统计报表类应用需求分析浅谈
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
统计报表类应用需求分析浅谈
摘要:本文针对统计报表需求的特点,对分析该类需求的方法和过程进行梳理和总结,重点提出统计报表类需求分析面向的重点内容、分析过程包括的步骤,最终产生的结果,
关键字:统计报表需求分析分析内容分析步骤分析结果
需求分析是对用户需求理解、分析、确定的过程,通过分解和细化需求来形成合理的需求范围、各方的一致理解及可衡量的验收标准。良好的分析活动有助于避免或尽早剔除早期错误,从而提高软件生产率,降低开发成本,改进软件质量。本文针对统计报表应用的特点,对该类应用需求分析方法和过程进行了归纳与总结。
1.需求分析内容
统计报表应用以报表形式展现用户关注的统计信息,包括统计数据处理和统计信息展示两个主要部分,前者完成对原始数据的统计处理,后者实现对统计结果的报表呈现。围绕上述两个部分,在该类应用的需求分析过程中重点关注如下内容:
1、统计信息,应用中涉及的统计维度、统计指标、统计条件等;
2、统计频率,应用执行间隔和周期,如日统计、月统计、季统计等;
3、统计粒度,应用提供信息的明细程度,如细节数据、汇总数据等;
4、数据范围,与统计内容相关的数据源系统信息和数据时间范围,如cbps8系统产生的数据,时间范围跨2008年、2009年两个年度;
5、统计口径,维度标准和指标定义,后者包括业务描述和逻辑实现脚本两个组成部分;
6、报表样式,与信息展现有关的内容,包括报表表头和报表功能;
7、非系统数据,无法在数据源系统中直接识别获取的信息,或数据源系统不具备而需要用户定义维护的信息,如重点关注险种、大客
户、营销服务部等信息;
8、用户范围及权限,应用可被授权的用户范围和数据范围,如总部、省、地市用户,及不同级别用户可供访问的数据范围。
2.需求分析步骤
在进行统计报表需求分析中,除关注需求本身外,还需要综合考虑两方面因素:一、公司业务和数据源系统情况,用于确定满足需求的基础数据信息是否具备;二、可采用的报表实现技术,用于判断需求提出的数据细度和统计频度是否影响系统效率。具体需求分析过程包括如下主要步骤:
2.1 熟悉需求内容
2.1.1 梳理报表内容
1、整理需求中涉及的维度、指标信息。
1)维度方面,确定与需求有关的维度内容,及每个维度相关的粒度、层次、成员等信息;
2)指标方面,确定与需求有关的指标内容、指标间的计算关系、基础指标、衍生指标及衍生指标的计算公式。对于每个指标,了解相关的统计频度、可参照的统计标准、或新指标的统计要求。2、报表样式。
报表的样式包括:表名、表头、查询条件、数据显示单位、排序功能、下载打印功能、备注说明等。
3、报表间关系。
确定报表间存在的上钻和下钻层次关系。对于具有该类关系的报表,可将位于最顶层的报表作为访问其他报表的入口,从顶层报表逐层下钻进行访问。
2.1.2 了解权限范围
1、应用的访问用户范围。
从安全性角度而言,应用产生的统计信息一般仅对经过授权的用户开放,不同的用户具备不同的访问权限,需要了解需求的用户范围、用户级别、用户数量等。
2、用户的访问数据范围。
对于组织架构覆盖全国的公司而言,用户范围广、分类多,不同级别的用户可访问的数据范围存在差异,如总部用户可访问全国数据,省级用户仅可访问本省及辖下机构数据等。需要了解需求对不同用户访问数据的限制和要求。
2.1.3 确定需求干系人
干系人的确立除考虑直接需求方外,还需结合公司组织架构,确定潜在需求方。对于我公司而言,统计需求的干系人包括:
1、需求方,需求的提出者,对需求内容负责,参与需求分析、测试验收、系统推广使用等工作;
2、其他干系方,包括:
1)数据源系统方,源系统数据信息的解释方,对维度、指标取数来源和逻辑关系提供专家建议;
2)系统测试方,进行系统上线前的功能性能测试,并组织用户验收;3)系统运维方,提出系统部署、运维限制要求,并提供系统上线后的部署运维服务。
2.2 深入分析交流
2.2.1 确定维度、指标统计信息
1、进行数据探查,确定维度、指标数据来源、业务逻辑、统计脚本,包括:
1)维度数据探查。
a)确定取数来源,判断数据取自现有系统还是手工录入。对于存
在多个取数来源的情况,需要结合具体的应用要求选择适当的
数据信息;
b)统一代码标准,建立不同源系统维度代码与标准代码间的对照
关系;
c)发现异常数据,制定清洗处理规则;
d)构建维度层次,确定维度的分类和层次关系,合理的维度层次
关系将有助于OLAP引擎的预处理,提高报表的访问速度。2)指标口径探查。
a)请用户根据对指标的理解,形成业务逻辑描述,并提供指标的
统计时间范围;
b)确定取数来源,依据指标业务描述判断数据源系统是否具备基
础数据信息,以及数据在源系统的分布情况;
c)编写指标统计脚本,依据指标业务描述和源系统数据模型,设
计实现指标统计的SQL脚本。在此过程,一方面需要分析人员
对数据源系统的业务和系统有一定了解,另一方面需要源系统
人员给予技术支持,保障统计脚本设计质量;
d)反复验证修改,将统计结果与用户提供的经验数据进行比较,
不断分析和修正业务逻辑描述,并更新统计脚本,直至满足用
户对数据准确性的要求;
e)确定验收标准,以字典卡片形式(详见3.3)记录最终形成的
业务描述和统计脚本,并以此作为衡量统计结果准确性的验收
标准。
2、结合系统的部署架构,确定合理的统计粒度。
对于需求所需的细粒度数据仅在省公司部署而总部只有粗粒度数据的部署架构,总部报表不宜提供粒度过细的统计信息,因为涉及在总分公司间传输大量的细节数据,影响系统的稳定运行。对于该类需求需要控制。
3、结合系统的运行效率,确定合理的统计频度。
影响系统的实现效率主要包括两方面因素:一、实现逻辑的复杂度,复杂度越高则运行效率越低;二、统计涉及的数据量,数据量越大则运行效率越低。运行效率较低的应用不宜选择较短的统计周期,否则会对整套报表系统资源造成较大压力,影响其他报表应用。比如对于非累加性指标,如期末有效件数,统计时需要对截至当前的所有有效保单件数进行合计,数据量较大,一般统计周期选为按月统计,不建议按日统计。
2.2.2 确定需求的合理性
结合对维度、指标信息的分析,判断报表表样、功能的合理性,与用户确定合理的需求范围。
1、报表表样方面: