企业官网建设流程全解析

简介：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常规领域固定，写在文档引言里：

每条需求用一个结构化条目描述，文档源文件里保存为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和财务能看到哪些数据。如果"允许HR查看全公司薪资但不可导出"，单元格里必须写R而不是E。任何"相关人员可见"的表述，评审时一律退回重写。

2.4 流程节点与异常分支：在需求阶段约束产品自由发挥

OA审批流是开发后最容易被业务推翻的部分。需求文档里对每个主流程附一张节点表。以请假审批流程为例：

这张表评审时要逐节点过。业务说"流程不对"，很多时候不是要改代码，而是节点表里少定义了一行。特别注意异常分支：超时自动通过还是自动提醒，驳回后终止还是退到上一节点，允许不允许加签和转办。这些在表里没有，开发阶段就会有人拍脑袋实现。

接口需求要单独成节。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-engine=xelatex \ -V mainfont="Noto Serif CJK SC" \ -V CJKmainfont="Noto Serif CJK SC" \ -V monofont="Noto Sans Mono CJK SC" \ --toc --toc-depth=2 \ -N \ -V geometry:margin=2.5cm \ -V colorlinks=true

参数说明：--pdf-engine=xelatex是中文文档必须的前端引擎，换成pdflatex会直接扑在中文上；CJKmainfont指定中文字体，Noto Serif CJK SC常见于Linux发行版，如果换系统要把字体名改成"Microsoft YaHei"或"PingFang SC"；--toc --toc-depth=2生成两级目录，对应一级章节和功能需求小节；-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-file=reference.docx > custom-reference.docx # Markdown渲染成带模板样式的Word pandoc oa_srs.md -o oa_srs.docx --reference-doc=custom-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。

变更记录表放PDF正文前面。废弃的需求条目不物理删除，正文里保留但标注"已废弃"，否则追溯矩阵对不上号。

正式对外发布的基线，我建议转PDF/A做长期归档，防止若干年后打开排版错乱。Ghostscript可以做：

gs -dPDFA -dBATCH -dNOPAUSE \ -sProcessColorModel=DeviceRGB \ -sDEVICE=pdfwrite \ -sPDFACompliancePolicy=1 \ -sOutputFile=oa_srs_archive.pdf oa_srs_v2.1.pdf

-dPDFA开启PDF/A输出；-sPDFACompliancePolicy=1表示转换失败时返回错误信号，方便挂在CI里。转完用pdfinfo抽验：

pdfinfo oa_srs_archive.pdf | grep -E "PDF version|Encrypted|Page size"

PDF/A的坑在中文字体未嵌入时报错；Pandoc加XeLaTeX默认子集嵌入字体，一般不触发，但如果跨发行版换过字体，批量转换后抽验一下更稳。

4. 已经躺了三年：怎么解析和复用别人的OA需求规格说明书PDF

接手项目时，需求文档经常只剩一份签完字的老PDF，Word源文件早没了；或者供应商只交付只读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(r"FR-[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_strategy="text", horizontal_strategy="text", )

vertical_strategy和horizontal_strategy可选"lines"、"text"或"explicit"。"text"模式不依赖画线，对扫描件表格更可靠，代价是相邻文字列可能被误判成表头。解析结果一定要落成中间JSON/CSV再手工review，别把PDF解析当成完全自动化的活。

提示：解析历史PDF的产出一律保存成中间格式，比如JSON或CSV，再基于中间格式做后续分析。PDF源文件被替换或字体缺字都会让解析结果漂移。

5. 从PDF需求条目到测试用例：用脚本做覆盖度闭环

需求文档的价值最终体现在能否指导测试验收。把PDF里的FR清单和测试用例关联起来，就形成需求追溯矩阵。矩阵的四个核心字段：

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="", encoding="utf-8-sig") as f: writer = csv.DictWriter(f, fieldnames=["req_id", "case_id", "status"]) writer.writeheader() writer.writerows(rows)

utf-8-sig编码是为了Excel直接打开不乱码；字段名用英文，避免某些数据库对中文表头不兼容。关联关系从哪来？一个来源是测试设计时用例标题里必须带需求编号，另一个来源是缺陷单里记录来源需求。没有关联的用例算"孤儿用例"，需要人工判断是冗余还是追溯断了。

覆盖度检查可以简单到一行awk：

awk -F, 'NR>1 {key=$1; if ($2=="") no_case[key]=1; seen[key]=1} END {for (k in seen) if (no_case[k]) print "缺少用例: " k}' trace_matrix.csv

CSV里需求编号有值但用例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-" done

pdftotext配合-f和-l只转换指定页码范围，-表示输出到标准输出，grep筛出这一页的FR编号。于是评审重点锁定在"第20到24页之间出现的FR编号"，逐条对照旧版本标记变更。这个做法成本极低，但能把PDF从"存档文件"变成"可评审的活文档"。

本文还有配套的精品资源，点击获取