苏ICP备112451047180号-6
投递平台业务需求分析
需求分析是项目开发的第一个阶段，根据项目的具体情况选用合适的需求分析方式，是需求分析能否能够顺利推进，以及所得结果是否能够支撑原先设想开发模型的先决条件，在这一阶段，我们需要对以下几个问题进行确认：
1.投递平台需要服务于哪些业务部门，需要完成哪些具体功能？
2.投递平台的最终用户是谁，用户的操作权限和访问方式如何分配？
3.业务部门对平台性能有哪些要求？
2．1 需求分析的方式
通过对比常用的需求分析方法的优劣性和运用场景需求。按照先进行场景分析，再进行需求分析方式选取的原则，首先对项目的现状进行分析如下：[2]
项目的提出方是函件局、报刊发行局、分销物流局相关领导，计划通过类似的信息化模式完成各自的旧业务流程改造和新业务开展工作。具体系统用户是相关专业局各个层级的业务人员，由于项目的提出者与主要用户并非同一人群，因此必然要选取一种能够在管理层、用户层、技术层三方之间能够达成一致的需求分析方式。根据项目的这一特点，我们采用了传统的结构化分析方法，在需求分析阶段并不要求精确的定义业务流程细节，在功能上保留一定的宽裕度，将具体细节的确认推后至系统的设计阶段。与管理层明确项目的功能要求和实现效果要求，与业务人员明确新流程、新业务的具体实施步骤，并在内部分析项目的技术可行性，是这一阶段的主要工作内容。
由于本项目得到足够的管理层支持，项目的跨部门协调工作就变得相对简单。针对函件局的需求，采用了实地跟班操作的调研方式，技术人员被抽调到函件局，在商函部、账单部、名址中心、投递部四个部门对现有业务流程进行全面的跟踪和考察；由于报刊业务与函件业务存在相当一部分重复需求，并考虑到技术队伍中有报刊业务专家，对于报刊发行局的业务需求调研，主要采用集中讨论的方式着重对报刊发行的业务特色进行分析；物流访销业务是新的业务需求，业务本身尚未发展成型，因此缺少固定的业务模式，后期需求变更的风险性较为突出
2．2 建设目标与建设原则
2．2．1 建设目标
投递平台的建设目标是解决当前投递环节中较为突出的邮件妥投反馈不及时、名址信息维护中出现名址信息更新滞后、后台录入人员工作负担重、投递和名址脱节问题，使邮政投递最后一公里的信息化水平达到行业领先。同时，利用手机终端实现投递员访问村邮站进行订单数据信息收集的需求，丰富了投递员的业务种类，提高了投递员收入，促进邮政多个专业协同发展。
投递平台以信息化手段服务于投递队伍转型改革，以段道+投递员+业务绩效为核心的全面量化管理，实现投递环节资源和邮政内部专业资源的有效整合，全面提升投递队伍素质和服务能力水平，促进邮政综合社会服务平台建设。能够为企业提供投递员实时作业监控，投递信息及时反馈、名址信息实时维护、产品订货、广告宣传、培训等功能，加快实现投递员向客户经理的转变、提升其社会渠道管理能力。
系统实现功能目标步骤分解如下：
1、实现给据邮件的投递反馈、党报投递反馈、形象期刊的数据制作、数据分发匹配、投递的反馈；
2、分销物流商品信息的展示、终端订单收集，商品订单数据的集中和配送处理；
3、在邮政基础设施数字化的基础上，实现二维码签到功能，实现服务质量监督的数字化管理；
4、通过采集投递交易地理位置坐标，实现投递作业路径的有效监控和管理。
2．2．2 建设原则
第一、全面集成原则。包括三个方面的集成：手机终端应用和PC应用访问接口集成、核心服务集成和应用数据的集成。[12]
应用接口集成主要体现在无论客户端是手机终端，还是PC客户端程序，还是网页浏览器，都通过统一的WEB服务接口调用来完成各自所需服务；核心服务集成应用层所需的交易后台服务，很多服务都可以被多种不同的客户端重复调用，提高了代码的复用性，并为以后加载更多的新业务提供了可能；应用数据的集成是指本系统所需的业务数据都来源于其它相关的业务系统，最新原始数据存在于第三方业务系统，本地定时进行基础数据同步和投递平台业务提交，同时，手机终端也会下载并保存部分本终端所需要的基础数据。
第二、支持个性化的配置。针对不同地市、区县业务开展情况，可以对不同操作员开放不同的模块操作权限（参见本文4.3.1节），具体应用的操作权限，不仅可以通过权限配置进行控制，还可以通过配置系统模块表进行多种方式的配置，例如结合业务状态，业务有效期等信息进行个性化配置，使得不同操作员拥有不同的操作界面。
2．3 业务需求分析
投递平台一期的业务归口部门主要涉及函件局、报刊发行局、分销物流局。通过需求调研，了解到函件局和报刊发行局在投递业务上共用邮政投递网，都有改进投递反馈流程方面的需求。同时，函件局的名址中心还承担名址信息维护的职责，名址资源服务于投递网，同样被两个专业局共同使用，对目前名址信息维护流程进行简化，减少层层反馈步骤，提高名址信息更新的及时性和准确性。分销物流局希望在平台上实现移动访销功能，利用投递平台系统和现有投递网资源，将单纯的投递网改造为投递加营销的综合网络，具体业务需求分析如下：
2．3．1 函件投递中的需求分析
投递反馈是指投递员在收到给据邮件的投递清单后， 在每投递一封邮件时，记录该邮件的收件人、收件时间等信息，并由收件人签字确认的过程。如果妥投成功，要记录未妥投的原因及处理结果，如查无此人、收件人拒收、改退、转下一班等。传统流程反馈环节多，
业务调研中，我们通过和投递员的沟通交流，认为上述业务通过android手机实现切实可行，将会大大减轻投递员的工作强度，缩短投递员和投递班交班处理的时间，从而加快投递的作业处理时间。但通过android手机实现必须解决以下几个方面的问题：
1、界面的易操作性。界面设计要简明，操作要快捷方便。投递员多数情况是手拿带着邮件进行妥投处理，基本上要求多数的操作单手可以完成。
2、用户签收问题。当前业务中，投递员妥投是由收件人在投递清单上进行签收（收件人签字或盖章，并写上身份证号），收件人签字可以明确投递员责任及解决因是否投递的法律纠纷问题。而通过手机妥投后，用户如何进行签收将是一个需要认真对待和解决的问题。
3、投递员的接件交班问题。当前业务中，投递员每天上班时从投递班签字取得投递清单和待投邮件，通过手机妥投后，投递员在获取投递清单和待投邮件时，如何向后台人员签收的问题。每日投递后，如何向后台人员交班。这些需要对业务流程、管理方式进行改造和改变。
2．3．2 期刊信息的需求分析
形象期刊信息反馈，是指形象期刊在异地发行中，解决客户无法获取订阅用户的反馈信息的问题。经了解，我省形象期刊发行量大（流转额3000万），在“中国邮政报刊发行系统”中同一个邮发代号不能满足个性化（分地市或订阅用户）的发行要求。建议开发一套我省的形象期刊管理系统，报刊目录数据由“中国邮政报刊发行系统”中获取更新，形象期刊发行时设置子代号，投递综合平台同该系统进行实时数据交互，具体操作由投递员投送时将妥投的反馈信息即时发送到该系统中来。
后台人员可以从系统中随时汇总给据邮件的妥投情况（每天、每月、年报），可以随时查询每个投递员、段道的妥投情况。
2．3．3 名址维护的需求分析
名址维护是指对“中国邮政名址信息系统”中的名址进行及时更新维护。业务现状是每季度由后台人员将各段道名址打印清单，由投递人员进行核对并批注修改，交由后台人员统一进行修改。从本次业务调研中发现以下方面的问题需要新系统来解决：
1、名址混乱：由于各种历史原因导致现有的地址库中存在大量的错误地址和旧地址。这些地址长期得不到删除和更新。
2、更新滞后：由于名址库的更新是由后台人员统一完成，时间上跨度很长，大量名址不能得到及时的更新。
3、后台负荷大：每季度末由名址管理人员集中录入，系统对名址的操作相对复杂，工作量极大。
4、投递和名址脱节：由于上述原因，大量的由名址库带来的衍生产品，如商函等无法进行投递，增加了投递处理的负荷和成本。投递和名址之间脱节，没有形成良性互动。建议在平台设计时，投递员进行妥投环节，进行地址定位，并可以联动进行名址的维护。数据接口需要同“中国邮政名址信息系统” 通过接口进行数据的交互。
2．3．4 报刊发行的需求分析
报刊发行局和函件局报刊发行局在投递服务上具备较高的业务相似度，其主要需求都在投递反馈方向。此外函件局还负责名址信息的维护，发行局负责报刊收订等工作。
报刊揽收是指通过投递员对散户开展的报刊收订工作。业务调研中，对“中国邮政报刊发行系统”中散户收订流程进行了解，同业务人员进行学习和交流。移动平台实现该业务重要关注以下几点：
报刊查询：投递员可以快速通过手机进行邮发代号的查询，形成收订信息。
收订收据：现在投递员收订后，每天交班后到发行班，将手工记录的收订信息和款项交由后台收订人员进行收订，次班将报刊收订收据交用户。通过交流，我们认为需要对这一业务流程进行改造，建议业务流程如下：
1、投递员在手机上实现收订成功后，后台向用户预留的手机发送收订信息（日期、收订号）。
2、投递员必须当天到邮储将收订款存到指定的委托分户上。
3、后台人员当日（次日）对投递员的收订和缴款信息进行核对。
4、投递员交班时将缴款回单交后台业务人员，同时将打印好的收订收据交由投递员。
2．3．5 分销物流的需求分析
随着河南邮政分销物流专业近几年的飞速发展，移动访销业务能够充分利用邮政投递队伍分布广泛、渗透力强的优势，以访问线路管理和销售采购管理为中心，满足分销物流专业酒水、洗化、小商品、小食品、农资等市场领域的业务需要。也就是业内称作“访销”的销售方式。
访销即走访销售，可以简单理解为上门服务，改变了传统坐店等客的销售模式，充分利用投递员熟悉当地零售商户、批销大户的优势，在投递员投递过程中给相关商户推销邮政物流商品，并给与一定的销售提成。访销业务的开展是提高邮政物流渠道影响力，提高投递员收入水平的重要措施。
访销业务已经成为现代渠道商的一种常用的营销手段，而“移动访销”更是近年来出现的新的销售模式，它利用信息技术作为辅助手段，在手持终端上完成下单操作，而相关的订单处理、订单配货、仓储物流管理另有一套完整的后台业务处理系统来完成支撑服务工作。经过分析，目前物流专业已经拥有一套商品管理系统，能够支撑订单的后续服务。手机终端下单完成后，订单通过特定接口提交至现有的物流配送系统，订单相关商品的调配货工作由物流配送系统完成。
挖掘潜在的销售能力，使投递员随时随地采集订单需求，是投递平台需要加载的一项重要业务，计划投递员通过智能手机客户端完成订单下单操作，并通过GPRS进行数据的上报，并支持辅助定位功能，保证了数据采集的及时性、准确性要求。
以订单查询为例，投递员使用手机终端上送的订单状态查询请求通过投递信息平台后台直接实时提交到河南邮政物流商品信息管理系统，提交移动平台流水号和投递员编号。系统返回信息包括返回代码、返回信息、终端编号、终端名称和订货时间。明细信息（当查询失败时不返回）内容包括商品编号、商品名称、价格类型、订货价格、订货数量、预付款金额、订货时间和订单明细状态。业务流程需要满足高度的灵活性与可适应性，计划使用 web logic所提供的独特的流程控制与任务分配的功能，按以下方式实现订单业务的各个制作过程：
1、 进行订单制作过程的定义时，将活动的分为订单流向判断、商品库存量判断、订单的、订单配货、订单缴款、订单取消、订单完成等活动。
2、 定义订单生成的权限为库存的一种扩展属性，定义订单数量为库存数在订单制作过程的一个相关数据（过程变量），并且定义任务分配条件为表达式，将表达式定义为：订单：订单要数<=库存数量
系统的作业监控管理，规定投递员的段道线路、班次，实现对投递员员的规范化管理；并通过辅助定位功能，解决对投递员的配送路线管理的问题。
2．4 用户角色分析
2．4．1 角色与权限分析
省级邮政管理层级可分为省、市、县、支局四级，各个层级机构又包含邮政各个专业。结合邮政内部管理层级划分与专业部门划分，需要设置的角色与权限分析如下：[6]
1省局管理员：具体职位为省函件局、省报刊发行局、省分销物流局的信息系统管理员，可管理全省范围内的移动终端信息、报刊目录信息、访销订单信息，可对全省投递员工作情况进行监督和统计，具体功能如图2-1所示
图2-1 省局管理用例图
2、市局管理员：具体职位为全省十八个地市的市函件局、市报刊发行局、市分销物流局的信息系统管理员。可管理全市所辖范围内的移动终端信息、报刊目录信息、访销订单信息，可对全市投递员工作情况进行监督和统计，功能如图2-2所示：
3、订销局管理员：具体职位为市、县级报刊发行专业的定销局信息系统管理员，可管理所辖范围内的移动终端信息、报刊目录信息、访销订单信息，对所辖投递员工作情况进行监督和统计。并且承担形象期刊批局、退改再投职能，主要由县局完成，市专业局也有同样的职能，功能如图2-3所示：
2．4．2 各角色业务流程分析
不同层级的角色有不同的权限，体现在系统中表现为不同角色可进行不同的操作，每个操作也有不同的流程，下面运用活动图分别对省局管理员、市局管理员、定销局管理员、支局管理员和投递员进行描述。
省局管理员：登录成功后可输入移动终端、村邮站信息、归班信息、投递轨迹信息、形象期刊信息的具体查询条件，系统可以根据用户提交的查询 条件进行查询，并返回查询结果；移动终端绑定活动，用户需提交移动终端信息和投递员信息，系统完成关联绑定操作，并返回绑定结果；终端角色维护，用户提交对终端角色的增删查改请求，系统完成用户提交的请求并返回执行结果；形象期刊信息录入，用户通过逐条录入或者批量导入的方式提交形象期刊信息，系统完成数据的记录，并同时完成形象期刊制签操作，返回操作结果。具体活动图如图2-7所示：
图2-7 省局管理员活动图
2．5 系统性能需求分析
根据系统的服务对象规模和分布情况以及业务的开展方式，系统性能需满足以下要求。[13]
1、高效性要求：本系统的最大用户群体是支局管理员和投递员，全省共有2500多个邮政支局，7000多名投递员，其中城镇投递员约有4000多名，去除大户段道，城市投递员平均一天的各类邮件投递量约在20件左右，系统先期供给程序投递员使用，在城镇地区完全普及后，每天的需要处理的投递反馈请求约在10万笔的数量级，节假日期间会数倍增长，根据Think Time计算公式,系统所需并发度为：
F = VU * R /T
其中，VU为用户数量；R为请求数；为T时间。
按照极端情况下，全天80%的业务量集中在两小时内提交进行估算，支撑每秒15笔业务并发度，能够满足日常高峰业务需求，而要保证支撑节假日高峰期业务开展需求，则需要达到每秒50笔的交易并发度。
综上所述，系统对软硬件的配置要求较高，所以配置必须要保证系统的高效运行。在项目的开发过程中就要充分考虑到系统的高效性要求。
2、可扩展性要求：系统的推广计划采用用户的逐级、逐地区开放的方式，因此系统的配置要充分考虑性能的可扩展性要求。主要集中在数据下载高峰期网络吞吐量和交易高峰期业务并发度，对业务并发度必须要有充分的考虑。系统后台服务器计划采用F5负载均衡技术，多台服务器共同对外提供服务，随着业务量增长，可以方便的将更多服务器并入负载均衡从而完成性能扩展。
3、系统安全要求
系统在安全性设计方面作以下考虑：
访问安全控制：系统为了防止不合法的访问，采用了手机终端序列号的绑定与加密传输协议https。
通讯安全控制：系统为了保证通讯过程中的安全，与业务系统使用同一套网络（专线）以保证数据在传输过程中的安全。业务数据省集中存储，管理权限集中后可防止业务数据被非法窃取。
存储安全控制：利用数据库的日常备份机制（日终备份另外机器的方式）可保证在突发事件情况下的数据安全恢复。
2．6 本章小结
本章从投递平台的建设目标与建设原则出发，从业务需求分析、用户角色分析、系统性能需求分析三个面，对项目的系统架构、角色与权限、系统配置以及主要子系统的功能边界予以分析和确认。
在此阶段，项目已经完成启动和计划筹备，项目相关部门职责、合作方式、人员配置已经得到确认，并已在技术与业务部门之间以集中讨论的方式对项目的功能边界予以划定，在技术部门内部对网络结构和大致流程进行了反复讨论论证。
针对邮政投平台的建设，我们多次到报刊发行局和分销物流局进行业务调研，了解了业务需求的主要内容，确定了更深的业务需求挖掘方向。调研管理入手，自上而下，从发行班、投递班到人投递员及段道，深入了解业务现状和业务需求，对各层面的业务需求及其关注点进行了摸底，初步形成了本次调研的业务需求。并确定项目第一期的两个核心子功能，为下一阶段平台功能分解与设计工作提供依据。
需求分析是项目开发的第一个阶段，根据项目的具体情况选用合适的需求分析方式，是需求分析能否能够顺利推进，以及所得结果是否能够支撑原先设想开发模型的先决条件，在这一阶段，我们需要对以下几个问题进行确认：
1.投递平台需要服务于哪些业务部门，需要完成哪些具体功能？
2.投递平台的最终用户是谁，用户的操作权限和访问方式如何分配？
3.业务部门对平台性能有哪些要求？
2．1 需求分析的方式
通过对比常用的需求分析方法的优劣性和运用场景需求。按照先进行场景分析，再进行需求分析方式选取的原则，首先对项目的现状进行分析如下：[2]
项目的提出方是函件局、报刊发行局、分销物流局相关领导，计划通过类似的信息化模式完成各自的旧业务流程改造和新业务开展工作。具体系统用户是相关专业局各个层级的业务人员，由于项目的提出者与主要用户并非同一人群，因此必然要选取一种能够在管理层、用户层、技术层三方之间能够达成一致的需求分析方式。根据项目的这一特点，我们采用了传统的结构化分析方法，在需求分析阶段并不要求精确的定义业务流程细节，在功能上保留一定的宽裕度，将具体细节的确认推后至系统的设计阶段。与管理层明确项目的功能要求和实现效果要求，与业务人员明确新流程、新业务的具体实施步骤，并在内部分析项目的技术可行性，是这一阶段的主要工作内容。
由于本项目得到足够的管理层支持，项目的跨部门协调工作就变得相对简单。针对函件局的需求，采用了实地跟班操作的调研方式，技术人员被抽调到函件局，在商函部、账单部、名址中心、投递部四个部门对现有业务流程进行全面的跟踪和考察；由于报刊业务与函件业务存在相当一部分重复需求，并考虑到技术队伍中有报刊业务专家，对于报刊发行局的业务需求调研，主要采用集中讨论的方式着重对报刊发行的业务特色进行分析；物流访销业务是新的业务需求，业务本身尚未发展成型，因此缺少固定的业务模式，后期需求变更的风险性较为突出
2．2 建设目标与建设原则
2．2．1 建设目标
投递平台的建设目标是解决当前投递环节中较为突出的邮件妥投反馈不及时、名址信息维护中出现名址信息更新滞后、后台录入人员工作负担重、投递和名址脱节问题，使邮政投递最后一公里的信息化水平达到行业领先。同时，利用手机终端实现投递员访问村邮站进行订单数据信息收集的需求，丰富了投递员的业务种类，提高了投递员收入，促进邮政多个专业协同发展。
投递平台以信息化手段服务于投递队伍转型改革，以段道+投递员+业务绩效为核心的全面量化管理，实现投递环节资源和邮政内部专业资源的有效整合，全面提升投递队伍素质和服务能力水平，促进邮政综合社会服务平台建设。能够为企业提供投递员实时作业监控，投递信息及时反馈、名址信息实时维护、产品订货、广告宣传、培训等功能，加快实现投递员向客户经理的转变、提升其社会渠道管理能力。
系统实现功能目标步骤分解如下：
1、实现给据邮件的投递反馈、党报投递反馈、形象期刊的数据制作、数据分发匹配、投递的反馈；
2、分销物流商品信息的展示、终端订单收集，商品订单数据的集中和配送处理；
3、在邮政基础设施数字化的基础上，实现二维码签到功能，实现服务质量监督的数字化管理；
4、通过采集投递交易地理位置坐标，实现投递作业路径的有效监控和管理。
2．2．2 建设原则
第一、全面集成原则。包括三个方面的集成：手机终端应用和PC应用访问接口集成、核心服务集成和应用数据的集成。[12]
应用接口集成主要体现在无论客户端是手机终端，还是PC客户端程序，还是网页浏览器，都通过统一的WEB服务接口调用来完成各自所需服务；核心服务集成应用层所需的交易后台服务，很多服务都可以被多种不同的客户端重复调用，提高了代码的复用性，并为以后加载更多的新业务提供了可能；应用数据的集成是指本系统所需的业务数据都来源于其它相关的业务系统，最新原始数据存在于第三方业务系统，本地定时进行基础数据同步和投递平台业务提交，同时，手机终端也会下载并保存部分本终端所需要的基础数据。
第二、支持个性化的配置。针对不同地市、区县业务开展情况，可以对不同操作员开放不同的模块操作权限（参见本文4.3.1节），具体应用的操作权限，不仅可以通过权限配置进行控制，还可以通过配置系统模块表进行多种方式的配置，例如结合业务状态，业务有效期等信息进行个性化配置，使得不同操作员拥有不同的操作界面。
2．3 业务需求分析
投递平台一期的业务归口部门主要涉及函件局、报刊发行局、分销物流局。通过需求调研，了解到函件局和报刊发行局在投递业务上共用邮政投递网，都有改进投递反馈流程方面的需求。同时，函件局的名址中心还承担名址信息维护的职责，名址资源服务于投递网，同样被两个专业局共同使用，对目前名址信息维护流程进行简化，减少层层反馈步骤，提高名址信息更新的及时性和准确性。分销物流局希望在平台上实现移动访销功能，利用投递平台系统和现有投递网资源，将单纯的投递网改造为投递加营销的综合网络，具体业务需求分析如下：
2．3．1 函件投递中的需求分析
投递反馈是指投递员在收到给据邮件的投递清单后， 在每投递一封邮件时，记录该邮件的收件人、收件时间等信息，并由收件人签字确认的过程。如果妥投成功，要记录未妥投的原因及处理结果，如查无此人、收件人拒收、改退、转下一班等。传统流程反馈环节多，
业务调研中，我们通过和投递员的沟通交流，认为上述业务通过android手机实现切实可行，将会大大减轻投递员的工作强度，缩短投递员和投递班交班处理的时间，从而加快投递的作业处理时间。但通过android手机实现必须解决以下几个方面的问题：
1、界面的易操作性。界面设计要简明，操作要快捷方便。投递员多数情况是手拿带着邮件进行妥投处理，基本上要求多数的操作单手可以完成。
2、用户签收问题。当前业务中，投递员妥投是由收件人在投递清单上进行签收（收件人签字或盖章，并写上身份证号），收件人签字可以明确投递员责任及解决因是否投递的法律纠纷问题。而通过手机妥投后，用户如何进行签收将是一个需要认真对待和解决的问题。
3、投递员的接件交班问题。当前业务中，投递员每天上班时从投递班签字取得投递清单和待投邮件，通过手机妥投后，投递员在获取投递清单和待投邮件时，如何向后台人员签收的问题。每日投递后，如何向后台人员交班。这些需要对业务流程、管理方式进行改造和改变。
2．3．2 期刊信息的需求分析
形象期刊信息反馈，是指形象期刊在异地发行中，解决客户无法获取订阅用户的反馈信息的问题。经了解，我省形象期刊发行量大（流转额3000万），在“中国邮政报刊发行系统”中同一个邮发代号不能满足个性化（分地市或订阅用户）的发行要求。建议开发一套我省的形象期刊管理系统，报刊目录数据由“中国邮政报刊发行系统”中获取更新，形象期刊发行时设置子代号，投递综合平台同该系统进行实时数据交互，具体操作由投递员投送时将妥投的反馈信息即时发送到该系统中来。
后台人员可以从系统中随时汇总给据邮件的妥投情况（每天、每月、年报），可以随时查询每个投递员、段道的妥投情况。
2．3．3 名址维护的需求分析
名址维护是指对“中国邮政名址信息系统”中的名址进行及时更新维护。业务现状是每季度由后台人员将各段道名址打印清单，由投递人员进行核对并批注修改，交由后台人员统一进行修改。从本次业务调研中发现以下方面的问题需要新系统来解决：
1、名址混乱：由于各种历史原因导致现有的地址库中存在大量的错误地址和旧地址。这些地址长期得不到删除和更新。
2、更新滞后：由于名址库的更新是由后台人员统一完成，时间上跨度很长，大量名址不能得到及时的更新。
3、后台负荷大：每季度末由名址管理人员集中录入，系统对名址的操作相对复杂，工作量极大。
4、投递和名址脱节：由于上述原因，大量的由名址库带来的衍生产品，如商函等无法进行投递，增加了投递处理的负荷和成本。投递和名址之间脱节，没有形成良性互动。建议在平台设计时，投递员进行妥投环节，进行地址定位，并可以联动进行名址的维护。数据接口需要同“中国邮政名址信息系统” 通过接口进行数据的交互。
2．3．4 报刊发行的需求分析
报刊发行局和函件局报刊发行局在投递服务上具备较高的业务相似度，其主要需求都在投递反馈方向。此外函件局还负责名址信息的维护，发行局负责报刊收订等工作。
报刊揽收是指通过投递员对散户开展的报刊收订工作。业务调研中，对“中国邮政报刊发行系统”中散户收订流程进行了解，同业务人员进行学习和交流。移动平台实现该业务重要关注以下几点：
报刊查询：投递员可以快速通过手机进行邮发代号的查询，形成收订信息。
收订收据：现在投递员收订后，每天交班后到发行班，将手工记录的收订信息和款项交由后台收订人员进行收订，次班将报刊收订收据交用户。通过交流，我们认为需要对这一业务流程进行改造，建议业务流程如下：
1、投递员在手机上实现收订成功后，后台向用户预留的手机发送收订信息（日期、收订号）。
2、投递员必须当天到邮储将收订款存到指定的委托分户上。
3、后台人员当日（次日）对投递员的收订和缴款信息进行核对。
4、投递员交班时将缴款回单交后台业务人员，同时将打印好的收订收据交由投递员。
2．3．5 分销物流的需求分析
随着河南邮政分销物流专业近几年的飞速发展，移动访销业务能够充分利用邮政投递队伍分布广泛、渗透力强的优势，以访问线路管理和销售采购管理为中心，满足分销物流专业酒水、洗化、小商品、小食品、农资等市场领域的业务需要。也就是业内称作“访销”的销售方式。
访销即走访销售，可以简单理解为上门服务，改变了传统坐店等客的销售模式，充分利用投递员熟悉当地零售商户、批销大户的优势，在投递员投递过程中给相关商户推销邮政物流商品，并给与一定的销售提成。访销业务的开展是提高邮政物流渠道影响力，提高投递员收入水平的重要措施。
访销业务已经成为现代渠道商的一种常用的营销手段，而“移动访销”更是近年来出现的新的销售模式，它利用信息技术作为辅助手段，在手持终端上完成下单操作，而相关的订单处理、订单配货、仓储物流管理另有一套完整的后台业务处理系统来完成支撑服务工作。经过分析，目前物流专业已经拥有一套商品管理系统，能够支撑订单的后续服务。手机终端下单完成后，订单通过特定接口提交至现有的物流配送系统，订单相关商品的调配货工作由物流配送系统完成。
挖掘潜在的销售能力，使投递员随时随地采集订单需求，是投递平台需要加载的一项重要业务，计划投递员通过智能手机客户端完成订单下单操作，并通过GPRS进行数据的上报，并支持辅助定位功能，保证了数据采集的及时性、准确性要求。
以订单查询为例，投递员使用手机终端上送的订单状态查询请求通过投递信息平台后台直接实时提交到河南邮政物流商品信息管理系统，提交移动平台流水号和投递员编号。系统返回信息包括返回代码、返回信息、终端编号、终端名称和订货时间。明细信息（当查询失败时不返回）内容包括商品编号、商品名称、价格类型、订货价格、订货数量、预付款金额、订货时间和订单明细状态。业务流程需要满足高度的灵活性与可适应性，计划使用 web logic所提供的独特的流程控制与任务分配的功能，按以下方式实现订单业务的各个制作过程：
1、 进行订单制作过程的定义时，将活动的分为订单流向判断、商品库存量判断、订单的、订单配货、订单缴款、订单取消、订单完成等活动。
2、 定义订单生成的权限为库存的一种扩展属性，定义订单数量为库存数在订单制作过程的一个相关数据（过程变量），并且定义任务分配条件为表达式，将表达式定义为：订单：订单要数<=库存数量
系统的作业监控管理，规定投递员的段道线路、班次，实现对投递员员的规范化管理；并通过辅助定位功能，解决对投递员的配送路线管理的问题。
2．4 用户角色分析
2．4．1 角色与权限分析
省级邮政管理层级可分为省、市、县、支局四级，各个层级机构又包含邮政各个专业。结合邮政内部管理层级划分与专业部门划分，需要设置的角色与权限分析如下：[6]
1省局管理员：具体职位为省函件局、省报刊发行局、省分销物流局的信息系统管理员，可管理全省范围内的移动终端信息、报刊目录信息、访销订单信息，可对全省投递员工作情况进行监督和统计，具体功能如图2-1所示
图2-1 省局管理用例图
2、市局管理员：具体职位为全省十八个地市的市函件局、市报刊发行局、市分销物流局的信息系统管理员。可管理全市所辖范围内的移动终端信息、报刊目录信息、访销订单信息，可对全市投递员工作情况进行监督和统计，功能如图2-2所示：
3、订销局管理员：具体职位为市、县级报刊发行专业的定销局信息系统管理员，可管理所辖范围内的移动终端信息、报刊目录信息、访销订单信息，对所辖投递员工作情况进行监督和统计。并且承担形象期刊批局、退改再投职能，主要由县局完成，市专业局也有同样的职能，功能如图2-3所示：
2．4．2 各角色业务流程分析
不同层级的角色有不同的权限，体现在系统中表现为不同角色可进行不同的操作，每个操作也有不同的流程，下面运用活动图分别对省局管理员、市局管理员、定销局管理员、支局管理员和投递员进行描述。
省局管理员：登录成功后可输入移动终端、村邮站信息、归班信息、投递轨迹信息、形象期刊信息的具体查询条件，系统可以根据用户提交的查询 条件进行查询，并返回查询结果；移动终端绑定活动，用户需提交移动终端信息和投递员信息，系统完成关联绑定操作，并返回绑定结果；终端角色维护，用户提交对终端角色的增删查改请求，系统完成用户提交的请求并返回执行结果；形象期刊信息录入，用户通过逐条录入或者批量导入的方式提交形象期刊信息，系统完成数据的记录，并同时完成形象期刊制签操作，返回操作结果。具体活动图如图2-7所示：
图2-7 省局管理员活动图
2．5 系统性能需求分析
根据系统的服务对象规模和分布情况以及业务的开展方式，系统性能需满足以下要求。[13]
1、高效性要求：本系统的最大用户群体是支局管理员和投递员，全省共有2500多个邮政支局，7000多名投递员，其中城镇投递员约有4000多名，去除大户段道，城市投递员平均一天的各类邮件投递量约在20件左右，系统先期供给程序投递员使用，在城镇地区完全普及后，每天的需要处理的投递反馈请求约在10万笔的数量级，节假日期间会数倍增长，根据Think Time计算公式,系统所需并发度为：
F = VU * R /T
其中，VU为用户数量；R为请求数；为T时间。
按照极端情况下，全天80%的业务量集中在两小时内提交进行估算，支撑每秒15笔业务并发度，能够满足日常高峰业务需求，而要保证支撑节假日高峰期业务开展需求，则需要达到每秒50笔的交易并发度。
综上所述，系统对软硬件的配置要求较高，所以配置必须要保证系统的高效运行。在项目的开发过程中就要充分考虑到系统的高效性要求。
2、可扩展性要求：系统的推广计划采用用户的逐级、逐地区开放的方式，因此系统的配置要充分考虑性能的可扩展性要求。主要集中在数据下载高峰期网络吞吐量和交易高峰期业务并发度，对业务并发度必须要有充分的考虑。系统后台服务器计划采用F5负载均衡技术，多台服务器共同对外提供服务，随着业务量增长，可以方便的将更多服务器并入负载均衡从而完成性能扩展。
3、系统安全要求
系统在安全性设计方面作以下考虑：
访问安全控制：系统为了防止不合法的访问，采用了手机终端序列号的绑定与加密传输协议https。
通讯安全控制：系统为了保证通讯过程中的安全，与业务系统使用同一套网络（专线）以保证数据在传输过程中的安全。业务数据省集中存储，管理权限集中后可防止业务数据被非法窃取。
存储安全控制：利用数据库的日常备份机制（日终备份另外机器的方式）可保证在突发事件情况下的数据安全恢复。
2．6 本章小结
本章从投递平台的建设目标与建设原则出发，从业务需求分析、用户角色分析、系统性能需求分析三个面，对项目的系统架构、角色与权限、系统配置以及主要子系统的功能边界予以分析和确认。
在此阶段，项目已经完成启动和计划筹备，项目相关部门职责、合作方式、人员配置已经得到确认，并已在技术与业务部门之间以集中讨论的方式对项目的功能边界予以划定，在技术部门内部对网络结构和大致流程进行了反复讨论论证。
针对邮政投平台的建设，我们多次到报刊发行局和分销物流局进行业务调研，了解了业务需求的主要内容，确定了更深的业务需求挖掘方向。调研管理入手，自上而下，从发行班、投递班到人投递员及段道，深入了解业务现状和业务需求，对各层面的业务需求及其关注点进行了摸底，初步形成了本次调研的业务需求。并确定项目第一期的两个核心子功能，为下一阶段平台功能分解与设计工作提供依据。