摘要：本文针对统计报表需求的特点，对分析该类需求的方法和过程进行梳理和总结，重点提出统计报表类需求分析面向的重点内容、分析过程包括的步骤，最终产生的结果，
关键字：统计报表 需求分析 分析内容 分析步骤 分析结果
需求分析是对用户需求理解、分析、确定的过程，通过分解和细化需求来形成合理的需求范围、各方的一致理解及可衡量的验收标准。良好的分析活动有助于防止或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改良软件质量。本文针对统计报表应用的特点，对该类应用需求分析方法和过程进行了归纳与总结。
1．需求分析内容
统计报表应用以报表形式展现用户关注的统计信息，包括统计数据处理和统计信息展示两个主要部分，前者完成对原始数据的统计处理，后者实现对统计结果的报表呈现。围绕上述两个部分，在该类应用的需求分析过程中重点关注如下内容：
1、 统计信息，应用中涉及的统计维度、统计指标、统计条件等； 2、 统计频率，应用执行间隔和周期，如日统计、月统计、季统计等； 3、 统计粒度，应用提供信息的明细程度，如细节数据、汇总数据等； 4、 数据范围，与统计内容相关的数据源系统信息和数据时间范围，如cbps8系统产生的数据，时间范围跨2008年、2009年两个年度； 5、 统计口径，维度标准和指标定义，后者包括业务描述和逻辑实现脚本两个组成部分；
6、 报表样式，与信息展现有关的内容，包括报表表头和报表功能； 7、 非系统数据，无法在数据源系统中直接识别获取的信息，或数据源系统不具备而需要用户定义维护的信息，如重点关注险种、大客
户、营销服务部等信息；
8、 用户范围及权限，应用可被授权的用户范围和数据范围，如总部、省、地市用户，及不同级别用户可供访问的数据范围。
2．需求分析步骤
在进行统计报表需求分析中，除关注需求本身外，还需要综合考虑两方面因素：一、公司业务和数据源系统情况，用于确定满足需求的基础数据信息是否具备；二、可采用的报表实现技术，用于判断需求提出的数据细度和统计频度是否影响系统效率。具体需求分析过程包括如下主要步骤：
熟悉需求内容
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、报表表样方面：
1） 基于对指标是否具备足够数据信息支持的分析，确定可实现的
指标范围，结合该信息从报表中去除不能实现的指标，对需求进行适当裁剪；
2） 基于对指标粒度和统计频率的分析，对于同一报表中存在不同
统计频率或统计粒度指标的情况，提出表样修改建议，防止规则不同的指标出现在同一张报表上，引起报表内容的混乱； 3） 对于一张报表存在多个维度组合的情况，假设将所有维度组合
均以报表间链接跳转的方式实现，则报表间关系较为复杂，不便于用户快速查询定位信息。建议在报表中仅对重点关注维度提供报表链接方式进行逐层下钻访问，其他维度作为报表的统计条件供用户筛选组合使用。 2、报表功能方面：
1） 根据对维度数据是否需要手工录入维护的判断，确定报表系统
中是否需要提供数据采集功能；
2） 对于涉及大量明细数据查询的报表，建议尽可能防止在总部报
表中展示，可在省分公司端形成数据文件包供用户下载分发使用，防止总部因获取大量细节数据而引起的系统不稳定问题； 3） 确定每张报表提供的操作功能，如查询条件设置、数据排序、
数据下钻上钻、数据导出、数据下载等。 2.2.3 确定用户范围
分析访问用户范围的合理性，与用户沟通确定用户范围和权限。一般总部单点部署的报表系统可支撑总、省、市用户，但对于县级用户范围，由于用户量过大，对系统造成压力，因此要控制县级用户范围，可采用增加数据下载功能，由地市级用户下载下辖各县数据后通过邮件发送给相关人员。 2.2.4 提出非功能需求
基于对前述内容的分析，结合报表需求的复杂度、数据量、统计频度、访问用户量等情况，确定报表性能方面的报表响应效率、后台数据准备效率指标要求，以及运行环境方面的设备资源要求。
2.3 分析结果评审
在形成需求分析结果后，需要组织需求干系人参加评审会议，以保证各方对分析结果达成共识，使后期的开发工作具有正确的参考依据。评审的主要内容包括：
1、业务需求分析结果，请需求方就需求范围、报表表样及功能、维度指标业务逻辑描述等分析结果进行确认，以保证双方对需求的理解保持一致；
2、维度指标实现分析结果，请数据源系统人员结合对源系统的专业了解，对照需求分析产生的维度指标业务逻辑描述，判断需求分析提出的信息取数来源和实现逻辑是否合理，以确保维度指标的脚本实现与业务描述保持一致。
3、运行环境需求，由后期系统上线的运维方进行评价和认可，确保系统上线的资源支持。
经过评审的需求分析结果，将作为后期系统验收的依据。
3．需求分析结果
3.1 表样原型
采用Excel工具制作表样原型。Excel提供的单元格合并功能和边框设置功能有助于清晰展示报表的页面布局、操作功能、报表表样等；其sheet链接功能有助于清晰表达报表间的访问关系和访问层
次。使用该工具进行报表原型设计即方便又快捷。具体例如详见下列图。
3.2 需求规格说明书
需求规格说明书针对本文第1部分中提出的各项需求内容，对需求分析结果进行汇总和整理，形成最终可实现需求的业务描述和技术说明，并与用户和各相关干系人达成一致意见，为开发过程和验收结项提供重要依据。
统计报表类应用的需求规格说明书一般包括以下几部分内容：需求背景；需求综述〔如系统功能、数据范围，用户权限、部署情况等〕；维度指标统计口径〔采用字典卡片形式，详见3.3部分〕；报表要求〔逐一描述说明每张报表需求内容，如报表名称、报表间层次关系、统计频度、粒度、筛选条件、数据单位、下载功能、访问响应时间等〕；设计约束〔如软件环境、遵循的开发标准等〕；运行环境约束〔如硬件环境、资源需求等〕。
3.3 维度指标字典卡片
字典卡片以卡片形式记录需求分析形成的维度指标业务描述和逻辑实现脚本，便于记录详细信息及再次查看使用。具体内容形式详见下面各表实例。 维度卡片形式如下： 需求分析人员填写信息 填写人 业务组 类型 名称 定义 表示 取值范围 取值含义 代码 维度 险种product 〔1〕按照保监会的销售渠道的划分标准，分4级。 〔2〕公司内部没有明确的划分标准，参考保监会分类。目前用到的包括渠道、个险。 〔1〕行业监管机构对机构的划分，满足行业监管需要。 〔2〕公司内部管理需要 〔1〕保监会的机构分为4级。 〔2〕业务需求涉及的属性包括： 1〕销售渠道：参考销售渠道维度 2〕长、短险标志：寿险与长期健康险归为长险，短期健康险与意外险归为短填写日期： 2008年05月07日 险。 3〕投资、风险标志：标识是投资型险种，还是风险型险种。 4〕业务系统中集团与股份有重复的险种代码。 5〕财务的长短险标志、财务的险种分类属性 维度属性 数据流来源 备注 原始维度 业务库 遗留问题： 〔1〕需要保留哪些维度属性的历史。保监会一级分类代码。 技术人员填写信息 填写人 名称 CBPS7 CBPS8 健康及意外险 年金 万能 AMIS 备注 技术人员 险种 险种码表： insur_policies/s_insur_pol 险种码表：product库的policy 险种码表：product库的policy 险种码表：t_prd 险种码表：t_prd 各系统的险种代码唯一。总公司维护pol_attrib 填写日期 2008年05月07日
指标卡片形式如下： 需求分析人员填写信息 填写人 类型 名称 定义 表示 取值含义 业务组 指标 保费收入〔权责发生制〕 公司直接承保业务所取得的保费收入 n..16,n2 1、新单首期保费按照保单生效日和实收日期确认保费； 2、非寿险业务〔短期健康险、短期意外险，下同〕的月缴、季缴、半年缴保单的保费需要在合同成立日确定全部保费，即短期险首期保费按照保单生效日期和实收日期大者确认保费，所有续期保费按照保单生效日一次性确认保费； 3、附加险续保或者中途增加附加险按新单首期确认保费收入； 4、寿险或长期健康险业务续期保费按照应收日期和产生应收日期大者确认保费； 5、年金业务续期保费按照资金到帐日确认保费； 6、寿险业务保全引起的保费增减变化，按照应收付日期和产生应收付日期的大者确认保费； 填写日期： 2008年7月10日 7、非寿险期交业务保全产生的保费增减变化，按照应收付日期和产生应收付日期的大者确认保费；非寿险趸交〔非期交〕业务保全产生的保费增减变化，按照实收付日期和应收付日期的大者确认保费； 8、寿险清算产生的保费增减变化，按照清算日期确认保费收入； 9、撤单退保费按照应付日期和产生应付日期的大者确认保费； 10、部分基金险拟不再作为保费核算，涉及险种有：国寿团体补充医疗保险〔基金型〕，险种代码YF4；国寿康瑞团体补充医疗保险〔账户管理型〕险种代码YF7、YF7A； 相关协议 指标属性 指标特点 数据流来源 数据流去向 计算公式 计算频率 计量单位 考察时间 保单 基础指标 涉及以下业务系统：cbps7版、cbps8版、健康及意外险、团体年金、统括年金、投连万能。 财务部、个险部、团险部、中介部 月 元 财务核算日期
技术人员填写信息 填写人 名称 加工数据源 CBPS7 系统 CBPS8系统 短险系统 年金系统 万能系统 技术人员 CBPS7\\CBPS8\\短险系统\\年金系统\\万能系统 基于CBPS7系统的实现脚本逻辑 基于CBPS8系统的实现脚本逻辑 基于短险系统的实现脚本逻辑 基于年金系统的实现脚本逻辑 基于万能系统的实现脚本逻辑 填写日期 2008年7月10日
因篇幅问题不能全部显示，请点此查看更多更全内容