前言
由于最近在备考系统分析师，需要准备一些论文，所以后面会写一个系列的文章，对于工作多年的项目一个总结，也锻炼一下写作水平，准备备考2022年上半年系统分析师的同学，可以参考一下，欢迎交流
试题
需求分析师提炼、分析和仔细审查已经获取到的需求的过程，需求分析的目的师确保所有的项目干系人（利益相关者）都理解需求的含义并找出其中的错误、遗漏或其它不足的地方。需求分析的关键在于对问题域的研究与理解。为了便于理解问题域，现代软件工程所推荐的需求分析方法是对问题域进行抽象，将其分解为若干基本元素，然后对元素之间的关系进行建模。常见的需求分析方法包括面向对象的分析方法、面向问题域的分析方法、结构化分析方法等。而无论采用何种方法，需求分析的主要工作内容都基本相同。
请围绕“需求分析方法及应用”论题，依次从以下三个方面进行论述
- 简要叙述你参与管理和开发的软件系统开发项目以及你在其中所承担的主要工作
- 概要论述需求分析工作过程所包含的主要工作内容。
- 结合你具体参与管理和开发的实际项目，说明采用了何种需求分析方法，并举例详细 描述具体的需求分析过程。
范例：
摘要部分：
2018年6月，我参与全球旅游玩乐系统项目的研发，该系统主要是使用中台的方式进行供应商、经销商的整合，自动化上架、下架、更新价格、库存的系统。我在项目中担任系统分析师的角色，全程参与了系统整体的分析规划以及设计工作。本文以该系统为例，主要论述了结构化分析方法在该系统的具体应用。通过采用数据流描述系统的功能组成；采用状态转换图对用户状态进行判断；采用数据字典对数据进行详细和准确的描述。通过以上技术的使用，使得需求分析的质量得到保证，对后续项目顺利实施提供了有力的支撑，最终项目于2019年5月正式上线，获得集团公司各级领导的好评； （注意：实际写作中相关项目情况应该介绍清楚，摘要字数（包括标点符号）一般写300到320个字；
正文部分：
2018年左右随着国内旅游的蓬勃发展，传统的旅游系统很难支撑大规模的产品上、下架以及产品的价格、库存的变动的业务处理，由于产品量可以达到几十万种左右，并且在变化中，所以使用人力来进行系统的维护会耗费很多的人力、物力，并且人力的操作容易产生误差以及不及时的情况。旅游集团最终决定将自动化的系统进行上线研发的项目规划，以解决传统旅游行业的系统老旧、不及时、很难支持的问题；
2018年6月，我所在的旅游集团决定进行全球旅游系统的研发，我在项目中担任系统分析师岗位，主要负责该项目需求分析调研，详细设计、主要研发的工作。该系统是一个大型的系统一共有30多个人的研发团队，耗时9个月的研发最终在2019年5月份上线；该系统支持供应商的系统上线产品的自动化同步以及我们系统的主动拉取更新产品的价格、库存、上架、下架的操作；也支持经销商的产品推送上架、下架以及新产品的库存、价格的更新，经销商的下单流程自动化的操作；供应商的产品接入主要使用的适配器的方式进行转换为行业标准化的产品；经销商下单使用的是反射进行策略模式进行不同经销商的下单实体的转换处理；一直到出票，支付、财务的结算处理；中间很少的业务人员参与；
要做好这个项目，需求分析非常关键。需求分析就是将杂乱无章的用户要求和期望转化为用户需求，那要怎么才能完成需求分析工作呢？可以通过绘制上下文范围关系图，定义系统与系统外部实体间的界限和接口，来确定需求范围；创建用户界面，帮助用户理解系统；分析需求的可行性，技术、经济、法律等；确定需求优先级，制定出系统研发的迭代计划；建立需求模型，帮助系统分析师理解系统，为软件设计提供系统的表示视图；创建数据字典以确保开发人员使用统一的数据定义；并使用QFD将 产品的特性、属性和对用户的重要性联系起来；
全球旅游玩乐系统项目前期，专家组会同线程运维人员对系统做了一次性能评审，并由专家组提供性能评估报告。报告指出系统在去年做过一次系统升级，现有的系统版本包括两个数据中心，一个中心的处理峰值，每天5亿的数据量请求的处理；每天有50万笔订单；均使用的分布式的系统；通过这个报告项目团队对现场的情况有了更为详细的了解，经过项目团队主要负责人会议充分讨论后，决定在需求文档里尽量使用图形来替代冗长枯燥的文字描述复杂的系统功能，最终通过评审，我们选择在需求分析时主要使用结构化分析方法，围绕数据字典建设、运用数据流图、状态转换图来进行需求分析工作。
数据流图的运用，为了向客户清楚地描述系统的那些功能部分组成，我们能利益DFD将产品的采集、接收、入库、分发、处理、转换、加工、校验、消息提醒几个模块的输入输出用一系列的处理连接起来，用图形符号准确地描述系统内各功能部件以及数据在它们之间的传递情况，简明易懂。在利用DFD分别对采集、解码、查重、业务分析、价格处理、详细入库推送到经销商以及集团官网上面售卖。通过DFD图进行数据处理进行分解，使得整个系统的复杂处理过程得以采用图形化的方式来描述，减少了大量篇幅的文字描述，使需求分析文档看起来非常简洁。同样我们用数据数据流图将在产品管理、订单管理、财务单据管理、信息流管理等系统进行了分解描述。使得整个需求文档看上去更加清晰，尽量避免让客户以及业务人员去看那些枯燥冗长的文章，让即使是不懂技术的客户、业务、研发、产品看完这些图，也能理解系统的数据处理过程。
状态转换图的运用。DFD仅仅描述了系统的功能组成部分以及功能之间的联系，而系统运行过程中需要对用户的状态做大量的批判，如产品的库存、价格情况、订单的支付金额、状态情况、上架的状态情况等等，这些状态判断依靠事件驱动，为将这些状态描述清楚，我们在需求分析过程中还使用了状态转换图，STD描述了系统如何在各种状态之间移动，如用户订购了A产品的订单，产生了A产品的费用，系统在分析时需要根据订单的属性将用户使用到的A订单产品解析出来，比如有机票、地接服务、门票等；然后进行各个单资源进行价格的计算。而当用户订购了A产品已经售卖为空，系统分析就会进行A产品的分析时显示订单产品异常，会有业务人员进行参与进来解决；通过使用STD，能清楚地描述了用户状态的转换过程，选择合理的输出。整个订单的下单过程非常复杂，需要分析判断的用户状态也非常多。
数据字典的运用。数据字典是结构化分析方法的核心，数据字典完成了DFD对数据详细内容无法具体、准确的描述，是对DFD的强力的补充。项目的数据结构非常的复杂，数据字典的设计要求非常高。包括系统域、产品域、资费域，控制域共涉及数据表300张。为了保证数据字典完整性和一致性，我安排了专门的数据库管理员对数据字典进行管理，项目团队任何人要调整数据字典都必须交由该专人进行调整，并且对所有的变更都必须有项目经理签字，变更记录必须邮件及时发送给其他团队负责人以及本组成员。为保障后续的数据割接工作不出问题，数据字典的涉及必须有系统的实际情况，为此，特地安排了2名现场维护人员参与数据字典涉及并负责后期的数据交割工作，一方面方便交流，另一方面可以充分考虑现场的实际情况并为后期的数据割接做足准备。
通过使用结构化方法，使得需求分析工作完成得非常顺利，需求分析的质量得到保证，对后续项目的顺利实施提供了有力的支撑。项目域2019年5月完成割接上线，在生产环境运行了3个月，各项指标性能达到了集团要求，并经受住了国庆假、五一节日黄金周的考验，订单的自动化问题、消息消费不及时的问题得到解决，最终通过了验收，项目获得了集团各层领导的好评。
在项目结束后的讨论会议上，大家也指出了项目中存在一些不足，如订单模块在性能上面没有达到预期的目标，导致的客户详单查收效率低下，上线后又经过了几轮优化处理，才在性能上面满足需求。另外，外围欸抽取订单详情数据时，没有一个可视化的数据流图，为此，我们不得不花费精力在下单的流程中添加日志的流程图日志处理，每个重要的节点会进行日志的记录，比如说，支付节点、出团书节点、库存、价格校验节点等，每个节点都会又详细的请求、响应日志以及时间响应的时长。为了后续的运维同事可以通过图形化的界面进行查看订单的实际情况。总的来说，这些问题主要还是需求分析时对订单功能模块考虑不够透彻，测试没有做彻底，埋下的隐患。所以，在以后的项目里面，需求分析质量得到保障的情况，还要把控好测试质量，把握好实施的每个细节。
