2008年的需求文档为何仍是经典？一次制造业需求分析拆解实录

简介：生产制造管理系统（CCAM）需求分析文档模板，面向制造企业信息化项目中的需求分析师、产品经理及开发测试人员，用于规范软件需求说明书的编写与评审流程。文档立足生产制造核心业务，覆盖基础资料、销售、采购、库存、生产等主要模块，并给出编写目的、范围、定义、项目概述、产品描述、功能需求等标准章节，可支撑团队从项目背景到具体功能点的完整梳理，直接作为企业编制需求文档的骨架参考。压缩包内含单份doc文档，共1个文件，大小仅199KB，轻量易用。模板在功能需求部分对各模块做了细化，如销售模块的订单与客户关系管理、采购模块的供应商管理、库存模块的库存查询与报表、生产模块的生产计划与过程质量控制等，同时包含用户特点、一般约束、假设和依据等非功能内容，便于在开发前对齐范围、减少需求遗漏。目前已有189人学习下载，适合需要快速搭建需求分析框架、梳理CCAM系统模块边界的团队参考。

1. 一份 2008 年的需求文档，为什么今天还能当模板用

拿到这份《生产制造管理系统（CCAM）软件需求说明书》时，我先看了一眼落款日期：初稿 2008-6-26。说实话，第一反应是这东西还有参考价值吗？翻到第 3 章「具体需求」里的 16 条存在问题，我改变了看法。里面记录的「玻璃破损严重但可再利用的没有再利用」「铝材采购长度 4.7 米导致下料剩料无法使用」「皮革小库一捆一捆领但没人登记」这些场景，我在后来的定制家居、移门加工项目里都遇到过几乎一模一样的原话。这份文档的真正价值不在模板结构，而在它把车间里的模糊抱怨翻译成了可开发的功能需求。对做企业应用、特别是制造业信息化的人而言，这种「问题 → 功能 → 验收口径」的转化过程，比任何空泛的模板都值得拆解。

这篇文章就按我拆解这份文档的思路来展开：先讲怎么把文档里的零散问题整理成业务规则，再落到模块设计和关键逻辑，然后是性能需求的落地方式，最后是让模板在团队里持续发挥作用的那点技巧。

2. 把车间抱怨变成需求：从「玻璃破损」到可量化指标的转化路径

2.1 原文里的问题清单为什么比功能列表值钱

大多数需求文档的问题在于写得太干净。功能列表整齐，用例规范，但开发拿到手不知道「为什么要有这个功能」。这份 CCAM 文档反着来，它把 16 条问题原封不动写在功能需求前面。这些问题的价值在于它们自带业务上下文，比如第 2 条：「铝材刮伤严重，可以再利用的铝材没有再利用（存在人为原因）」。单看这句话，开发只能理解为「做一个铝材管理功能」，但结合第 9 条「玻璃破损统计及破损玻璃的补够」、第 15 条「柜体材料库存不足又没有及时采购，给做个库存上下限」，就能还原出完整的业务闭环。

我一般会把这类问题清单做一次归类，归类的维度不是模块，而是「数据从哪来、谁负责录入、谁消费结果」。以这份文档为例，16 条问题可以归成四组：

这个表不建议照抄，它是用来示范怎么把原始问题重新分组。分组之后，每条问题都要继续追问两个点：数据源在哪、验收口径是什么。

2.2 给需求补上「可计算的验收口径」

拿第 6 条「皮革小库无法控制」来走一遍完整过程。原文描述是：仓库领皮革一捆一捆拿，放到皮革小库，没有记录；希望从领用那天开始记录，再从移门数据统计总共用了多少料，算出利用率，能随时查询。

这句话如果直接交给开发，大概率会做成一个「领料记录表单」。但问两个问题之后就变了：皮革利用率怎么算？分母是领用总量，分子是什么？是订单理论用料量。这里必须有个算料环节来提供理论值，也就是文档里提到的「销售单 CAD 算料」和「备料组」。所以完整的业务规则是：

1. 车间按生产任务单从仓库领料，系统记录领用数量；
2. 每张生产任务单关联算料单，算料单给出理论用料量；
3. 系统按周期汇总：利用率 = 理论用料总量 ÷ 实际领用总量。

这样需求文档里就多了一条可以写进测试用例的验收口径。再比如安全库存那条，原文只说「低于安全库存时需要进行采购」，但真正落地时要确定计算逻辑。常见的做法有两种，一种是按固定值触发，另一种是按日均消耗乘采购周期。对这份文档里的场景，我一般会建议用库存上下限加一个「在途量」修正：

