文档介绍：2 / 11
统计报表类应用需求分析浅谈
摘要:本文针对统计报表需求的特点,对分析该类需求的方法和过程进行梳理和总结,重点提出统计报表类需求分析面向的重点内容、分析过程包括的步骤,最终产生的结果,
关键字:统计报表 需求分析 源系统的分布情况;
编写指标统计脚本,依据指标业务描述和源系统数据模型,设计实现指标统计的SQL脚本。在此过程,一方面需要分析人员对数据源系统的业务和系统有一定了解，另一方面需要源系统人员给予技术支持,保障统计脚本设计质量;
反复验证修改,将统计结果与用户提供的经验数据进行比较,不断分析和修正业务逻辑描述，并更新统计脚本,直至满足用户对数据准确性的要求;
确定验收标准,以字典卡片形式（详见3．3）记录最终形成的业务描述和统计脚本,并以此作为衡量统计结果准确性的验收标准。
２、结合系统的部署架构，确定合理的统计粒度。
对于需求所需的细粒度数据仅在省公司部署而总部只有粗粒度数据的部署架构,总部报表不宜提供粒度过细的统计信息,因为涉及在总分公司间传输大量的细节数据,影响系统的稳定运行。对于该类需求需要控制。
3、结合系统的运行效率,确定合理的统计频度。
影响系统的实现效率主要包括两方面因素:一、实现逻辑的复杂度，复杂度越高则运行效率越低;二、统计涉及的数据量,数据量越大则运行效率越低。运行效率较低的应用不宜选择较短的统计周期,否则会对整套报表系统资源造成较大压力，影响其他报表应用。比如对于非累加性指标，如期末有效件数,统计时需要对截至当前的所有有效保单件数进行合计，数据量较大,一般统计周期选为按月统计,不建议按日统计。
确定需求的合理性
结合对维度、指标信息的分析，判断报表表样、功能的合理性,与用户确定合理的需求范围。
5 / 11
1、报表表样方面:
基于对指标是否具备足够数据信息支持的分析,确定可实现的指标范围,结合该信息从报表中去除不能实现的指标,对需求进行适当裁剪;
基于对指标粒度和统计频率的分析,对于同一报表中存在不同统计频率或统计粒度指标的情况,提出表样修改建议，避免规则不同的指标出现在同一张报表上,引起报表内容的混乱；
对于一张报表存在多个维度组合的情况,若将所有维度组合均以报表间链接跳转的方式实现，则报表间关系较为复杂，不便于用户快速查询定位信息。建议在报表中仅对重点关注维度提供报表链接方式进行逐层下钻访问,其他维度作为报表的统计条件供用户筛选组合使用。
2、报表功能方面:
根据对维度数据是否需要手工录入维护的判断，确定报表系统中是否需要提供数据采集功能;
对于涉及大量明细数据查询的报表,建议尽可能避免在总部报表中展示，可在省分公司端形成数据文件包供用户下载分发使用，避免总部因获取大量细节数据而引起的系统不稳定问题;
确定每张报表提供的操作功能,如查询条件设置、数据排序、数据下钻上钻、数据导出、数据下载等。
２． 确定用户范围
分析访问用户范围的合理性，与用户沟通确定用户范围和权限。一般总部单点部署的报表系统可支撑总、省、市用户，但对于县级用户范围,由于用户量过大，对系统造成压力,因此要控制县级用户范围，可采用增加数据下载功能,由地市级用户下载下辖各县数据后通过邮件发送给相关人员。
２．2．４ 提出非功能需求
基于对前述内容的分析,结合报表需求的复杂度、数据量、统计频度、访问用户量等情况,确定报表性能方面的报表响应效率、后台数据准备效率指标要求,以及运行环境方面的设备资源要求。
7 / 11
分析结果评审
在形成需求分析结果后,需要组织需求干系人参加评审会议，以保证各方对分析结果达成共识，使后期的开发工作具有正确的参考依据。评审的主要内容包括:
１、业务需求分析结果，请需求方就需求范围、报表表样及功能、维度指标业务逻辑描述等分析结果进行确认，以保证双方对需求的理解保持一致;
２、维度指标实现分析结果,请数据源系统人员结合对源系统的专业了解,对照需求分析产生的维度指标业务逻辑描述，判断需求分析提出的信息取数来源和实现逻辑是否合理,以确保维度指标的脚本实现与业务描述保持一致。
３、运行环境需求,由后期系统上线的运维方进行评价和认可，确保系统上线的资源支持。
经过评审的需求分析结果，将作为后期系统验收的依据。
表样原型
采用Excｅl工具制作表样原型。Excel提供的单元格合并功能和边框设置功能有助于清晰展示报表的页面布局、操作功能、报表表样等；其ｓhｅet链接功能有助于清晰表达报表间的访问关系和访问层次。使用该工具进行报表原型设计即方便又快捷。具体示例详见下图。
7 / 11
3．２ 需求规格说明书
需求规格说明书针对本文第1部分中提出的各项需求内容