简介一份完整的图书管理系统需求分析报告面向软件工程学习者、系统分析师、产品经理与开发人员适合课程设计、毕业设计或实际项目前期需求建模使用。报告以引言、项目背景、相关定义开篇明确系统目标、用户类特征及Windows/Linux与多种数据库的运行环境需求分析部分重点展开数据需求、事务需求、业务流程图、数据流程图和数据字典对图书信息、借阅信息、读者信息等数据结构做出定义并覆盖借阅图书、归还图书、编目、分类、检索、统计等核心用例说明权限检查、可借阅性校验等关键规则随后还补充性能需求、故障处理及硬件/软件外部接口要求形成从需求提取到用例文档的完整链条。资源包共1个doc文件大小161KB目录结构清晰适合对照学习需求分析文档的写作规范、流程建模方法以及用例设计思路。已有7998人学习可作为图书管理系统相关设计与开发工作的参考模板。1. 图书管理系统需求分析报告的核心是“借与还”之外的那些默认假设一个图书管理系统业务上无非是采编、借还、预约、罚款、统计这几条线。可真把需求分析报告摊开开发、测试和业务方最容易吵架的地方不是界面长什么样而是“这本书能不能借、什么时候能借、谁有权限改它的状态”。读者以为预约成功就等于拿到书管理员以为先到先得开发则会追问“预约时到底锁不锁副本”。这些默认假设如果不写进报告到联调阶段改一个字段就意味着返工一张表。所以需求分析报告的价值不是提交一份文档交差而是把角色、流程、数据和异常分支定成一份开发照着做、测试照着验、业务方看了说“对这就是我要的”的契约。这篇从用例拆解、数据建模、非功能性需求到报告自检依次展开给出可直接落到文档里的写法。2. 从业务到用例图书管理系统的角色边界与流程取舍2.1 先定角色再谈权限图书管理系统里的三类参与者需求分析收到的原始需求往往是“能借书、能还书、能查书、能管理图书”。第一件事是把主语划出来。图书管理系统的用户角色一般超不过三类读者借阅者、图书管理员操作前台借还、处理上架、系统管理员维护基础数据和权限。只有在高校分馆或总分馆体系里才需要单独拆出“采编员”和“馆际互借员”。角色不是在用例图上多画几个小人而是决定了后续权限矩阵的粒度。角色核心职责常见误设读者检索、预约、借阅记录查询、个人资料维护把“自助借还”写成读者直接改库存状态图书管理员借还办理、图书上架与下架、读者违规处理、罚款收取把管理员做成拥有全部权限的超级账号系统管理员基础数据维护、系统参数配置、操作日志审计允许管理员级别的角色删除借阅历史角色和权限分离是这阶段就要定的。把“图书管理员”和“系统管理员”合并成一个角色后期加一个“图书盘点”功能时就得回头改权限表。常见做法是在报告里画一张角色用例图再配一张权限矩阵矩阵的横轴是功能模块纵轴是角色单元格写“可操作/只读/不可见”。2.2 用例粒度拆到“用户目标级”不要拆成界面操作用例图里最容易犯的错是把每个点击动作都画成一个用例。“点击借书按钮”“扫描条形码”“确认借阅人身份”是从机角度拆分不是从用户目标拆分。用户的目标是“借到这本书”管理员的目标是“完成本次借阅”。所以“借书”是一个用例而扫描条形码、校验读者资格、扣减可借额度都是它的基本流步骤。下面是一份可以直接抄进需求规格的用例规约建议以代码块的形式放进报告正文而不是丢在附录里用例编号UC-BORROW-01 用例名称读者借书线下服务台办理 参与者读者、图书管理员 前置条件 1. 读者已完成注册且账号状态为“正常” 2. 图书管理员已登录借还工作台 基本流 1. 读者持实体图书到服务台 2. 管理员扫描图书条形码系统读取副本信息 3. 系统校验读者状态未注销、未被停借 4. 系统校验副本状态为“在馆”且未被预约 5. 系统创建借阅记录将副本状态改为“借出” 6. 系统累加读者在借数量并打印借阅凭证 替代流 2a. 条形码磨损无法识别转人工输入馆藏编号 3a. 读者有逾期未还的图书系统提示“需先归还或缴纳罚款” 4a. 副本状态为“预约中”系统提示“该书已被其他读者预约不可外借” 异常流 5a. 创建借阅记录失败回滚副本状态变更不产生部分更新 后置条件 副本状态为“借出”借阅记录状态为“借出”读者在借数量增加 1用例编号建议按“UC-业务域-序号”的规则业务域用 BORROW、RETURN、RESERVE、FINE、QUERY 这类英文词。前置条件里不要写“系统时间正确”“网络正常”这类无关条件它们属于运维保障。基本流必须和报告里的业务流程图一致且每一行都能对应到后面数据字典里的至少一个字段。用例规约写到位了开发写代码时基本不需要再猜业务规则。2.3 流程图的替代方案用“步骤-数据-异常”三列表格把流程写死很多需求分析报告都会画业务流程图但流程图在评审时很难逐行核对。我一般会在报告里同时放一张三列流程表代替部分难以导航的跨页流程图也便于测试用例的编写。表格的每一行对应一个操作步骤数据列负责明确这一步骤涉及哪些数据异常列说明这个步骤可能中断的条件。以“还书”流程为例步骤执行动作涉及数据异常分支1管理员扫描图书条形码副本号条形码不存在且无法找到匹配记录2系统查询未归还借阅记录副本号、读者号无在借记录提示“该书未处于借出状态”3系统计算是否逾期应还日期、当前日期无异常分支逾期仅触发罚款计算4系统更新副本状态为“在馆”副本状态更新失败则整体回滚5系统写入归还时间和超期信息归还时间、逾期天数逾期天数大于 0 时生成待缴罚款单写这张表的时候要特别注意第 3 步中的“当前日期”是自然日还是工作日。有的高校图书馆允许节假日顺延那“应还日期”就不是简单加 30 天而是加 30 个有效开放日。这个规则如果不写清楚开发通常会用最朴素的自然日计算上线后一到国庆长假就会产生投诉。3. 数据建模与需求映射E-R 图、数据字典和参数规格3.1 从用例到 E-R 图先分清“书目”和“副本”图书管理系统数据建模中最容易踩的第一个坑是把“书名”当成图书的唯一标识。同一个 ISBN 对应同一本书但图书馆会采购多本复本每本复本有自己的条形码。所以核心实体至少要拆成三个书目book、馆藏副本book_copy、借阅记录borrow_record。E-R 图里要体现的关系是一个书目对应多个馆藏副本一个馆藏副本对应多条借阅记录一个读者对应多条借阅记录。报告正文里可以用实体关系描述代替图形绘制例如读者(1)—(N)借阅记录(N)—(1)使馆藏副本(N)—(1)书目。这句话比画一整页 E-R 图更能直达开发。数据字典里馆藏副本表的关键字段可以这样定义CREATE TABLE book_copy ( copy_id BIGINT PRIMARY KEY COMMENT 条形码/副本唯一标识, isbn CHAR(13) NOT NULL COMMENT ISBN对应书目表, book_title VARCHAR(200) NOT NULL COMMENT 冗余书名用于列表展示, status TINYINT NOT NULL DEFAULT 0 COMMENT 0在馆 1借出 2预约中 3待上架 4剔旧下架, location VARCHAR(50) COMMENT 馆藏位置例如 社科A区-3排-2架, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_isbn (isbn), KEY idx_status (status) );为什么把 book_title 冗余在 book_copy 表里因为借还列表和馆藏查询都要展示书名冗余字段可以避免每次 join 书目表。代价是书目改名时需要同步更新但图书管理场景里书名极少改动这个冗余是划算的。status 字段用 TINYINT 而不是字符串是为了节约存储和索引空间应用层用枚举常量做映射。location 字段一定要给示例值否则业务方验收时会发现界面显示了“A区1排”还是“A-1-1”又成了一场讨论。3.2 借阅记录的数据字典要把“应还日期”写成一个字段借阅记录是图书管理系统里事务性最强的表。很多初版需求会把“借期 30 天”写在规则说明里而表结构里只有借出时间。开发实现时每一种查询都要用 DATE_ADD(borrowed_at, INTERVAL 30 DAY) 去推应还日期。这个写法的隐患是一旦规则改成“不同读者类型不同借期”所有 SQL 都要跟着改。正确做法是在需求分析阶段就定义借阅记录表包含“应还日期”字段。CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, copy_id BIGINT NOT NULL COMMENT 所借副本ID不能直接引用书目ID, reader_id BIGINT NOT NULL COMMENT 读者ID, borrowed_at DATETIME NOT NULL COMMENT 借出时间, due_at DATETIME NOT NULL COMMENT 应还时间由借期规则计算后写入, returned_at DATETIME NULL COMMENT 实际归还时间NULL表示未还, renew_count TINYINT NOT NULL DEFAULT 0 COMMENT 已续借次数, status TINYINT NOT NULL DEFAULT 1 COMMENT 1借出 2已还 3逾期, KEY idx_reader_status (reader_id, status), KEY idx_due_at (due_at) );这里的核心设计是业务规则产生的计算结果到期日、罚款金额在写入时固化。需求文档里写明“续借操作会基于新的到期时间重新计算 due_at 并更新 renew_count”开发实现就无须在查询时动态计算。逾期判断也简化成 returned_at IS NULL AND due_at NOW()。测试用例里构造一条逾期记录只要插入一个过去的时间点不需要去调整数据库时间。3.3 业务规则表把“罚款、预约、续借”的数字全部提前锁死借阅规则是需求分析报告里必须用参数表形式呈现的部分。常见做法是把所有可由管理人员修改的规则统一配置化避免后续业务调整时频繁改代码。下表是建议的规则参数清单参数项默认值说明配置位置读者最大借阅数10达到上限后不可再借读者类型配置借期天数30从借出日当天起算自然日读者类型配置续借次数上限1续借成功后重新计算到期日图书类型配置续借借期天数30自续借日起算图书类型配置预约保留天数3到馆后为预约读者保留的天数全局参数逾期日罚款金额0.1按自然日计算单位为元全局参数停借阈值5累计逾期超过该天数时暂停借阅全局参数最大预约数3单读者未完成的预约数量上限读者类型配置这些参数在需求阶段就要明确“谁可以改”。如果业务方要求“这些参数管理员自己能在后台改”那报告里就要增加一个参数配置模块的用例而不是把这些值硬编码在系统设计里。预约场景里还有一个容易被忽略的细节预约成功后系统要不要自动给读者发通知通知方式是什么这直接决定是否要接入短信或邮件网关需求分析阶段漏掉开发后期补会很被动。4. 非功能性需求并发、权限与备份参数不写进报告验收时无据可依4.1 图书管理系统的权限设计要从“菜单级”下沉到“操作级”图书馆管理系统的权限误区是把权限等同于界面菜单显隐。真实场景里图书管理员和采编员可能都能进入图书管理页面但前者只能修改馆藏状态后者能编辑书目信息。需求分析报告里的权限矩阵应写明操作级权限包括新增、修改、删除、导出、审核。这里给出一个简化的权限矩阵示例功能模块读者图书管理员系统管理员书目检索可操作可操作可操作图书借还不可见可操作只读罚款处理可查看自己的可操作可操作读者管理修改本人资料可操作可操作系统参数不可见只读可操作操作日志不可见不可见只查询这套矩阵要能对应到实现端的 RBAC 模型。报告里应写一句后端接口校验基于角色权限码前端隐藏菜单仅作为用户体验优化不作为安全边界。这一句写出来开发不会再说“页面上没有入口所以接口不用防护”。4.2 并发量怎么估借还业务是低并发检索和预约才是压力点需求分析报告里的性能指标经常写成“系统需支持高并发”这种词必须量化。图书管理系统的典型使用场景是图书馆开馆后和闭馆前半小时以及选课季教材集中借阅。以一个本科生规模 2 万人的高校为例集中借阅峰值大约出现在开学前三天全馆日均借还量 3000 笔峰值小时大概是 500 笔。按一小时 3600 秒算每秒不到 0.14 个事务。真正需要关注的是书目检索接口它会同时被全部在线读者使用高峰并发可能在几十到几百 QPS。所以性能需求应拆成接口级指标而不是一个笼统的数字。示例如下接口/场景预估峰值目标响应时间说明借书接口30 笔/分钟P95 1 秒事务性操作需保证数据一致性书目检索100 QPSP95 500 毫秒可加缓存全文检索需考虑 Elasticsearch读者借阅历史查询20 QPSP95 1 秒分页查询避免全表扫描预约请求5 笔/秒成功返回 2 秒需要处理并发抢最后一本副本的场景图书管理系统一般不需要引入消息队列和分库分表。但如果需求里有“预约热门书籍”的功能就要在需求分析报告里明确一个规则同一时间多位读者预约同一本书时以预约提交时间为准当预约副本释放时通知排序最靠前的读者。这个规则如果不写开发大概率会用先到先得的普通查询实现并在读多写少的场景下产生超卖问题。4.3 备份策略从第一天就要写RPO/RTO 优于备份频率校图书馆这类系统的数据丢失后果很严重但需求分析报告里经常只有一句“定期备份”。建议写成可验收的参数备份频率、保留周期、恢复时间目标。示例参数表如下指标建议值验收方式数据备份频率每日全量 每 30 分钟增量查看备份任务日志全量备份保留时间30 天检查备份存储增量日志保留时间7 天检查存储清理任务RTO恢复时间目标4 小时演练恢复计时RPO恢复点目标30 分钟备份间隔确认报告里还可以附一个备份脚本策略让运维确认时间窗口是否合适# 每天 02:30 执行全量备份保留 30 天 30 2 * * * /opt/backup/full_backup.sh --retain30 # 每 30 分钟归档 binlog保留 7 天 */30 * * * * /opt/backup/archive_binlog.sh --keep7d图书管理系统大部分使用 MySQL 存储备份窗口建议选在闭馆后和开馆前避免备份期间的锁表影响借还业务。RPO 30 分钟意味着最多丢失半小时内的借还记录这个指标要业务方确认因为罚款金额和借阅状态如果丢失补录成本极高。4.4 审计日志谁在什么时间改了书的状态图书管理系统涉及罚款和账目管理员操作必须可追溯。需求报告里要包含审计需求记录操作人、操作时间、操作类型、变更前值、变更后值、IP 地址和应用模块。审计日志只追加不修改并单独存储不与应用数据同库。这里的关键点是报告必须明确哪些操作需要审计借还书、罚款修改、读者状态变更、删除书目。常见做法是建议业务表更新时自动写入审计表而不是由业务代码手动记录避免漏记。5. 报告写完后如何自检需求追溯表、原型走查与三查法5.1 用需求追溯表把每条需求落到用例和验收标准报告初稿完成后我会先建一张需求追溯表它是一份一页纸的清单列为“需求编号、需求描述、来源、关联用例、对应页面/原型、验收指标”。追溯表不仅方便自查遗漏也是测试用例设计的来源。下面是一段示例需求编号需求描述来源关联用例原型位置验收指标RF-LEND-001读者可以借阅在馆状态的图书副本访谈记录-读者-03UC-BORROW-01借书页面标注“在馆”标签借出后副本状态可见为“借出”RF-RESV-002预约成功后系统提示预计可借时间访谈记录-管理员-07UC-RESERVE-01预约结果页生成预约记录并显示排名RF-FINE-001逾期归还自动计算罚款金额会议纪要-图书馆-05UC-FINE-01个人借阅明细页逾期 1 天产生对应罚金如果某条需求无法对应到任何用例或原型需要回头补全如果某个用例在追溯表里找不到需求来源则要判断是否属于额外设计。这能防止需求分析报告变成一堆功能的堆砌。5.2 三查法查完整性、查可测性、查异常路径写需求报告时我自己执行“三查法”一查流程完整性二查指标可测性三查异常分支。查完整性是走链路从“读者检索书目”开始到“读者归还图书收到罚款单”结束把这条主链路涉及的每个小环节列出来看是否有需求缺口。常见漏项是“还书时发现副本已被人预约要转入预约到馆处理”这个分支以及“读者注销前有在借图书未归还”的处理。可测性是看每个需求是否包含动作、条件和预期结果。比如“书名支持模糊检索”不是可测需求应改成“输入书名关键字后系统返回题名包含该关键词且状态为在馆的书目列表”。异常路径看的是报告里每个用例的替代流和异常流是否覆盖了权限不足、数据不存在、状态冲突这三类问题。用例的异常流从哪来从业务访谈中让业务方回忆真实工作中遇到过的卡壳场景而不是开发自己臆想。5.3 用原型走查替代文档评审让业务方在界面上挑毛病需求分析报告写得再好业务方也未必能理解用例图和数据字典。我的习惯是把报告中的用例、流程和参数表转成一版可点击的低保真原型然后在评审会上按业务流程走查。从检索页面进入点击某本书尝试预约切到管理员账号处理预约到馆每一步都对照需求追溯表验证。只要流程走得通业务方确认签字后这份报告才能真正成为开发依据。最后在提交报告前把追溯表和参数表打印出来对照测试用例模板逐项过一遍。凡是测试人员看了不知道如何构造数据的需求一律改写。这比在开发评审时争论规则更省钱。本文还有配套的精品资源点击获取 图书管理系统需求分析怎么写：从用例拆解到数据建模实战
简介一份完整的图书管理系统需求分析报告面向软件工程学习者、系统分析师、产品经理与开发人员适合课程设计、毕业设计或实际项目前期需求建模使用。报告以引言、项目背景、相关定义开篇明确系统目标、用户类特征及Windows/Linux与多种数据库的运行环境需求分析部分重点展开数据需求、事务需求、业务流程图、数据流程图和数据字典对图书信息、借阅信息、读者信息等数据结构做出定义并覆盖借阅图书、归还图书、编目、分类、检索、统计等核心用例说明权限检查、可借阅性校验等关键规则随后还补充性能需求、故障处理及硬件/软件外部接口要求形成从需求提取到用例文档的完整链条。资源包共1个doc文件大小161KB目录结构清晰适合对照学习需求分析文档的写作规范、流程建模方法以及用例设计思路。已有7998人学习可作为图书管理系统相关设计与开发工作的参考模板。1. 图书管理系统需求分析报告的核心是“借与还”之外的那些默认假设一个图书管理系统业务上无非是采编、借还、预约、罚款、统计这几条线。可真把需求分析报告摊开开发、测试和业务方最容易吵架的地方不是界面长什么样而是“这本书能不能借、什么时候能借、谁有权限改它的状态”。读者以为预约成功就等于拿到书管理员以为先到先得开发则会追问“预约时到底锁不锁副本”。这些默认假设如果不写进报告到联调阶段改一个字段就意味着返工一张表。所以需求分析报告的价值不是提交一份文档交差而是把角色、流程、数据和异常分支定成一份开发照着做、测试照着验、业务方看了说“对这就是我要的”的契约。这篇从用例拆解、数据建模、非功能性需求到报告自检依次展开给出可直接落到文档里的写法。2. 从业务到用例图书管理系统的角色边界与流程取舍2.1 先定角色再谈权限图书管理系统里的三类参与者需求分析收到的原始需求往往是“能借书、能还书、能查书、能管理图书”。第一件事是把主语划出来。图书管理系统的用户角色一般超不过三类读者借阅者、图书管理员操作前台借还、处理上架、系统管理员维护基础数据和权限。只有在高校分馆或总分馆体系里才需要单独拆出“采编员”和“馆际互借员”。角色不是在用例图上多画几个小人而是决定了后续权限矩阵的粒度。角色核心职责常见误设读者检索、预约、借阅记录查询、个人资料维护把“自助借还”写成读者直接改库存状态图书管理员借还办理、图书上架与下架、读者违规处理、罚款收取把管理员做成拥有全部权限的超级账号系统管理员基础数据维护、系统参数配置、操作日志审计允许管理员级别的角色删除借阅历史角色和权限分离是这阶段就要定的。把“图书管理员”和“系统管理员”合并成一个角色后期加一个“图书盘点”功能时就得回头改权限表。常见做法是在报告里画一张角色用例图再配一张权限矩阵矩阵的横轴是功能模块纵轴是角色单元格写“可操作/只读/不可见”。2.2 用例粒度拆到“用户目标级”不要拆成界面操作用例图里最容易犯的错是把每个点击动作都画成一个用例。“点击借书按钮”“扫描条形码”“确认借阅人身份”是从机角度拆分不是从用户目标拆分。用户的目标是“借到这本书”管理员的目标是“完成本次借阅”。所以“借书”是一个用例而扫描条形码、校验读者资格、扣减可借额度都是它的基本流步骤。下面是一份可以直接抄进需求规格的用例规约建议以代码块的形式放进报告正文而不是丢在附录里用例编号UC-BORROW-01 用例名称读者借书线下服务台办理 参与者读者、图书管理员 前置条件 1. 读者已完成注册且账号状态为“正常” 2. 图书管理员已登录借还工作台 基本流 1. 读者持实体图书到服务台 2. 管理员扫描图书条形码系统读取副本信息 3. 系统校验读者状态未注销、未被停借 4. 系统校验副本状态为“在馆”且未被预约 5. 系统创建借阅记录将副本状态改为“借出” 6. 系统累加读者在借数量并打印借阅凭证 替代流 2a. 条形码磨损无法识别转人工输入馆藏编号 3a. 读者有逾期未还的图书系统提示“需先归还或缴纳罚款” 4a. 副本状态为“预约中”系统提示“该书已被其他读者预约不可外借” 异常流 5a. 创建借阅记录失败回滚副本状态变更不产生部分更新 后置条件 副本状态为“借出”借阅记录状态为“借出”读者在借数量增加 1用例编号建议按“UC-业务域-序号”的规则业务域用 BORROW、RETURN、RESERVE、FINE、QUERY 这类英文词。前置条件里不要写“系统时间正确”“网络正常”这类无关条件它们属于运维保障。基本流必须和报告里的业务流程图一致且每一行都能对应到后面数据字典里的至少一个字段。用例规约写到位了开发写代码时基本不需要再猜业务规则。2.3 流程图的替代方案用“步骤-数据-异常”三列表格把流程写死很多需求分析报告都会画业务流程图但流程图在评审时很难逐行核对。我一般会在报告里同时放一张三列流程表代替部分难以导航的跨页流程图也便于测试用例的编写。表格的每一行对应一个操作步骤数据列负责明确这一步骤涉及哪些数据异常列说明这个步骤可能中断的条件。以“还书”流程为例步骤执行动作涉及数据异常分支1管理员扫描图书条形码副本号条形码不存在且无法找到匹配记录2系统查询未归还借阅记录副本号、读者号无在借记录提示“该书未处于借出状态”3系统计算是否逾期应还日期、当前日期无异常分支逾期仅触发罚款计算4系统更新副本状态为“在馆”副本状态更新失败则整体回滚5系统写入归还时间和超期信息归还时间、逾期天数逾期天数大于 0 时生成待缴罚款单写这张表的时候要特别注意第 3 步中的“当前日期”是自然日还是工作日。有的高校图书馆允许节假日顺延那“应还日期”就不是简单加 30 天而是加 30 个有效开放日。这个规则如果不写清楚开发通常会用最朴素的自然日计算上线后一到国庆长假就会产生投诉。3. 数据建模与需求映射E-R 图、数据字典和参数规格3.1 从用例到 E-R 图先分清“书目”和“副本”图书管理系统数据建模中最容易踩的第一个坑是把“书名”当成图书的唯一标识。同一个 ISBN 对应同一本书但图书馆会采购多本复本每本复本有自己的条形码。所以核心实体至少要拆成三个书目book、馆藏副本book_copy、借阅记录borrow_record。E-R 图里要体现的关系是一个书目对应多个馆藏副本一个馆藏副本对应多条借阅记录一个读者对应多条借阅记录。报告正文里可以用实体关系描述代替图形绘制例如读者(1)—(N)借阅记录(N)—(1)使馆藏副本(N)—(1)书目。这句话比画一整页 E-R 图更能直达开发。数据字典里馆藏副本表的关键字段可以这样定义CREATE TABLE book_copy ( copy_id BIGINT PRIMARY KEY COMMENT 条形码/副本唯一标识, isbn CHAR(13) NOT NULL COMMENT ISBN对应书目表, book_title VARCHAR(200) NOT NULL COMMENT 冗余书名用于列表展示, status TINYINT NOT NULL DEFAULT 0 COMMENT 0在馆 1借出 2预约中 3待上架 4剔旧下架, location VARCHAR(50) COMMENT 馆藏位置例如 社科A区-3排-2架, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_isbn (isbn), KEY idx_status (status) );为什么把 book_title 冗余在 book_copy 表里因为借还列表和馆藏查询都要展示书名冗余字段可以避免每次 join 书目表。代价是书目改名时需要同步更新但图书管理场景里书名极少改动这个冗余是划算的。status 字段用 TINYINT 而不是字符串是为了节约存储和索引空间应用层用枚举常量做映射。location 字段一定要给示例值否则业务方验收时会发现界面显示了“A区1排”还是“A-1-1”又成了一场讨论。3.2 借阅记录的数据字典要把“应还日期”写成一个字段借阅记录是图书管理系统里事务性最强的表。很多初版需求会把“借期 30 天”写在规则说明里而表结构里只有借出时间。开发实现时每一种查询都要用 DATE_ADD(borrowed_at, INTERVAL 30 DAY) 去推应还日期。这个写法的隐患是一旦规则改成“不同读者类型不同借期”所有 SQL 都要跟着改。正确做法是在需求分析阶段就定义借阅记录表包含“应还日期”字段。CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, copy_id BIGINT NOT NULL COMMENT 所借副本ID不能直接引用书目ID, reader_id BIGINT NOT NULL COMMENT 读者ID, borrowed_at DATETIME NOT NULL COMMENT 借出时间, due_at DATETIME NOT NULL COMMENT 应还时间由借期规则计算后写入, returned_at DATETIME NULL COMMENT 实际归还时间NULL表示未还, renew_count TINYINT NOT NULL DEFAULT 0 COMMENT 已续借次数, status TINYINT NOT NULL DEFAULT 1 COMMENT 1借出 2已还 3逾期, KEY idx_reader_status (reader_id, status), KEY idx_due_at (due_at) );这里的核心设计是业务规则产生的计算结果到期日、罚款金额在写入时固化。需求文档里写明“续借操作会基于新的到期时间重新计算 due_at 并更新 renew_count”开发实现就无须在查询时动态计算。逾期判断也简化成 returned_at IS NULL AND due_at NOW()。测试用例里构造一条逾期记录只要插入一个过去的时间点不需要去调整数据库时间。3.3 业务规则表把“罚款、预约、续借”的数字全部提前锁死借阅规则是需求分析报告里必须用参数表形式呈现的部分。常见做法是把所有可由管理人员修改的规则统一配置化避免后续业务调整时频繁改代码。下表是建议的规则参数清单参数项默认值说明配置位置读者最大借阅数10达到上限后不可再借读者类型配置借期天数30从借出日当天起算自然日读者类型配置续借次数上限1续借成功后重新计算到期日图书类型配置续借借期天数30自续借日起算图书类型配置预约保留天数3到馆后为预约读者保留的天数全局参数逾期日罚款金额0.1按自然日计算单位为元全局参数停借阈值5累计逾期超过该天数时暂停借阅全局参数最大预约数3单读者未完成的预约数量上限读者类型配置这些参数在需求阶段就要明确“谁可以改”。如果业务方要求“这些参数管理员自己能在后台改”那报告里就要增加一个参数配置模块的用例而不是把这些值硬编码在系统设计里。预约场景里还有一个容易被忽略的细节预约成功后系统要不要自动给读者发通知通知方式是什么这直接决定是否要接入短信或邮件网关需求分析阶段漏掉开发后期补会很被动。4. 非功能性需求并发、权限与备份参数不写进报告验收时无据可依4.1 图书管理系统的权限设计要从“菜单级”下沉到“操作级”图书馆管理系统的权限误区是把权限等同于界面菜单显隐。真实场景里图书管理员和采编员可能都能进入图书管理页面但前者只能修改馆藏状态后者能编辑书目信息。需求分析报告里的权限矩阵应写明操作级权限包括新增、修改、删除、导出、审核。这里给出一个简化的权限矩阵示例功能模块读者图书管理员系统管理员书目检索可操作可操作可操作图书借还不可见可操作只读罚款处理可查看自己的可操作可操作读者管理修改本人资料可操作可操作系统参数不可见只读可操作操作日志不可见不可见只查询这套矩阵要能对应到实现端的 RBAC 模型。报告里应写一句后端接口校验基于角色权限码前端隐藏菜单仅作为用户体验优化不作为安全边界。这一句写出来开发不会再说“页面上没有入口所以接口不用防护”。4.2 并发量怎么估借还业务是低并发检索和预约才是压力点需求分析报告里的性能指标经常写成“系统需支持高并发”这种词必须量化。图书管理系统的典型使用场景是图书馆开馆后和闭馆前半小时以及选课季教材集中借阅。以一个本科生规模 2 万人的高校为例集中借阅峰值大约出现在开学前三天全馆日均借还量 3000 笔峰值小时大概是 500 笔。按一小时 3600 秒算每秒不到 0.14 个事务。真正需要关注的是书目检索接口它会同时被全部在线读者使用高峰并发可能在几十到几百 QPS。所以性能需求应拆成接口级指标而不是一个笼统的数字。示例如下接口/场景预估峰值目标响应时间说明借书接口30 笔/分钟P95 1 秒事务性操作需保证数据一致性书目检索100 QPSP95 500 毫秒可加缓存全文检索需考虑 Elasticsearch读者借阅历史查询20 QPSP95 1 秒分页查询避免全表扫描预约请求5 笔/秒成功返回 2 秒需要处理并发抢最后一本副本的场景图书管理系统一般不需要引入消息队列和分库分表。但如果需求里有“预约热门书籍”的功能就要在需求分析报告里明确一个规则同一时间多位读者预约同一本书时以预约提交时间为准当预约副本释放时通知排序最靠前的读者。这个规则如果不写开发大概率会用先到先得的普通查询实现并在读多写少的场景下产生超卖问题。4.3 备份策略从第一天就要写RPO/RTO 优于备份频率校图书馆这类系统的数据丢失后果很严重但需求分析报告里经常只有一句“定期备份”。建议写成可验收的参数备份频率、保留周期、恢复时间目标。示例参数表如下指标建议值验收方式数据备份频率每日全量 每 30 分钟增量查看备份任务日志全量备份保留时间30 天检查备份存储增量日志保留时间7 天检查存储清理任务RTO恢复时间目标4 小时演练恢复计时RPO恢复点目标30 分钟备份间隔确认报告里还可以附一个备份脚本策略让运维确认时间窗口是否合适# 每天 02:30 执行全量备份保留 30 天 30 2 * * * /opt/backup/full_backup.sh --retain30 # 每 30 分钟归档 binlog保留 7 天 */30 * * * * /opt/backup/archive_binlog.sh --keep7d图书管理系统大部分使用 MySQL 存储备份窗口建议选在闭馆后和开馆前避免备份期间的锁表影响借还业务。RPO 30 分钟意味着最多丢失半小时内的借还记录这个指标要业务方确认因为罚款金额和借阅状态如果丢失补录成本极高。4.4 审计日志谁在什么时间改了书的状态图书管理系统涉及罚款和账目管理员操作必须可追溯。需求报告里要包含审计需求记录操作人、操作时间、操作类型、变更前值、变更后值、IP 地址和应用模块。审计日志只追加不修改并单独存储不与应用数据同库。这里的关键点是报告必须明确哪些操作需要审计借还书、罚款修改、读者状态变更、删除书目。常见做法是建议业务表更新时自动写入审计表而不是由业务代码手动记录避免漏记。5. 报告写完后如何自检需求追溯表、原型走查与三查法5.1 用需求追溯表把每条需求落到用例和验收标准报告初稿完成后我会先建一张需求追溯表它是一份一页纸的清单列为“需求编号、需求描述、来源、关联用例、对应页面/原型、验收指标”。追溯表不仅方便自查遗漏也是测试用例设计的来源。下面是一段示例需求编号需求描述来源关联用例原型位置验收指标RF-LEND-001读者可以借阅在馆状态的图书副本访谈记录-读者-03UC-BORROW-01借书页面标注“在馆”标签借出后副本状态可见为“借出”RF-RESV-002预约成功后系统提示预计可借时间访谈记录-管理员-07UC-RESERVE-01预约结果页生成预约记录并显示排名RF-FINE-001逾期归还自动计算罚款金额会议纪要-图书馆-05UC-FINE-01个人借阅明细页逾期 1 天产生对应罚金如果某条需求无法对应到任何用例或原型需要回头补全如果某个用例在追溯表里找不到需求来源则要判断是否属于额外设计。这能防止需求分析报告变成一堆功能的堆砌。5.2 三查法查完整性、查可测性、查异常路径写需求报告时我自己执行“三查法”一查流程完整性二查指标可测性三查异常分支。查完整性是走链路从“读者检索书目”开始到“读者归还图书收到罚款单”结束把这条主链路涉及的每个小环节列出来看是否有需求缺口。常见漏项是“还书时发现副本已被人预约要转入预约到馆处理”这个分支以及“读者注销前有在借图书未归还”的处理。可测性是看每个需求是否包含动作、条件和预期结果。比如“书名支持模糊检索”不是可测需求应改成“输入书名关键字后系统返回题名包含该关键词且状态为在馆的书目列表”。异常路径看的是报告里每个用例的替代流和异常流是否覆盖了权限不足、数据不存在、状态冲突这三类问题。用例的异常流从哪来从业务访谈中让业务方回忆真实工作中遇到过的卡壳场景而不是开发自己臆想。5.3 用原型走查替代文档评审让业务方在界面上挑毛病需求分析报告写得再好业务方也未必能理解用例图和数据字典。我的习惯是把报告中的用例、流程和参数表转成一版可点击的低保真原型然后在评审会上按业务流程走查。从检索页面进入点击某本书尝试预约切到管理员账号处理预约到馆每一步都对照需求追溯表验证。只要流程走得通业务方确认签字后这份报告才能真正成为开发依据。最后在提交报告前把追溯表和参数表打印出来对照测试用例模板逐项过一遍。凡是测试人员看了不知道如何构造数据的需求一律改写。这比在开发评审时争论规则更省钱。本文还有配套的精品资源点击获取