简介中国铁路窗口售票系统需求分析文档是一份面向软件工程学生、系统分析师及铁路售票系统开发人员的完整需求说明书适用于课程设计、毕业设计或实际项目前期的需求梳理。文档依据V3.0.0版本从系统总体目标和功能要求入手完整描述了前端界面、后端服务器与数据库组成的三层体系架构并详细分析了订票、改签、退票三大业务模块的流程以及基本票价与优惠票价的计算方法同时覆盖用户管理、支付服务、统计分析等辅助模块的需求。资源包内仅含1个docx文档大小约275KB目前已有581人学习。文档附有规范目录和修订记录从初稿到正稿的变更过程清晰可见读者可直接借鉴其需求分析框架和写作格式快速搭建自己的售票或类似交易系统的功能边界、业务流程与文档结构节省从零开始撰写需求报告的时间。1. 中国铁路窗口售票系统需求分析难的不是“卖票”是席位与结账中国铁路窗口售票系统需求分析听名字很像“一个卖票的增删改查”真正开工才发现百分之八十的精力要花在席位、票额、结账这三件事上。屏幕上一个“售”字点下去背后要回答座位是否允许跨区间复用、票额池是否充足、退票后额度什么时候回到池子、日终结账时钱和票能不能对平。这篇笔记按我习惯的顺序把这类需求分析拆开讲先划业务边界再定领域模型然后逐用例定义规则最后说评审怎么防止翻车。适合正在做交通、政务类交易系统的产品经理、需求分析师以及刚接需求的后端开发——新手能照着理清结构熟手可以直接对照查漏。2. 先划清业务边界涉众、外部接口与核心用例2.1 涉众与系统边界窗口售票到底“管”到哪一层需求分析最容易犯的第一个错是觉得“系统很简单一个界面加一张表就够了”。实际上窗口售票系统是所有票务渠道里对账要求最苛刻的一类因为它直接经手现金还牵扯到多名售票员在一个班次内的交接。我一般会在动手写用例之前先做一张涉众表把每个人在系统里要什么、怕什么写清楚。角色核心诉求常见担心售票员操作快、票号准、出错能补救最怕结账不平、说不清责任值班员 / 班组长授权异常、审核班组账最怕责任边界模糊票额管理人员票额计划可执行、限售规则生效最怕窗口乱卖打破计划财务 / 稽核流水与缴款对得上最怕渠道收款对不平系统维护号段分配、设备状态、离线恢复最怕票号重复、数据丢失涉众确认之后紧接着是系统边界。窗口售票系统不是一个孤岛它至少和四类外部对象打交道。第一是上级票务系统负责实时可售查询、票额扣减和票额计划下发这是最核心的依赖需求里必须写明它不可达时的降级口径。第二是互联网售票渠道二者共享票额池但不共享会话需求要定义清楚窗口售与线上售的优先级以及票额锁定、释放的口径。第三是支付渠道现金为主部分窗口接扫码和刷卡按自然日对账与按班次日对账的口径经常不一致。第四是车站的信息发布设备和窗口设备比如票卷打印机、证件阅读器、扫码枪。边界里更重要的部分是“不做什么”。常见做法是明确写出窗口售票系统不做列车运行图维护不做票额计划编制只接收和执行不做财务总账只产生流水与结账单不做车站大屏的实时刷写出票动作不触发大屏刷新。把“不做”写清楚需求评审时才能拦住那些“顺手加个功能”的请求。这些内容最终体现在文档的“系统上下文图”和“接口清单”里而不是只在会上口头对齐一遍就完事。2.2 核心用例与班次流程把需求按“班前—班中—班后”组织窗口业务是按“班”组织的不是按“天”组织的。同一名售票员从接班到交班是一个完整的业务周期需求如果按自然日拆后面做结账用例时一定会绕晕。所以我会把所有用例挂到“班前—班中—班后”三个阶段里每个阶段的数据状态不同班前是准备态班中是交易态班后是结算态。用例编号用例名称参与者核心流程简述典型异常UC-01售票售票员、旅客查询、选票、录入、收款、出票票额不足、打印失败UC-02退票售票员、旅客验票、算退费、退款、销账超时不可退、票已检UC-03改签售票员、旅客验票、选新车次、算差额、退旧出新新车无票、开车后UC-04废票售票员、值班员授权、作废、保留原联跨班次废票限制UC-05班结售票员、值班员汇总、对账、差异处理、签认差异超限UC-06余票查询售票员按条件展示可售数量上级系统不可达需求捕获阶段我一般会走四步。第一步是跟班观察站在窗口旁边记录售票员每一步操作和输入内容留意他用了哪些默认值、哪些快捷键访谈里听不到这些细节。第二步是分别访谈售票员、值班员、财务同一个问题要问三类人“错了怎么办”。第三步是收集实物单据包括客票样张、退票报销凭证、结账单、差异登记单。第四步是把流程转成用例草稿再让业务方对着异常分支逐条打钩确认。需求分析不是玄学是拿单据和异常把系统边界钉死的过程。3. 领域模型与票额规则需求分析里最容易翻车的地基3.1 票、票额、席位是三个概念别让业务方一句话带偏几乎所有翻车项目都死在把“票”当成库存字段。业务方问“还有票吗”系统里实际是三件事有没有可售票额、有没有可复用席位、当前是不是限售状态。需求分析要做的第一件事不是画界面而是定义术语表把下面这三个概念彻底分开。票是客票单据有票号、区间、车次、日期、席别、乘车人、票价它是交易的结果。票额是某车次某席别在特定区段的可用额度比如“某次列车硬卧在A站到B站之间可售40张”由票额计划决定用完就没了退票或改签后按规则回补。窗口看到的“余票数”是票额池口径不是车辆物理座位剩余。席位是物理的座位或铺位一个席位可以被不同区段的旅客分段使用但同一时段只能卖一段。实体关键字段归属方说明列车基础数据车次、停站、日期类型基础数据由上级系统下发票额计划车次、日期、席别、发到区间、额度、限售标记上级票务系统窗口只读席位资源车次、车厢、座位号、已分配区段车辆与票务窗口系统通常不直接操作客票票号、乘车人、区间、票价、票额快照票务系统票号全局唯一交易流水交易号、票号、操作员、类型、金额、渠道窗口系统与票一一对应术语表示例里要把“可售”、“复用”、“释放”、“回池”这些词的业务含义写死。比如“回池”指退票后票额恢复销售但恢复时机在不同车次上不一样再比如“可售”指票额池还有额度并不代表物理上一定有个空座位。这些词不定义清楚开发按自己的理解建模评审时业务方又默认开发懂业务两边对着一句话各说各话等系统上线才发现模型搭错了。3.2 席位复用与票额回收用规则参数表把“口头约定”钉死业务方经常说“这个车次的卧铺能复用那个不行”。这种口头约定如果不参数化开发就会写死在代码里后面每个车次要改一次需求文档里也没有任何依据可查。我的做法是在需求阶段直接产出一张业务规则参数表穷举当前业务方明确知道的规则逐条向票务人员确认取值和边界。参数编号参数名称取值示例默认值影响范围定义方R-01票额回收延时0 / 10 / 60 分钟0全部车次业务方R-02席位复用开关0 / 11按车次 席别业务方R-03限售区段车次 区间 席别 阈值无按车次票额管理R-04退票后原席位释放时机立即 / 班后立即全局业务方R-05手续费梯度H48h / 24h≤H≤48h / H24h5% / 10% / 20%全局客运规章每个参数都要说清楚“怎么问出来”。以 R-01 为例访谈时直接问“退一张票之后这个额度什么时候能再卖”对方回答“马上就能卖”就记 0 分钟回答“下一班再说”就记一个延时值或者“班后”。要让业务方在每个候选值上做选择而不是让他描述流程。R-02 的复用开关更细必须按车次加席别逐项确认因为一趟车的硬座能拆段卖卧铺未必能。这张参数表是需求文档的正式附录每条规则带“来源”规章文件、访谈记录或者票务人员签字确认。如果一条规则追不到出处就标成“待确认”绝不让开发自己猜。我见过最贵的一次返工就是开发默认“退票立即回池”结果业务方的真实规则是“开车前2小时内退的票当班次不再回池避免被同一旅客反复占票”上线当天就出了票额虚耗。4. 功能需求拆解从一次售票到日终结账的完整规则4.1 售票主用例字段、校验与异常分支逐项定义售票是这个系统的心脏。需求文档里只写“系统应支持售票”等于没写必须把字段、校验、异常分支全部定义到可直接开发的程度。下面是一张我常用的售票字段要求表评审时让业务方逐行确认。字段类型必填校验规则错误提示乘车日期日期是在预售期内超出预售期车次字符是存在于基础数据车次不存在发站 / 到站车站代码是停站表内且顺向区间不成立席别枚举是当前车次有该席别无此席别票种全价 / 儿童 / 学生 / 伤残是按证件与规章校验证件不符乘车人、证件类型、证件号字符是身份证加权校验校验位错误收款方式现金 / 扫码 / 银行卡是渠道可用渠道拒收每个字段的校验背后都有业务依据。比如学生票要看学生证区间和发证日期儿童票按年龄边界判断这些边界值必须写进需求用“6周岁”“14周岁”这样可验证的描述而不是“按国家规定”一句带过。证件类型是枚举身份证、护照、港澳台证件、其他身份证要做加权校验但窗口售票通常只录入不核验这一点也要写清楚避免开发额外做实名核验接口。异常分支比正常流程更重要。票额不足时怎么提示、是否推荐替代车次打印失败时票是否已经生成常见做法是先记录流水再补打需求里要明确“打印失败不算未售”支付超时后订单怎么处理锁定票额何时释放。另外窗口售票讲究全程键盘操作售票员双手不离开键盘光标默认落在日期或车次输入框这些交互要求如果不写开发只会做鼠标点选上线后售票效率直接砍半。4.2 退票、改签、废票金额计算规则必须单独成表这三类操作都涉及钱是需求里最容易埋雷的地方。我习惯按“场景”而不是按“功能按钮”来组织规则因为同一个按钮在不同时间条件下走的是完全不同的一套逻辑。场景条件手续费钱去哪审计要求开车前 48 小时以上退票未检票5%原路退回记录原票号开车前 24 至 48 小时退票未检票10%原路退回记录原票号开车前不足 24 小时退票未检票20%原路退回记录原票号开车后退票仅特殊原因且经授权另定窗口退款记录授权已检票退票不允许——提示手续费梯度的“边界”必须写小时数而不是“当天”“前一天”。我踩过一次坑需求写“开车前24小时内退票收20%”开发按自然日判断凌晨1点的车前一天晚上11点退票被收了20%实际距开车还有2小时按规则只能算“不足24小时”之外的低档。这就是边界定义不清的典型事故。另外手续费不足某金额按最低标准计这类附加规则也要单独列行。改签的账务处理和“退票加售票”完全不同。改签后原票作废、新票生成差额多退少补按新票价减旧票价计算新票价高时补款低时退款。手续费通常按退票规则计算差额部分。改签次数限制也要确认常见做法是每张票限改签一次、开车后不可改签。这里的关键细节是改签必须生成一条改签流水而不是“退票流水加售票流水”两条否则日终对账会把同一张票的钱重复计算。废票是当班售错或打印损坏时的补救手段必须有值班员授权保留原票、新票和授权记录。废票不参与营收统计但必须进审计。需求要明确限制跨班次废票否则第二天发现昨天卖错了来废票账就说不清。4.3 日终结账钱、票、流水三者对平的要点窗口售票员最怕结账不平。需求分析要把结账流程拆到和售票用例一样细每一步的数据来源和计算公式都要写清楚。班结流程常见做法拆成六步汇总当日交易售票 N 张、金额 A退票 M 张、金额 B改签差额 C废票 K 张按现金、扫码、银行卡分渠道汇总收款计算应缴金额 售票收入 - 退款支出 - 改签退款 改签补收 - 废票原金额清点实缴现金登记长短款差异在阈值内允许挂账超阈值报值班员授权处理打印结账单、签认、上传流水每个步骤都要回答两个问题数据从哪来口径是什么。最容易出错的是支付渠道的对账口径扫码和银行卡的“结算日”与“交易发生日”不是同一天结账时按自然日还是按班次日汇总必须让财务拍板并且写进需求文档。如果窗口的现金由多人共用一台收款机还要定义“共用现金池”和“个人应缴”的拆分规则否则金额对不平就不知道是哪个环节漏了。网络中断时结账是否继续也要明确。常见做法是允许本地结账生成带本地标识的结账单网络恢复后补传流水再按上传成功重新确认一次。需求里要把“本地结账”和“正式结账”两个状态区分开避免恢复后重复提交。4.4 非功能需求底线并发、一致性、离线应急窗口系统并发量不高但不容错因为票额扣减是全局共享的热点。并发估算可以按站台式来测比如一个车站同时开 20 个窗口每个窗口每隔 2 分钟完成一次出票峰值就是每分钟 10 笔左右但每次扣减都要在上级票务系统上完成所以响应时间才是瓶颈。常见要求是扣减接口响应时间不超过 800 毫秒票额锁定超时 60 秒自动释放防止同一旅客在多个窗口反复占票不付。一致性是窗口系统的生命线。出票与扣减必须在一个事务里完成退票的状态变更与退款登记不能分两条链路改签更不能“先退再售”两步落库。这些要在需求里的“事务边界”一节写明否则开发做成异步就对不上了。离线应急也要提前定上级票务系统不可达时用本地缓存的票额计划继续售票但限定可售总额恢复后按本地流水号与全局流水号的映射关系补传离线期间退票和改签通常停办或经值班员授权办理。数据保留方面交易流水和结账单要按规章要求长期保留废票和授权记录全审计。非功能需求不要写成“系统应快速、可靠”要写成可测的量化描述。比如“扣减超时后系统自动重试最多重试 2 次第 3 次仍未成功则提示售票员系统繁忙并保留本地草稿”。这样评审时开发才知道要怎么设计测试才知道怎么验收。5. 窗口售票系统需求分析避坑指南5个血泪案例5.1 案例一票额“可售”与“可复用”没区分现象某项目上线后旅客投诉“这趟车明明还有空位却买不到票”内部测试又发现系统可售数与实载数对不上甚至出现两个区段售出同一个座位号。原因需求阶段只有“剩余票数 座位数 - 已售票”这一层理解没定义区间复用和票额池开发直接拿物理座位做库存。解决需求文档补上了“票额与席位”术语定义和复用规则参数表评审时请票务人员逐车次确认复用开关。以后凡是票务类需求我都会先问一句“卖的是额度还是座位”。5.2 案例二退票手续费边界用了自然日现象乘客凌晨 1 点的车前一天晚上 11 点退票系统收了 20% 手续费乘客投诉“还有两个小时才开车凭什么按最贵的收”。原因需求写“开车前 24 小时内退票收 20%”没规定按小时数计算开发按自然日的“今天/明天”判断。解决规则改为按距开车小时数 H 分档H 小于 24 收 20%H 在 24 到 48 之间收 10%H 大于 48 收 5%并在需求里附三个边界示例。这条后来被我写进了模板凡是带“内、前、后”的时间规则一定要追问边界怎么算。5.3 案例三结账差异没有处理路径现象上线一周售票员每天现金多几块或少几块系统只显示“不平”没有登记入口只能纸质记录财务不认。原因访谈只聊了正常结账流程没问“长短款怎么办”需求漏了差异处理用例。解决需求增加“差异登记 / 授权挂账 / 追缴退补”流程定义阈值比如 10 元以内挂账超限报值班员处理。系统补上这个功能之后售票员才敢正常下班。5.4 案例四票号段未分配两个窗口重复出票现象某站两个窗口同时出票出现了相同票号后续退票和审计全部混乱。原因需求定义了“票号唯一”但没有定义号段由谁分配、何时下发、离线时怎么办。解决需求写明票号段由票务系统统一分配窗口在班前下载本班次可用号段离线时使用本地预置号段并记录起止号。做这行久了凡是需求里出现“唯一”两个字我都会追问一句“唯一性靠什么保证”。5.5 案例五“加个备注字段”改坏了账务统计现象业务方要求退票单加一个备注字段开发直接给客票表加了列导致日终汇总口径全变财务报表对不上。原因变更没走需求评审没人判断字段该挂在客票上还是退票流水上也没评估对结账统计的影响。解决需求文档里增加变更登记页每次变更必须写明影响实体、影响哪些报表、是否影响票号唯一性评审通过才允许动工。6. 需求文档怎么才算合格评审清单与可验证指标6.1 评审清单10分钟检查需求能不能落地我习惯在评审会开始前用一张固定清单扫一遍需求文档。清单不长但每项都能拦住一类问题。检查项常见失败表现合格标准术语表没有或只解释名词票、票额、席位三者定义分明用例异常分支只有主流程每个用例至少 3 条异常路径规则参数来源开发自定默认值每条规则带定义方和出处三个关键标识没定义唯一性票号、流水号、操作员号唯一性路径明确结账口径没写按什么周期按班次日、渠道结算口径写清离线应急没写降级方案每个核心用例有离线表现说明变更记录只有最新版有历史版本和变更登记页评审组织也有讲究。业务评审请“干过窗口的人”来技术评审请“写过交易系统的人”来两类问题不要混在一场会里。业务评审抓规则抓边界比如“开车后到底能不能改签”技术评审抓一致性和事务边界比如“扣减票额和生成客票是不是同一个事务”。混在一起的结果通常是业务方和技术方互相打断一上午开完什么都没定。6.2 验收指标用测试场景反推需求完整性评审清单能查文档的“形”但查不出逻辑漏洞。我一般再走一道工序把核心业务规则写成可验证的验收场景让开发照着场景过一遍需求文档缺哪补哪。验收场景输入预期结果对应需求条款区间复用A-B 区间售出一张查询 B-C 区间B-C 仍可购可售数不变票额模型与复用规则退费梯度距开车 2 小时退票手续费按 H24 档收 20%退票手续费参数表离线售票断网后继续售票本地限额内可售恢复后流水补齐离线应急差异挂账结账现金多 10 元系统登记差异、值班员授权挂账结账差异处理并发抢票两窗口同时抢最后一张票一人成功一人提示票额不足并发与一致性这套场景同时也是给测试团队验收用的。需求文档里能抽出多少个这样的可执行场景比任何评审清单都能说明文档质量。做这类需求分析我最深的教训是别把“有票吗”当成一个简单字段别把“按标准来”当成一条需求。窗口售票的规则绕、账务绕、交接绕一份合格的需求文档能让三年后接手的人不打电话问业务方。我的习惯是每一条规则都追到出处追不到的标成待确认绝不让开发猜。希望这份拆解能帮到你的项目少踩几个坑。本文还有配套的精品资源点击获取