# 采购建议量计算示例（按安全库存与在途量修正） def calc_purchase_qty(material_id, order_demand_qty): # 读取材料档案中的安全库存与最低库存 safety_stock = get_safety_stock(material_id) # 安全库存，低于此值触发预警 min_stock = get_min_stock(material_id) # 最低库存，物理下限 current_stock = get_current_stock(material_id) # 当前可用库存 on_order_qty = get_on_order_qty(material_id) # 在途采购量，已下订单未入库 # 预计可供应量 = 当前库存 + 在途量 available_qty = current_stock + on_order_qty # 缺口 = 订单需求量 + 安全库存 - 可供应量 shortage = order_demand_qty + safety_stock - available_qty if shortage > 0: return shortage else: return 0

这段逻辑对应文档 2.2.2 采购模块里「参照现有库存、安全库存数据，生产常规材料订购单」的需求。on_order_qty这个参数特别重要，很多库存模块漏了在途量，导致重复下采购单。我在项目里见过因为漏掉这个参数，同一种材料下了三张采购单，仓库到货后堆不下的真实事故。计算出来的建议采购量只是参考，实际操作里还要设定一个取整规则，比如铝材按支数向上取整，玻璃按面积向上取整，这个规则建议放在基础资料的材料类型里配置。

2.3 把「人为原因」转化为系统约束

原文里多次出现「存在人为原因」「他们现在是直接去仓库领料，无法控制损耗」。这类描述是需求分析师最容易忽略的——它本质上是在要求系统通过流程约束来替代人工判断。这里有一个关键的转化原则：凡是需要约束的行为，都要变成一个「如果不这么做，系统就不往下走」的规则。

文档里对应的设计是：移门维修处领料必须先到下料处签字，再凭单据到仓库领料；仓库重复领料必须通过要货单出库，否则视为损耗，填写损耗单后才能出库。这就是典型的「单据流转控制」。落地时要注意一个细节：系统要支持「例外流程」，否则实际运行两周就会被业务人员绕过。比如加急维修场景，可以让主管权限强制通过并事后补单，但补单行为本身要留痕，包括操作人、时间、原因。

3. 模块拆分与单据闭环：CCAM 系统的主数据、业务单据和执行逻辑

3.1 用一张表理清七个模块的主数据和核心单据

文档把系统功能分成了基础资料、销售、采购、库存、生产、售后服务、绩效七个模块。这七个模块不是孤立的，它们通过单据串联。我把文档中涉及的主数据和单据整理如下，这张表可以用在需求评审会上让业务方确认，也可以在开发阶段作为数据库设计的起点：

这里有一个容易在实施时踩的坑：主数据模块常被低估。文档里第 10 条问题「玻璃的叫法不同，使商品信息无法完成，要规范材料编码与名称」，看似只是编码问题，实际牵扯整个系统的数据质量。我在类似项目里总结的经验是，材料编码规则一定要包含「分类段 + 规格段 + 属性段」，比如玻璃可以编码为GL-08-33-ARG（玻璃-厚度 8mm-色号 33-镀膜）。文档里铝材信息包括模具编号、长度、宽度、表面处理、槽深槽宽，这些都要设计进材料属性表，否则后续的 CAD 算料根本没法取数。

3.2 销售订单到采购订单的自动推导逻辑

这份文档里最值得展开的业务逻辑，是销售订单经过 CAD 算料后自动传导到采购模块。原文描述是：销售单 CAD 算料得到用料单，然后与库存比对，常规材料自动分到各供应商产生几张订单，同时产生定制材料用料单和采购订单、待入库单。

这个流程的核心是一个「MRP 运算」的简化版。我把完整链路拆成五个步骤：

1. 销售订单审核通过后触发算料，系统根据成品类型和产品参数生成用料单明细；
2. 用料单明细与库存比对，区分「库存充足」「库存不足」「完全不缺」三类；
3. 库存不足的材料，判断是常规材料还是定制材料；
4. 常规材料按供应商分配规则自动拆分采购订单；
5. 定制材料生成用料单，由采购员人工询价后转采购订单。

其中第 4 步的拆分逻辑就是文档里说的「自动分到每家供应商处」。供应商分配规则一般有三种配置方式：按材料类别指定主供应商、按历史供货比例轮询、按最低报价优先。这里给出一段简化的拆分示例：

