论需求分析方法及应用-系统分析师论文

这篇文章是我关于《需求分析方法及应用》的系统分析师论文。

2020年3月，我参与了某某省图书发行集团公司的业务管理系统的研发项目。该系统以图书销售功能为核心，分为采购管理模块、入库管理模块、库存管理模块、销售管理模块、退货管理模块、调剂管理模块、盘点管理模块、客户管理模块、促销管理模块、APP模块等。我在项目中担任系统分析师，全程参与了系统整体的规划分析以及设计工作。本文以该系统为例，主要论述了结构化分析方法在该系统的具体应用。通过采用数据流图描述系统的功能组成；采用状态转换图对用户状态进行判断；采用数据字典对数据进行详细和准确的描述。通过以上技术的使用，使得需求分析的质量得到保证，对后续项目顺利实施提供了有力的支撑，最终项目于2021年12月正式上线，获得集团公司各级领导的好评。

       该集团公司的现有业务管理系统是20多年前开发的，且各子分公司、各门店系统均是独立运行的局域网C/S架构系统，由于已经完全不能满足公司业务开展和互联网技术发展的需要，该公司论证认为此系统即无商业价值也无技术价值，可以淘汰，重新研发一套新的系统。2020年3月，我单位承接了该集团公司的业务管理系统的研发项目（以下简称为“系统”），以取代原有传统的业务管理系统。该系统主要以图书销售功能为核心，分为采购管理模块、入库管理模块、库存管理模块、销售管理模块、退货管理模块、调剂管理模块、盘点管理模块、客户管理模块、促销管理模块、APP模块等。采购管理模块主要负责采购订单的管理，采购员根据采购要求提交订单到系统，系统将根据业务流程将订单发送到采购经理审核，将审核后的订单发送给出版社进行订货；入库管理模块用于采购到货后的入库管理；库存管理模块用于因入库、销售、调剂、退货等操作引起的库存变化，保证库存的准确；销售管理模块主要用于全省各门店POS机销售、政企部门批量销售、线上APP销售的管理；退货管理模块用于向出版社的退货管理；调剂管理模块用于各门店间的图书调剂管理；盘点管理模块用于管理各门店的库存盘点；客户管理模块负责客户信息的管理。在这个项目中，我担任了系统分析师的职务，主要负责系统的分析设计相关工作。

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

       经过项目团队主要负责人会议充分讨论后，决定在需求文档里尽量使用图形来替代冗长枯燥的文字描述复杂的系统功能，最终通过评审，我们选择在需求分析时主要使用结构化分析方法，围绕数据字典建设、运用数据流图、状态转换图来进行需求分析工作。

       数据流图的运用。为了向客户清楚地描述系统的那些功能部分组成，我们能利益DFD将产品的采集、接收、入库、分发、处理、转换、加工、校验、消息提醒几个模块的输入输出用一系列的处理连接起来，用图形符号准确地描述系统内各功能部件以及数据在它们之间的传递情况，简明易懂。在利用DFD分别对采集、解码、查重、业务分析、价格处理、详细入库推送到经销商以及集团官网上面售卖。通过DFD图进行数据处理进行分解，使得整个系统的复杂处理过程得以采用图形化的方式来描述，减少了大量篇幅的文字描述，使需求分析文档看起来非常简洁。同样我们用数据数据流图将在产品管理、订单管理、财务单据管理、信息流管理等系统进行了分解描述。使得整个需求文档看上去更加清晰，尽量避免让客户以及业务人员去看那些枯燥冗长的文章，让即使是不懂技术的客户、业务、研发、产品看完这些图，也能理解系统的数据处理过程。

       状态转换图的运用。DFD仅仅描述了系统的功能组成部分以及功能之间的联系，而系统运行过程中需要对用户的状态做大量的批判，如产品的库存、价格情况、订单的支付金额、状态情况、上架的状态情况等等，这些状态判断依靠事件驱动，为将这些状态描述清楚，我们在需求分析过程中还使用了状态转换图，STD描述了系统如何在各种状态之间移动，如用户订购了A产品的订单，产生了A产品的费用，系统在分析时需要根据订单的属性将用户使用到的A订单产品解析出来，比如有机票、地接服务、门票等；然后进行各个单资源进行价格的计算。而当用户订购了A产品已经售卖为空，系统分析就会进行A产品的分析时显示订单产品异常，会有业务人员进行参与进来解决；通过使用STD，能清楚地描述了用户状态的转换过程，选择合理的输出。整个订单的下单过程非常复杂，需要分析判断的用户状态也非常多。

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

       通过使用结构化方法，使得需求分析工作完成得非常顺利，需求分析的质量得到保证，对后续项目的顺利实施提供了有力的支撑。项目系统于2021年12月完成割接上线，在生产环境运行了3个月，各项指标性能达到了集团要求，并经受住了国庆假、五一节日黄金周的考验，订单的自动化问题、消息消费不及时的问题得到解决，最终通过了验收，项目获得了集团各层领导的好评。

       在项目结束后的讨论会议上，大家也指出了项目中存在一些不足，如订单模块在性能上面没有达到预期的目标，导致的客户详单查收效率低下，上线后又经过了几轮优化处理，才在性能上面满足需求。另外，外围欸抽取订单详情数据时，没有一个可视化的数据流图，为此，我们不得不花费精力在下单的流程中添加日志的流程图日志处理，每个重要的节点会进行日志的记录，比如说，支付节点、出团书节点、库存、价格校验节点等，每个节点都会又详细的请求、响应日志以及时间响应的时长。为了后续的运维同事可以通过图形化的界面进行查看订单的实际情况。总的来说，这些问题主要还是需求分析时对订单功能模块考虑不够透彻，测试没有做彻底，埋下的隐患。所以，在以后的项目里面，需求分析质量得到保障的情况，还要把控好测试质量，把握好实施的每个细节。