【系统架构设计师】论文:论需求分析方法及应用

论文:论需求分析方法及应用

文章目录

摘要

2021年9月,我参与了某省移动通信有限公司VerisBilling6.0项目的研发,该系统主要完成在线计费、离线计费、内容计费、账务处理、产品管理、信控管理等功能的整合。我在该项目中担任系统分析师角色,全程参与了VerisBilling6.0系统的分析规划及设计工作。本文以Veris Billing6.0系统为例,主要论述了结构化分析方法在该系统的具体应用。通过采用数据流图描述系统的功能组成;采用状态转换图对用户的状态进行判断;采用数据字典对数据进行详细和准确的描述。通过以上技术的使用,使得需求分析的质量得到了保证,对后续项目的顺利实施提供了有力的支撑,最终项目于2022年4月正式上线,获得省移动通信公司各级领导的好评。

正文

近几年来某省移动用户增长至3000多万,随着移动数据流量资费的新一轮下调,导致GPRS数据流量成爆发式增长,OpenBillingNG版系统在话单处理上瓶颈显现。2021年春节期间,GPRS日话单达到30亿条,话单处理处于积压状态,直到节后两周才将积压话单追完,大量跨月的话单引发了大批用户投诉,给移动业务支撑中心带来的压力非常大;该省移动通信公司相关领导联合系统运营商遂展开会议讨论解决方案,最终决定将该省OpenBillingNG版升级至VerisBilling6.0版本,以解决OpenBillingNG版本遇到的瓶颈问题。作为移动通信BOSS业务支撑的核心,VerisBilling6.0需支持24x7连续运行,满足话单的实时处理,还需要把在线计费、离线计费、内容计费、账务处理、产品管理等在OpenBillingNG版时独立的系统进行整合。我以系统分析师的角色全程参与了项目的建设,VerisBilling6.0由产品管理组、研发组、测试组、对账组、运维组、数据组、专家组共120人组成的项目团队,耗时8个月完成,项目从2021年9月启动,至2022年4月30日上线。

要做好这个项目,需求分析非常关键。需求分析就是将杂乱无章的用户要求和期望转化为用户需求。那要怎么才能完成需求分析工作呢?可以通过绘制上下文范围关系图,定义系统与系统外部实体间的界限和接口,来确定需求范围;创建用户界面,帮助用户理解系统;分析需求的可行性,技术、经济、法律等;确定需求优先级,制定出系统研发的迭代计划;建立需求模型,帮助系统分析师理解系统,为软件设计提供系统的表示视图;创建数据字典以确保开发人员使用统一的数据定义;并使用QFD将产品的特性、属性和对用户的重要性联系起来。

VerisBilling6.0项目前期,专家组会同现场运维人员对OpenBillingNG系统做了一次性能评审,并由专家组提供性能评估报告。报告指出该省13年做过一次系统升级,现有的NG版本包括两个数据中心,各中心话单处理峰值是12亿话单量,均使用的是配置较好的小型机。通过这个报告项目团队对现场的情况有了更为详细的了解,经过项目团队主要负责人会议充分讨论后,决定在需求文档里尽量用图形来代替冗长枯燥的文字描述复杂的系统功能,最终通过评审,我们选择在需求分析时主要使用结构化分析方法,围绕数据字典建设、运用的数据流图、状态转换图来进行需求分析工作

一、数据流图的运用。

为了向客户清楚地描述系统的由哪些功能部分组成,我们利用DFD将离线计费系统的话单采集、预处理、话单分拣、话单查重、业务分析、批价、详单入库、分发、消费提醒几个功能模块的输入输出用一系列的处理连接起来,用图形符号准确地描述系统内各功能部件及数据在它们之间的传递情况,简明易懂。再利用DFD分别对采集、解码、话单分拣、话单查重、业务分析、批价、详单入库、分发、信控等功能模块进行分解,使得整个计费系统的复杂处理过程得以采用图形化的方式来描述,减少了大量篇幅的文字描述,使需求分析文档看上去非常简洁。同样我们用数据流图将在线计费、内容计费、账务处理、产品管理、信控管理等系统进行了分解描述。使得整个需求文档看上去更清晰,尽量避免让客户去看哪些枯燥冗长的文章,让即使是不懂技术的客户看完这些图,也能理解系统的数据处理过程。