# 采购订单自动拆分逻辑示意 def split_purchase_orders(shortage_list): """ 按供应商分配规则将缺料清单拆分为采购订单 :param shortage_list: 缺料明细，元素为 (材料编号, 缺口数量, 期望到货日) """ # 1. 读取供应商分配规则：材料类别 -> [(供应商, 份额比例), ...] rules = get_supplier_allocate_rule() orders = {} for mat_code, qty, expect_date in shortage_list: # 2. 检查材料类型是否常规，非常规材料不做自动拆分 if not is_regular_material(mat_code): continue # 3. 按比例拆分数量，取整规则按材料的采购单位 for supplier_no, ratio in rules[mat_code]: allocated_qty = round_up(qty * ratio, get_round_rule(mat_code)) if allocated_qty <= 0: continue # 4. 同供应商合并成一张采购订单 orders.setdefault(supplier_no, []).append( (mat_code, allocated_qty, expect_date) ) # 5. 生成采购订单号并落库 for supplier_no, items in orders.items(): create_purchase_order(supplier_no, items) return orders

参数说明：shortage_list由库存比对环节生成，round_up的取整规则必须与材料主数据的计量单位一致，铝材按支、玻璃按平方米；expect_date是从销售订单的安装日期倒推出来的，倒推天数一般在基础资料里配置。这段逻辑放到生产环境之前，至少要跑一次全量历史数据模拟，拿上一年度的销售订单反算采购单，跟实际采购单对比，验证分配比例设置是否合理。我在一个项目里做过这类验证，发现比例设置成平均分配时，实际会产生大量小批量采购，采购员的工作量翻倍，后来改成了按材料金额保证同一张订单的金额下限才解决问题。

3.3 缺料单与生产排产的联动

生产模块里还有一个容易被忽略的设计点：加急单不能超出日产量的 N%，由生产厂长自由设定，系统能显示材料不足的、可能不足的、采购材料未到不能生产的。这个需求实际上是把生产排产和材料齐套率绑定。

实现的关键在于给每个材料定义一个「齐套状态」。常见做法是在生产任务单上增加一个状态字段，取值及判断逻辑如下：

这块我要特别提示一个文档里没有展开的点：生产模块排产后的「出库指令、备料指令、待入库指令」要发给哪一级组织。文档里提到「发到各部门及各组」，但实际项目实施时要先做组织和角色的梳理，至少区分部门、班组两层。否则指令发给部门，部门没有班组长账号，还是会退回纸质单据流转。

4. 非功能性需求不是摆设：性能、安全、兼容性怎么落实到测试和配置

4.1 从文档里的三个数字反推容量规划

文档的性能需求写得相当具体：支持并行操作的用户数 50 个；欲处理的事务和任务数量 300 个；峰值条件下 1000 秒时间周期中处理的数据总量 1 个，即 1 秒一个事务。这些数字放在 2008 年是合理的，但今天拿来直接用肯定不行，要用当下的系统能力去审视。

50 个并发用户是一个很重要的数字。这不是指系统注册用户 50 人，而是指同时在线执行操作的用户数。按一般的经验，企业应用的同时在线率大约在 20%-30%，50 个并发意味着实际使用用户数在 150-250 人左右。对应到硬件配置上，2008 年的方案可能是单台数据库服务器加若干客户端，现在我会建议：

• 应用服务器 4 核 8G，数据库服务器单独 8 核 16G；
• SQL Server 2005（文档里的软件接口写的是 MS SQL 2005）升级到 SQL Server 2019 或 2022，但要注意文档里提到的存储过程和表结构是否兼容。

每秒一个事务这个指标，今天的普通硬件轻松满足，但要注意「事务」的类型。如果是成品入库审核这类写操作，问题不大；如果是销售订单查询这种涉及多表联查的操作，「一个事务」的响应时间差异会很大。我在做需求评审时会要求把事务类型拆分：OLTP 型联机事务要区分简单查询、复杂查询、写操作的响应时间目标，文档里没有区分，落地时要补。

4.2 把「可用性 95%」转换成可执行的监控和压测方案

文档第 3.5.3 节提到「核心操作可维护率达到 95% 以上」。这个表述其实是把「可用性」和「可维护性」混在了一起。可用性的标准定义是系统可用时间占比，可维护性更准确的说法是「故障平均修复时间」。我建议在需求阶段就把它明确成两个指标：

• 可用性：月度系统可用时间占比 ≥ 99%，排除计划内维护窗口；
• 可维护性：单次故障的平均诊断和恢复时间 ≤ 2 小时。

有了指标之后，还要落到验证手段。对这套系统而言，压测场景至少覆盖三个：50 用户同时做销售订单录入、30 用户同时查询库存报表、批量导入用料单时事务的响应变化。这里给出一段 JMeter 压测脚本里的关键参数配置示例：

