简介OA办公自动化系统需求规格说明书是一份面向OA系统设计、开发、测试与验收人员的完整需求文档适用于需要梳理办公自动化功能边界、编制需求基线或核对项目交付范围的团队。资源包共1个文件为PDF格式大小约300KB。文档从引言、任务概述到需求规定逐层展开既覆盖总体目标和总体功能需求也对电子邮件、待办事宜、文档管理、工作流、报表等核心能力提出明确要求个人办公子系统中还进一步细化到日程安排、个人空间、个人设置、委托授权、在线用户等具体功能点并兼顾性能、接口、测试与验收标准目录层级清晰便于按模块检索和复用。目前已有590人学习下载适合作为需求分析模板、项目文档编写蓝本或开发初期的规格参考可帮助团队快速建立OA系统需求基线降低沟通成本提升交付质量。1. 从没人看到没法验收OA办公自动化系统需求规格说明书为什么难在PDF里大多数OA项目做烂根子不在技术选型而在那份签字归档后没人再看的PDF。评审时各方都点头三个月后交付业务说审批流程不对测试翻文档发现权限和实际配置对不上于是陷入改需求改代码改文档的循环。问题的本质是需求规格说明书被当成了功能清单而不是可验证的基线。OA系统跨部门审批、权限、公文、会议、行政、HR数据交织难的是模块间的角色边界与数据流向PDF定稿后需求变更、测试映射、模块追溯往往都回到人工维护。下面顺着OA办公自动化系统需求规格说明书.pdf这条主线讲需求骨架怎么搭、PDF怎么可靠输出、遗留PDF怎么解析、需求到用例的追溯怎么做命令均可直接复用。2. 拆解OA需求规格说明书的骨架模块、编号与角色权限写OA的需求规格说明书很多人第一反应是开一个Word把截图贴进去再按审批管理、公文管理、会议管理列一堆按钮功能。这种文档评审时没人细看开发时没人照做验收时吵成一团。我一般把SRS当成一份可测试的契约而不是产品介绍。2.1 先定文档骨架SRS的七个必写章节一份面向开发实施的OA需求规格说明书至少要覆盖七部分引言编写目的、术语定义、参考文档总体描述系统定位、用户角色、运行环境约束功能需求按业务模块组织每条需求独立编号非功能需求性能、可用性、安全、浏览器兼容性接口需求与HR、财务、ESB、单点登录的对接数据需求数据字典、归档周期、删除策略附录岗位清单、组织架构图、术语表关键在可验证三个字。功能需求不写系统支持请假审批要写当员工提交请假申请且时长小于等于3天时系统应自动发送给直属上级审批。一个评审过的需求条目开发完成后必须能通过一个具体操作判定满足还是不满足。非功能需求也一样系统应支持主流浏览器没法验收要写成系统应在Chrome 120及以上、Edge 120及以上版本中正常完成附件上传。企业环境里浏览器OA上传文件不兼容几乎每个季度都会上报一次这条不写死实施过程就会被反复退回。2.2 功能需求编号规则让PDF正文能反查到代码和用例需求条目没有编号PDF做得再精美也没法追溯。我采用的格式是 FR-模块代号-三位序号例如 FR-APP-001。模块代号按OA常规领域固定写在文档引言里模块代号典型需求审批中心APPROVAL请假、报销、采购申请流程公文管理DOC发文、收文、套红、归档会议管理MEETING会议室预订、纪要分发车辆与资产管理ASSET用车申请、资产领用行政管理ADMIN用章、证照申请门户与消息PORTAL待办、通知、门户配置系统管理SYSADMIN用户、组织、权限、审计日志每条需求用一个结构化条目描述文档源文件里保存为JSON再渲染成PDF中的说明性表格。示例{ id: FR-APP-001, module: APPROVAL, title: 员工提交请假申请, priority: P0, precondition: 用户已登录OA门户且存在有效雇佣关系, main_flow: [ 员工选择请假类型与起止日期, 系统自动计算请假时长, 提交给直属上级审批 ], exception: 请假时长超过3天时系统自动转给部门总监审批, acceptance: 审批人可在待办中心看到该申请并完成通过或驳回 }id、precondition、main_flow、exception、acceptance这五个字段就是后面测试用例可以直接引用的内容。需要强调编号一旦随PDF发布就不能复用和变更需求调整只能新增编号并废弃旧编号废弃记录写入变更记录。这样追溯矩阵里每个编号状态唯一不会出现一个编号对应两套逻辑。2.3 角色-权限矩阵最容易返工的一页用表格锁死OA的需求评审会几乎每次都要在谁能看谁的审批单上吵起来。避免返工的办法是把权限矩阵作为独立小节用表格逐行确认。矩阵的列是角色行是业务对象单元格写权限级别查看R、新增C、编辑U、审批A、导出E。业务对象员工部门经理总监HR财务系统管理员个人请假单RAARU--部门薪资数据--RRUARU-报销单RAA-RUA-审计日志-----RUA矩阵定稿时要核对两个方向。行方向看数据流转员工提交的数据会到哪一级列方向看跨部门角色HR和财务能看到哪些数据。如果允许HR查看全公司薪资但不可导出单元格里必须写R而不是E。任何相关人员可见的表述评审时一律退回重写。2.4 流程节点与异常分支在需求阶段约束产品自由发挥OA审批流是开发后最容易被业务推翻的部分。需求文档里对每个主流程附一张节点表。以请假审批流程为例节点处理人时限驳回策略备注N1 提交员工本人--未提交前可撤回N2 直属上级审批员工直属上级2个工作日驳回则流程结束可转办给同级N3 总监审批部门总监2个工作日驳回则退回N2仅请假时长超过3天触发N4 归档系统自动通过后实时-写入人事系统接口这张表评审时要逐节点过。业务说流程不对很多时候不是要改代码而是节点表里少定义了一行。特别注意异常分支超时自动通过还是自动提醒驳回后终止还是退到上一节点允许不允许加签和转办。这些在表里没有开发阶段就会有人拍脑袋实现。接口需求要单独成节。OA几乎必然要和企业微信、钉钉做待办接入与HR系统做组织同步与财务系统做报销传单与ESB总线做消息路由。每条接口需求至少要写协议、方向、字段清单和失败处理策略。实施中像致远OA、泛微E9这类产品在对接金蝶或企业微信时经常抛出-16之类的访问代码追根溯源往往是对接字段和网络约束没有写在接口需求里。这层写透实施返工量会明显下降。3. 把需求规格说明书可靠地输出为PDF工具链与版本管理Word写需求文档的问题是评审后的版本对比和差异标注非常痛苦LaTeX对多数产品经理又不友好。常见方案是Markdown维护源文件用Pandoc转换出PDF。好处是需求条目以结构化列表维护PDF目录稳定与Git天然配合。3.1 Markdown Pandoc 出 PDF 的最小命令pandoc oa_srs.md -o oa_srs.pdf \ --pdf-enginexelatex \ -V mainfontNoto Serif CJK SC \ -V CJKmainfontNoto Serif CJK SC \ -V monofontNoto Sans Mono CJK SC \ --toc --toc-depth2 \ -N \ -V geometry:margin2.5cm \ -V colorlinkstrue参数说明--pdf-enginexelatex是中文文档必须的前端引擎换成pdflatex会直接扑在中文上CJKmainfont指定中文字体Noto Serif CJK SC常见于Linux发行版如果换系统要把字体名改成Microsoft YaHei或PingFang SC--toc --toc-depth2生成两级目录对应一级章节和功能需求小节-N让标题自动编号PDF里的章节号和需求编号能对应上几何边距统一设2.5cm防止打印机裁切内容。3.2 模板定制页眉、页脚、封面与目录输出PDF的控制点有两个。一是Markdown源文件头部的元数据块控制封面信息--- title: OA办公自动化系统需求规格说明书 author: 系统集成部 date: 2025-06-10 version: 2.1 status: 评审通过 ---二是控制页眉页脚。Pandoc直接出PDF时改页眉页脚要动LaTeX模板成本高。我的做法是走Word中转链先把Markdown渲染成带自定义样式的Word再用LibreOffice转PDF页眉的机密等级、页脚的版本号都能在Word模板里一次性定死。# 导出默认Word模板在Word里改页眉页脚、封面样式 pandoc --print-default-data-filereference.docx custom-reference.docx # Markdown渲染成带模板样式的Word pandoc oa_srs.md -o oa_srs.docx --reference-doccustom-reference.docx # 用LibreOffice转PDF页眉页脚和封面一起保留 soffice --headless --convert-to pdf oa_srs.docx说明套用reference-doc后Pandoc会用模板样式替换默认正文字体、标题颜色和表格边框。封面最简单的方式是在Word模板第一页做好版式标题、版本号、日期留空每次生成后手动补齐工作量可接受。这一跳的代价是中文字体和表格跨页控制比直接XeLaTeX差一些但对需求文档足够。3.3 版本命名与 PDF/A 归档PDF发出去后收件人手里的版本和源文件版本就是两个事实。版本命名我建议按 OA_SRS_v主.次_YYYYMMDD.pdf 落地次版本每次评审后递增日期对应Git tag。版本号日期变更摘要评审结论v1.02025-05-06初稿完成整体结构需修改v1.12025-05-20增加角色权限矩阵细化异常分支通过v2.02025-06-01引入新审批流废弃FR-APP-015有条件通过v2.12025-06-10按评审意见修订接口字段通过变更记录表放PDF正文前面。废弃的需求条目不物理删除正文里保留但标注已废弃否则追溯矩阵对不上号。正式对外发布的基线我建议转PDF/A做长期归档防止若干年后打开排版错乱。Ghostscript可以做gs -dPDFA -dBATCH -dNOPAUSE \ -sProcessColorModelDeviceRGB \ -sDEVICEpdfwrite \ -sPDFACompliancePolicy1 \ -sOutputFileoa_srs_archive.pdf oa_srs_v2.1.pdf-dPDFA开启PDF/A输出-sPDFACompliancePolicy1表示转换失败时返回错误信号方便挂在CI里。转完用pdfinfo抽验pdfinfo oa_srs_archive.pdf | grep -E PDF version|Encrypted|Page sizePDF/A的坑在中文字体未嵌入时报错Pandoc加XeLaTeX默认子集嵌入字体一般不触发但如果跨发行版换过字体批量转换后抽验一下更稳。4. 已经躺了三年怎么解析和复用别人的OA需求规格说明书PDF接手项目时需求文档经常只剩一份签完字的老PDFWord源文件早没了或者供应商只交付只读PDF。与其把PDF转成Word再人工整理不如直接用解析库处理把文本、表格、编号抽出来作为后续做需求追踪矩阵的原始数据。这条路线上用到的就是最常见的pdf解析方案。4.1 pdfplumber 提取文本与表格先把PDF变成结构化数据pdfplumber基于PDFMiner封装对文本排版的还原能力比pypdf强。先做两步抽文本、抽表格判断这PDF是数字版还是扫描版。import pdfplumber pdf_path oa_srs_v2.1.pdf with pdfplumber.open(pdf_path) as pdf: print(f总页数: {len(pdf.pages)}) for page in pdf.pages[:3]: text page.extract_text() print(f--- 第 {page.page_number} 页 ---) print(text[:300] if text else (无文本层)) for table_idx, table in enumerate(page.extract_tables()): print(f表格 {table_idx}: {len(table)} 行) for row in table[:3]: print(row)extract_text()返回按阅读顺序拼接的文本extract_tables()返回二维列表每行是一个单元格。先跑这个脚本能快速判断PDF带不带文本层。如果所有页返回None或乱码说明是扫描图片直接跳到4.3的OCR处理。历史文档解析的产出一律保存为JSON或CSV再基于中间格式做分析不要每次重新跑一遍解析。4.2 用正则把 FR 编号洗成需求清单拿到全文文本后核心任务是捞出所有需求条目编号。基于第2章的编号规则模式是 FR-模块-三位数字import re import pdfplumber pattern re.compile(rFR-[A-Z]-\d{3}) reqs [] with pdfplumber.open(oa_srs_v2.1.pdf) as pdf: for page in pdf.pages: text page.extract_text() or text re.sub(r[\s\u3000], , text) for m in pattern.finditer(text): start max(0, m.start() - 60) end min(len(text), m.end() 80) reqs.append({ id: m.group(0), page: page.page_number, context: text[start:end].replace(\n, ) }) seen set() unique_reqs [] for r in reqs: if r[id] not in seen: seen.add(r[id]) unique_reqs.append(r) print(f共提取 {len(unique_reqs)} 个唯一需求编号) for r in unique_reqs: print(f{r[id]} page {r[page]}: {r[context][:40]})逻辑说明finditer在全文文本流里按正则找编号以编号为中心截取前后上下文便于人工判断这条需求的内容用集合去重同一编号跨页引用时只保留第一次出现的页码和上下文。注意先把全角空格和空白归一化否则两端对齐的排版会在编号中间混入不可见字符。如果文档用的是FR-001这类无模块代号编号把正则改成FR-\d{4,}保守模式。跑完后人工抽查20个编号确认抽取稳定再批量处理。编号抽错了比没有索引更麻烦。4.3 扫描件与多栏排版的三个实操坑坑一纯扫描件没有文本层。常见处理是OCR中文。Tesseract加chi_sim语言包tesseract page_12.png page_12 -l chi_sim --psm 6--psm 6表示按统一文本块识别适合单栏扫描页。OCR对FR-APP-001这种连字符加数字的识别不稳定经常把001识别成OOI。我一般全量OCR后只对命中FR-的页面做人工二次确认。坑二双栏排版导致extract_text()顺序错乱。PDF单栏没这个问题但历史文档常为省纸排双栏流式输出会把右栏上半部分和左栏下半部分混在一起。处理办法是按坐标裁剪成左右两半分别提取with pdfplumber.open(legacy_srs.pdf) as pdf: page pdf.pages[4] left page.crop((0, 0, page.width / 2, page.height)) right page.crop((page.width / 2, 0, page.width, page.height)) print(left.extract_text()) print(right.extract_text())crop参数是(x0, top, x1, bottom)单位是PDF Point。这个方案只对对称双栏有效三栏或图文混排得分栏多次裁切。坑三表格线缺失导致extract_tables()把多行合并成一行。扫描件转出来的PDF表格线都是噪点这时改用文字对齐推断行边界table page.extract_tables( vertical_strategytext, horizontal_strategytext, )vertical_strategy和horizontal_strategy可选lines、text或explicit。text模式不依赖画线对扫描件表格更可靠代价是相邻文字列可能被误判成表头。解析结果一定要落成中间JSON/CSV再手工review别把PDF解析当成完全自动化的活。提示解析历史PDF的产出一律保存成中间格式比如JSON或CSV再基于中间格式做后续分析。PDF源文件被替换或字体缺字都会让解析结果漂移。5. 从PDF需求条目到测试用例用脚本做覆盖度闭环需求文档的价值最终体现在能否指导测试验收。把PDF里的FR清单和测试用例关联起来就形成需求追溯矩阵。矩阵的四个核心字段需求编号所属模块测试用例ID执行结果备注FR-APP-001APPROVALTC-APP-001PASS覆盖3天以内流程FR-APP-001APPROVALTC-APP-002FAIL覆盖超过3天转总监FR-APP-002APPROVALTC-APP-003PASS驳回后流程终止5.1 需求追溯矩阵的构建用脚本把需求清单和用例清单关联输出CSV便于在Excel里和业务方核对import csv req_to_cases { FR-APP-001: [TC-APP-001, TC-APP-002], FR-APP-002: [TC-APP-003], } rows [] for req_id, case_ids in req_to_cases.items(): for case_id in case_ids: rows.append({req_id: req_id, case_id: case_id, status: NOT_EXECUTED}) with open(trace_matrix.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[req_id, case_id, status]) writer.writeheader() writer.writerows(rows)utf-8-sig编码是为了Excel直接打开不乱码字段名用英文避免某些数据库对中文表头不兼容。关联关系从哪来一个来源是测试设计时用例标题里必须带需求编号另一个来源是缺陷单里记录来源需求。没有关联的用例算孤儿用例需要人工判断是冗余还是追溯断了。覆盖度检查可以简单到一行awkawk -F, NR1 {key$1; if ($2) no_case[key]1; seen[key]1} END {for (k in seen) if (no_case[k]) print 缺少用例: k} trace_matrix.csvCSV里需求编号有值但用例ID为空时这条需求就是未覆盖需求。测试经理基于这份报告做缺口分析而不是打开一份100页PDF挨个搜编号。5.2 用 PDF 书签定位模块变更的过审技巧需求文档迭代时最大工作量是把新版PDF和旧版PDF的差异找出来。先用pypdf读PDF书签大纲生成模块到页码的映射from pypdf import PdfReader reader PdfReader(oa_srs_v2.1.pdf) for item in reader.outline: if isinstance(item, list): for sub in item: page_no reader.get_destination_page_number(sub) print(f章节: {sub.title} - 第 {page_no 1} 页)reader.outline返回嵌套列表逐层展开取title和页码。这一步能快速看出新版把会议管理从第20页挪到第24页或者新增了一节接口需求。评审会上与会者不用从头翻PDF只对着映射表圈变更范围。把映射表导出成JSON在CI里做两个版本的diff就是一个自动化评审辅助for p in $(seq 20 24); do pdftotext -f $p -l $p oa_srs_v2.1.pdf - | grep ^FR- donepdftotext配合-f和-l只转换指定页码范围-表示输出到标准输出grep筛出这一页的FR编号。于是评审重点锁定在第20到24页之间出现的FR编号逐条对照旧版本标记变更。这个做法成本极低但能把PDF从存档文件变成可评审的活文档。本文还有配套的精品资源点击获取 简介OA办公自动化系统需求规格说明书是一份面向OA系统设计、开发、测试与验收人员的完整需求文档适用于需要梳理办公自动化功能边界、编制需求基线或核对项目交付范围的团队。资源包共1个文件为PDF格式大小约300KB。文档从引言、任务概述到需求规定逐层展开既覆盖总体目标和总体功能需求也对电子邮件、待办事宜、文档管理、工作流、报表等核心能力提出明确要求个人办公子系统中还进一步细化到日程安排、个人空间、个人设置、委托授权、在线用户等具体功能点并兼顾性能、接口、测试与验收标准目录层级清晰便于按模块检索和复用。目前已有590人学习下载适合作为需求分析模板、项目文档编写蓝本或开发初期的规格参考可帮助团队快速建立OA系统需求基线降低沟通成本提升交付质量。1. 从没人看到没法验收OA办公自动化系统需求规格说明书为什么难在PDF里大多数OA项目做烂根子不在技术选型而在那份签字归档后没人再看的PDF。评审时各方都点头三个月后交付业务说审批流程不对测试翻文档发现权限和实际配置对不上于是陷入改需求改代码改文档的循环。问题的本质是需求规格说明书被当成了功能清单而不是可验证的基线。OA系统跨部门审批、权限、公文、会议、行政、HR数据交织难的是模块间的角色边界与数据流向PDF定稿后需求变更、测试映射、模块追溯往往都回到人工维护。下面顺着OA办公自动化系统需求规格说明书.pdf这条主线讲需求骨架怎么搭、PDF怎么可靠输出、遗留PDF怎么解析、需求到用例的追溯怎么做命令均可直接复用。2. 拆解OA需求规格说明书的骨架模块、编号与角色权限写OA的需求规格说明书很多人第一反应是开一个Word把截图贴进去再按审批管理、公文管理、会议管理列一堆按钮功能。这种文档评审时没人细看开发时没人照做验收时吵成一团。我一般把SRS当成一份可测试的契约而不是产品介绍。2.1 先定文档骨架SRS的七个必写章节一份面向开发实施的OA需求规格说明书至少要覆盖七部分引言编写目的、术语定义、参考文档总体描述系统定位、用户角色、运行环境约束功能需求按业务模块组织每条需求独立编号非功能需求性能、可用性、安全、浏览器兼容性接口需求与HR、财务、ESB、单点登录的对接数据需求数据字典、归档周期、删除策略附录岗位清单、组织架构图、术语表关键在可验证三个字。功能需求不写系统支持请假审批要写当员工提交请假申请且时长小于等于3天时系统应自动发送给直属上级审批。一个评审过的需求条目开发完成后必须能通过一个具体操作判定满足还是不满足。非功能需求也一样系统应支持主流浏览器没法验收要写成系统应在Chrome 120及以上、Edge 120及以上版本中正常完成附件上传。企业环境里浏览器OA上传文件不兼容几乎每个季度都会上报一次这条不写死实施过程就会被反复退回。2.2 功能需求编号规则让PDF正文能反查到代码和用例需求条目没有编号PDF做得再精美也没法追溯。我采用的格式是 FR-模块代号-三位序号例如 FR-APP-001。模块代号按OA常规领域固定写在文档引言里模块代号典型需求审批中心APPROVAL请假、报销、采购申请流程公文管理DOC发文、收文、套红、归档会议管理MEETING会议室预订、纪要分发车辆与资产管理ASSET用车申请、资产领用行政管理ADMIN用章、证照申请门户与消息PORTAL待办、通知、门户配置系统管理SYSADMIN用户、组织、权限、审计日志每条需求用一个结构化条目描述文档源文件里保存为JSON再渲染成PDF中的说明性表格。示例{ id: FR-APP-001, module: APPROVAL, title: 员工提交请假申请, priority: P0, precondition: 用户已登录OA门户且存在有效雇佣关系, main_flow: [ 员工选择请假类型与起止日期, 系统自动计算请假时长, 提交给直属上级审批 ], exception: 请假时长超过3天时系统自动转给部门总监审批, acceptance: 审批人可在待办中心看到该申请并完成通过或驳回 }id、precondition、main_flow、exception、acceptance这五个字段就是后面测试用例可以直接引用的内容。需要强调编号一旦随PDF发布就不能复用和变更需求调整只能新增编号并废弃旧编号废弃记录写入变更记录。这样追溯矩阵里每个编号状态唯一不会出现一个编号对应两套逻辑。2.3 角色-权限矩阵最容易返工的一页用表格锁死OA的需求评审会几乎每次都要在谁能看谁的审批单上吵起来。避免返工的办法是把权限矩阵作为独立小节用表格逐行确认。矩阵的列是角色行是业务对象单元格写权限级别查看R、新增C、编辑U、审批A、导出E。业务对象员工部门经理总监HR财务系统管理员个人请假单RAARU--部门薪资数据--RRUARU-报销单RAA-RUA-审计日志-----RUA矩阵定稿时要核对两个方向。行方向看数据流转员工提交的数据会到哪一级列方向看跨部门角色HR和财务能看到哪些数据。如果允许HR查看全公司薪资但不可导出单元格里必须写R而不是E。任何相关人员可见的表述评审时一律退回重写。2.4 流程节点与异常分支在需求阶段约束产品自由发挥OA审批流是开发后最容易被业务推翻的部分。需求文档里对每个主流程附一张节点表。以请假审批流程为例节点处理人时限驳回策略备注N1 提交员工本人--未提交前可撤回N2 直属上级审批员工直属上级2个工作日驳回则流程结束可转办给同级N3 总监审批部门总监2个工作日驳回则退回N2仅请假时长超过3天触发N4 归档系统自动通过后实时-写入人事系统接口这张表评审时要逐节点过。业务说流程不对很多时候不是要改代码而是节点表里少定义了一行。特别注意异常分支超时自动通过还是自动提醒驳回后终止还是退到上一节点允许不允许加签和转办。这些在表里没有开发阶段就会有人拍脑袋实现。接口需求要单独成节。OA几乎必然要和企业微信、钉钉做待办接入与HR系统做组织同步与财务系统做报销传单与ESB总线做消息路由。每条接口需求至少要写协议、方向、字段清单和失败处理策略。实施中像致远OA、泛微E9这类产品在对接金蝶或企业微信时经常抛出-16之类的访问代码追根溯源往往是对接字段和网络约束没有写在接口需求里。这层写透实施返工量会明显下降。3. 把需求规格说明书可靠地输出为PDF工具链与版本管理Word写需求文档的问题是评审后的版本对比和差异标注非常痛苦LaTeX对多数产品经理又不友好。常见方案是Markdown维护源文件用Pandoc转换出PDF。好处是需求条目以结构化列表维护PDF目录稳定与Git天然配合。3.1 Markdown Pandoc 出 PDF 的最小命令pandoc oa_srs.md -o oa_srs.pdf \ --pdf-enginexelatex \ -V mainfontNoto Serif CJK SC \ -V CJKmainfontNoto Serif CJK SC \ -V monofontNoto Sans Mono CJK SC \ --toc --toc-depth2 \ -N \ -V geometry:margin2.5cm \ -V colorlinkstrue参数说明--pdf-enginexelatex是中文文档必须的前端引擎换成pdflatex会直接扑在中文上CJKmainfont指定中文字体Noto Serif CJK SC常见于Linux发行版如果换系统要把字体名改成Microsoft YaHei或PingFang SC--toc --toc-depth2生成两级目录对应一级章节和功能需求小节-N让标题自动编号PDF里的章节号和需求编号能对应上几何边距统一设2.5cm防止打印机裁切内容。3.2 模板定制页眉、页脚、封面与目录输出PDF的控制点有两个。一是Markdown源文件头部的元数据块控制封面信息--- title: OA办公自动化系统需求规格说明书 author: 系统集成部 date: 2025-06-10 version: 2.1 status: 评审通过 ---二是控制页眉页脚。Pandoc直接出PDF时改页眉页脚要动LaTeX模板成本高。我的做法是走Word中转链先把Markdown渲染成带自定义样式的Word再用LibreOffice转PDF页眉的机密等级、页脚的版本号都能在Word模板里一次性定死。# 导出默认Word模板在Word里改页眉页脚、封面样式 pandoc --print-default-data-filereference.docx custom-reference.docx # Markdown渲染成带模板样式的Word pandoc oa_srs.md -o oa_srs.docx --reference-doccustom-reference.docx # 用LibreOffice转PDF页眉页脚和封面一起保留 soffice --headless --convert-to pdf oa_srs.docx说明套用reference-doc后Pandoc会用模板样式替换默认正文字体、标题颜色和表格边框。封面最简单的方式是在Word模板第一页做好版式标题、版本号、日期留空每次生成后手动补齐工作量可接受。这一跳的代价是中文字体和表格跨页控制比直接XeLaTeX差一些但对需求文档足够。3.3 版本命名与 PDF/A 归档PDF发出去后收件人手里的版本和源文件版本就是两个事实。版本命名我建议按 OA_SRS_v主.次_YYYYMMDD.pdf 落地次版本每次评审后递增日期对应Git tag。版本号日期变更摘要评审结论v1.02025-05-06初稿完成整体结构需修改v1.12025-05-20增加角色权限矩阵细化异常分支通过v2.02025-06-01引入新审批流废弃FR-APP-015有条件通过v2.12025-06-10按评审意见修订接口字段通过变更记录表放PDF正文前面。废弃的需求条目不物理删除正文里保留但标注已废弃否则追溯矩阵对不上号。正式对外发布的基线我建议转PDF/A做长期归档防止若干年后打开排版错乱。Ghostscript可以做gs -dPDFA -dBATCH -dNOPAUSE \ -sProcessColorModelDeviceRGB \ -sDEVICEpdfwrite \ -sPDFACompliancePolicy1 \ -sOutputFileoa_srs_archive.pdf oa_srs_v2.1.pdf-dPDFA开启PDF/A输出-sPDFACompliancePolicy1表示转换失败时返回错误信号方便挂在CI里。转完用pdfinfo抽验pdfinfo oa_srs_archive.pdf | grep -E PDF version|Encrypted|Page sizePDF/A的坑在中文字体未嵌入时报错Pandoc加XeLaTeX默认子集嵌入字体一般不触发但如果跨发行版换过字体批量转换后抽验一下更稳。4. 已经躺了三年怎么解析和复用别人的OA需求规格说明书PDF接手项目时需求文档经常只剩一份签完字的老PDFWord源文件早没了或者供应商只交付只读PDF。与其把PDF转成Word再人工整理不如直接用解析库处理把文本、表格、编号抽出来作为后续做需求追踪矩阵的原始数据。这条路线上用到的就是最常见的pdf解析方案。4.1 pdfplumber 提取文本与表格先把PDF变成结构化数据pdfplumber基于PDFMiner封装对文本排版的还原能力比pypdf强。先做两步抽文本、抽表格判断这PDF是数字版还是扫描版。import pdfplumber pdf_path oa_srs_v2.1.pdf with pdfplumber.open(pdf_path) as pdf: print(f总页数: {len(pdf.pages)}) for page in pdf.pages[:3]: text page.extract_text() print(f--- 第 {page.page_number} 页 ---) print(text[:300] if text else (无文本层)) for table_idx, table in enumerate(page.extract_tables()): print(f表格 {table_idx}: {len(table)} 行) for row in table[:3]: print(row)extract_text()返回按阅读顺序拼接的文本extract_tables()返回二维列表每行是一个单元格。先跑这个脚本能快速判断PDF带不带文本层。如果所有页返回None或乱码说明是扫描图片直接跳到4.3的OCR处理。历史文档解析的产出一律保存为JSON或CSV再基于中间格式做分析不要每次重新跑一遍解析。4.2 用正则把 FR 编号洗成需求清单拿到全文文本后核心任务是捞出所有需求条目编号。基于第2章的编号规则模式是 FR-模块-三位数字import re import pdfplumber pattern re.compile(rFR-[A-Z]-\d{3}) reqs [] with pdfplumber.open(oa_srs_v2.1.pdf) as pdf: for page in pdf.pages: text page.extract_text() or text re.sub(r[\s\u3000], , text) for m in pattern.finditer(text): start max(0, m.start() - 60) end min(len(text), m.end() 80) reqs.append({ id: m.group(0), page: page.page_number, context: text[start:end].replace(\n, ) }) seen set() unique_reqs [] for r in reqs: if r[id] not in seen: seen.add(r[id]) unique_reqs.append(r) print(f共提取 {len(unique_reqs)} 个唯一需求编号) for r in unique_reqs: print(f{r[id]} page {r[page]}: {r[context][:40]})逻辑说明finditer在全文文本流里按正则找编号以编号为中心截取前后上下文便于人工判断这条需求的内容用集合去重同一编号跨页引用时只保留第一次出现的页码和上下文。注意先把全角空格和空白归一化否则两端对齐的排版会在编号中间混入不可见字符。如果文档用的是FR-001这类无模块代号编号把正则改成FR-\d{4,}保守模式。跑完后人工抽查20个编号确认抽取稳定再批量处理。编号抽错了比没有索引更麻烦。4.3 扫描件与多栏排版的三个实操坑坑一纯扫描件没有文本层。常见处理是OCR中文。Tesseract加chi_sim语言包tesseract page_12.png page_12 -l chi_sim --psm 6--psm 6表示按统一文本块识别适合单栏扫描页。OCR对FR-APP-001这种连字符加数字的识别不稳定经常把001识别成OOI。我一般全量OCR后只对命中FR-的页面做人工二次确认。坑二双栏排版导致extract_text()顺序错乱。PDF单栏没这个问题但历史文档常为省纸排双栏流式输出会把右栏上半部分和左栏下半部分混在一起。处理办法是按坐标裁剪成左右两半分别提取with pdfplumber.open(legacy_srs.pdf) as pdf: page pdf.pages[4] left page.crop((0, 0, page.width / 2, page.height)) right page.crop((page.width / 2, 0, page.width, page.height)) print(left.extract_text()) print(right.extract_text())crop参数是(x0, top, x1, bottom)单位是PDF Point。这个方案只对对称双栏有效三栏或图文混排得分栏多次裁切。坑三表格线缺失导致extract_tables()把多行合并成一行。扫描件转出来的PDF表格线都是噪点这时改用文字对齐推断行边界table page.extract_tables( vertical_strategytext, horizontal_strategytext, )vertical_strategy和horizontal_strategy可选lines、text或explicit。text模式不依赖画线对扫描件表格更可靠代价是相邻文字列可能被误判成表头。解析结果一定要落成中间JSON/CSV再手工review别把PDF解析当成完全自动化的活。提示解析历史PDF的产出一律保存成中间格式比如JSON或CSV再基于中间格式做后续分析。PDF源文件被替换或字体缺字都会让解析结果漂移。5. 从PDF需求条目到测试用例用脚本做覆盖度闭环需求文档的价值最终体现在能否指导测试验收。把PDF里的FR清单和测试用例关联起来就形成需求追溯矩阵。矩阵的四个核心字段需求编号所属模块测试用例ID执行结果备注FR-APP-001APPROVALTC-APP-001PASS覆盖3天以内流程FR-APP-001APPROVALTC-APP-002FAIL覆盖超过3天转总监FR-APP-002APPROVALTC-APP-003PASS驳回后流程终止5.1 需求追溯矩阵的构建用脚本把需求清单和用例清单关联输出CSV便于在Excel里和业务方核对import csv req_to_cases { FR-APP-001: [TC-APP-001, TC-APP-002], FR-APP-002: [TC-APP-003], } rows [] for req_id, case_ids in req_to_cases.items(): for case_id in case_ids: rows.append({req_id: req_id, case_id: case_id, status: NOT_EXECUTED}) with open(trace_matrix.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[req_id, case_id, status]) writer.writeheader() writer.writerows(rows)utf-8-sig编码是为了Excel直接打开不乱码字段名用英文避免某些数据库对中文表头不兼容。关联关系从哪来一个来源是测试设计时用例标题里必须带需求编号另一个来源是缺陷单里记录来源需求。没有关联的用例算孤儿用例需要人工判断是冗余还是追溯断了。覆盖度检查可以简单到一行awkawk -F, NR1 {key$1; if ($2) no_case[key]1; seen[key]1} END {for (k in seen) if (no_case[k]) print 缺少用例: k} trace_matrix.csvCSV里需求编号有值但用例ID为空时这条需求就是未覆盖需求。测试经理基于这份报告做缺口分析而不是打开一份100页PDF挨个搜编号。5.2 用 PDF 书签定位模块变更的过审技巧需求文档迭代时最大工作量是把新版PDF和旧版PDF的差异找出来。先用pypdf读PDF书签大纲生成模块到页码的映射from pypdf import PdfReader reader PdfReader(oa_srs_v2.1.pdf) for item in reader.outline: if isinstance(item, list): for sub in item: page_no reader.get_destination_page_number(sub) print(f章节: {sub.title} - 第 {page_no 1} 页)reader.outline返回嵌套列表逐层展开取title和页码。这一步能快速看出新版把会议管理从第20页挪到第24页或者新增了一节接口需求。评审会上与会者不用从头翻PDF只对着映射表圈变更范围。把映射表导出成JSON在CI里做两个版本的diff就是一个自动化评审辅助for p in $(seq 20 24); do pdftotext -f $p -l $p oa_srs_v2.1.pdf - | grep ^FR- donepdftotext配合-f和-l只转换指定页码范围-表示输出到标准输出grep筛出这一页的FR编号。于是评审重点锁定在第20到24页之间出现的FR编号逐条对照旧版本标记变更。这个做法成本极低但能把PDF从存档文件变成可评审的活文档。本文还有配套的精品资源点击获取