二、状态转换图的运用。

DFD仅仅描述了系统的功能组成部分及功能间了联系,而系统运行过程中需要对用户的状态做大量的判断,如用户的余额情况、用户的套餐情况、用户星级、停开机状态等。这些状态判断靠事件驱动,为将这些状态描述清楚,我们在需求分析过程中还使用了状态转换图。STD描述了系统如何在各种状态之间移动,如用户订购了A套餐且产生了相应的话单,系统在分析时需要根据话单的属性将用户使用到的A套餐产品解析出来,批价的时候才能匹配到A套餐产品进行计费。而当用户订购的A套餐已经耗尽,系统分析时就会转到基础套餐产品。通过使用STD,能清楚地描述了用户的状态转换过程,选择合理的输出。计费系统的过程非常复杂,需要分析判断的用户状态非常多。

三、数据字典的运用。

数据字典是结构化分析方法的核心,数据字典完成了DFD对数据详细内容无法具体、准确的描述,是对DFD的强力的补充。Veris Billing6.0项目数据结构的非常复杂,数据字典的设计要求非常高。包括系统域,产品域,资费域,控制域共涉及数据表670张。为了保障数据字典完整性和一致性,我安排了专门的数据库管理员对数据字典进行管理,项目团队任何人要调整数据字典都必须交由该专人进行调整,并且对所有的变更都必须有项目经理签字,变更记录必须邮件及时发送给其他团队负责人及本组成员。为保障后续的数据割接工作不出现问题,数据字典的设计必须考虑OpenBillingNG版系统的实际情况,为此,特地安排了2名现场维护人员参与数据数据字典设计并负责后期的数据割接工作;一方面方便交流,另一方面可以充分考虑现场的实际情况并为后期的数据割接做足准备。

通过使用结构化分析方法,使得需求分析工作完成得非常顺利,需求分析的质量得到了保证,对后续项目的顺利实施提供了有力的支撑。项目于2022年4月30日完成割接上线,在生产环境运行了半年,各项性能指标达到客户要求,并经受住了五一节假日和国庆黄金周的检验,话单积压的问题得到解决,最终通过用户的验收,项目获得了该省移动通信公司领导的好评。

总结

在项目结束后的讨论会上,大家也指出了项目中存在一些不足,如云详单功能模块在性能上没有达到预期的目标,导致客户的详单查询效率低下,上线后又经过几轮的优化处理,才在性能上满足客户需求。另外,外围系统在抽取详单数据时需要研发专门的接口,维护难度增大。为此,我们不得不在项目后期又花费精力为现场运维人员开发了一款辅助产品,使现场运维人员能用图形化界面通过简单的配置即可生成相应的接口脚本。总的来说,这些问题主要还是需求分析时对云详单功能模块的考虑不够透彻,测试工作没有做彻底,埋下的隐患。所以,在以后的项目里,需求分析质量得到保障的情况,还要把控好测试质量,把握好系统实施的每个细节。

更多内容请见备考系统架构设计师-核心总结索引

相关推荐
找了一圈尾巴11 小时前
架构师备考-架构基本概念
架构·系统架构
诗这样的12 小时前
【需求变更】使用 Redis 和 Lua 脚本实现变更后方案编号的生成
java·redis·缓存·微服务·lua·需求分析
Mephostopheles14 小时前
0基础读顶会论文—流程即服务(PraaS):通过无服务器流程统一弹性云和有状态云
论文
spssau1 天前
13类高频数据分析方法分类汇总
大数据·数据分析·论文·spss·spssau
白总Server1 天前
OpenHarmony
后端·spring cloud·华为·微服务·ribbon·架构·系统架构
ftswsfb2 天前
【系统架构设计师】六、UML建模与架构文档化
系统架构·uml
程序猿进阶2 天前
系统上云-流量分析和链路分析
java·后端·阿里云·面试·性能优化·系统架构·云计算
我码玄黄2 天前
软考系统分析师知识点三二:案例知识点三
软考高级·软考·系统分析师·软考复习
ccino .2 天前
企业级邮件系统架构
系统架构
qq26215424092 天前
挂名副主编评职称能用吗?
论文·教育·独著·出书