# jmeter 场景配置片段，用于模拟 50 并发销售订单录入 Thread Group: Number of Threads: 50 Ramp-Up Period: 10 Loop Count: 10 # 10 秒内启动 50 个线程，每个线程循环 10 次 HTTP Request: Protocol: https Server: ccam.example.local Path: /api/sale/order/create Method: POST Body: {"customerId": "${customerId}", "items": [...]} # 使用 CSV 数据集配置读取不同客户编号，避免并发写同一主数据

参数说明：Ramp-Up Period 设为 10 表示 10 秒内逐步启动 50 个线程，避免瞬时并发导致假性失败；Loop Count 设为 10 是为了让压测持续一段时间观察内存和连接池表现。CSV 数据集配置里的客户编号要准备至少 50 条不同数据，这样每个线程操作不同客户，更接近真实场景。压测时我还要同时监控数据库的连接数和主表的锁等待时间，这两个指标最能反映问题所在。

4.3 安全与审计需求在制造业系统里的实施细节

文档里的安全需求提到帐号限定功能、审计追踪、数据备份、检查点恢复这些点，还有「财务封帐后不能对上期单据进行任何更改」「销售订单调整必须开具变更单，对原始记录作备份后再更新」。制造业系统的安全重点跟互联网系统不一样，前者更看重「数据不可篡改」和「操作可追溯」，而不是防注入和防 DDoS。

落实到具体设计，至少要有这几层：

1. 功能权限：按模块和操作按钮分配，库存模块操作员不能看到销售价格；
2. 数据权限：销售只能看自己片区的客户和订单，财务能看全部；
3. 封帐控制：财务封帐后在系统层面锁定该时间区间的所有单据，任何模块不能通过 UI 修改；
4. 变更留痕：所有更新操作写操作日志，日志包括操作人、时间、旧值、新值、终端 IP。

这里有一个特别实用的做法：销售订单变更单不直接 update 原记录，而是「先复制一条新版本，标记原单作废」。这类设计在后面的第 5 章讲模板复用时要再提到，它不只是技术选择，而是需求阶段就该确定的业务规则。

5. 模板复用的边界：怎么把旧文档改造成能持续维护的需求资产

5.1 版本管理的技巧：每次变更给到每一个人

原文档的版本记录表列了版本号、修改批准人、修改人、安装日期、签收人几项，还专门强调「每次的改动转发给每一位相关工作人员」。这个要求在 2008 年意味着发邮件、打印签字，今天做起来可以更轻，但核心逻辑一样：需求变更必须同步到所有角色。

我在实际项目里会把这份模板里的版本记录改造成「需求变更日志」，每一行记录对应一次评审通过的需求变更，包含：变更编号、变更内容、涉及模块、影响范围、评审结论、生效日期。关键是「影响范围」这一列，必须写清楚影响到哪几个已有功能。举例：把「安全库存触发采购」改成「安全库存 + 在途量触发采购」，影响范围就包括库存查询、采购建议、缺料提醒三处。这个表格存放在需求文档的附录里，每次变更都追加，版本号同步递增。

5.2 附录模板的两个坑

这份文档的附录列出了输入输出格式样本、用户调查结果、背景信息、交叉访问表等。用下来有两个坑要避开。

第一个坑是「用户调查结果」直接贴原始记录。车间操作员的原话、领导的访谈记录不加整理就放进附录，后面评审时每人看到的重点都不一样。我一般会把访谈记录先归并成「问题清单」，每条标注提出人角色、发生频次、业务影响，再放进附录。这样评审时讨论的是问题本身，而不是某一句原话。

第二个坑是「交叉访问表」没有说明更新频率。附录里放了一张表说明哪些需求在哪些章节出现，但如果不维护，这张表半年后就失效了。我的做法是：在文档里加一行说明，注明「本节内容由需求负责人维护，随基线变更同步更新」，并把维护责任落实到人名和岗位，而不仅仅是写一个「需求工程师」的职位。

5.3 从需求模板到需求基线的收尾动作

模板也好，规范也罢，最后都要落到「基线」这个概念上。一份需求文档如果只有初稿日期和版本号，没有基线标识，开发过程中改了几轮之后，很可能出现开发和测试拿着不同版本的工作局面。操作上建议：每轮评审通过后打一个基线号，比如CCAM-SRS-BASELINE-2025-01，基线内冻结需求，后续变更走变更单流程。变更单里要列出对测试用例、用户手册、培训计划的影响说明。这个动作是让模板真正成为「活文档」的关键一步——它不增加多少工作量，但能省掉项目后期大量扯皮的时间。

把文档里的 16 条问题逐条转化、把七个模块的单据闭环理清、把性能数字翻译成压测场景，这份 2008 年的需求说明书的剩余价值就基本提取干净了。下次再拿到类似的旧需求文档，不妨先从「问题清单」开始看，而不是先研究它的模块结构。

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