简介：这份需求规格说明书范例面向美和易思大一卓越项目A类及软件工程课程设计，围绕实验室信息管理系统（LIMS）展开，帮助初学者弄清需求阶段该写什么、章节如何组织、业务边界怎样界定。压缩包内仅含1个doc文件，约6.25MB，正文按引言、系统概述、系统范围、遵循标准、系统角色、功能性需求与非功能性需求等章节排布，目录层级完整，便于直接参考或改写。已有1298人学习下载，适合作为课程作业、项目立项和需求评审的对照材料。文档细化了实验室基础信息、工作流、自动排程、仪器设备、物资、标准与方法、检测业务、编码规则、首页报表及框架系统等模块，并列出系统管理员、设备管理员、样品管理员、检验人员等角色职责；同时覆盖可用性、可靠性、性能、安全性与软硬件环境要求，可帮助读者快速搭建需求清单、梳理业务流程，并模仿其写法完成自己的需求文档。

1. 需求先立住：一份 76 页 LIMS 需求规格说明书要解决的真正问题

接手实验室信息管理系统（LIMS）的人，八成都在某个时间点被同一句话问住：“这功能到底谁提的？”需求文档如果只是把功能列表摊开，写着写着就变成功能清单堆砌，后面做设计、做测试、写验收报告的人全部得返工。这份 76 页的需求规格说明书要解决的正是这件事：把位置、采样点、企业、培训、样品类型、量纲、人员、工作流、自动排程、仪器、物资、标准方法、检测业务、编码规则、首页、报表、框架系统管理这些模块，逐条落到“执行者是谁、业务规则是什么、字段怎么录、非必填项怎么算”，给出一个可以直接当设计依据和验收依据的基线。它适合两类人：正在做大一卓越项目或课程设计、需要一份结构完整需求文档做参照的学生，以及要给实验室做方案交付、需要一份可裁剪需求基线模板的从业者。需求阶段处在开发金字塔塔尖，位置对了后面省一半力气，位置错了后面全在还债。

2. 需求文档的骨架：从系统目标到非功能约束的四层结构

2.1 第一层定边界：系统范围与遵循标准怎么落笔

一份需求规格说明书最先要卡死的不是功能，而是边界。文档第一章到第四章的排布逻辑是先讲目的与范围，再定系统目标、系统说明、假定和约束，最后划出系统范围并列出应当遵循的标准或规范。这个顺序不能乱，因为后面所有功能条目都要能追溯到范围里的一句话。

以这份文档为例，系统目标写了两条：重新定义 LIMS 业务模块；实现能够覆盖既有实验室系统核心使用场景的功能。系统范围则明确列出了 11 项建设内容——实验室基础信息管理、工作流管理、自动排程管理、仪器管理、物资管理、编码规则管理、标准与方法管理、检测业务管理、首页、报表、系统管理优化。这个清单不是装饰，它在验收阶段就是模块级的验收单元：11 项内容每一项都要有自己的功能条目、自己的测试用例集合、自己的验收结论。

标准规范这一章通常只写一条，就是 ISO/IEC 17025《检测和校准实验室能力的通用要求》。很多人写到这里就抄个标准号了事，实际交付里这一条会向下渗透：人员培训要有有效期和资质状态、仪器要有校准与期间核查记录、检测方法要与分析项目关联、原始记录要可追溯。写需求时把这条标准当成“业务规则的来源”而不是“文档的点缀”，后面评审时被追问的概率会低很多。

假定和约束那一章更要写实。这份文档写的是“本系统要求当年 12 月底前完成”，一个硬时间点直接把项目切成倒排期。倒排期意味着需求必须做优先级分级，于是你能看到文档里每个需求都带“使用频度”和“优先级”两个字段：企业管理的频度和优先级都是高，位置管理都是低。这就是需求裁剪的依据——时间不够时先砍低优先级条目，而不是临到上线前才开始吵。

提示：写系统范围时，用“本阶段建设内容包括……”这种可枚举的句式，列出来的每一项都要在后文有对应章节。范围章列了 11 项而后文只有 9 个模块，是评审时最容易被抓的漏洞。

2.2 第二层定人：七类角色与群组权限模型

角色定义这一章看着最像走过场，其实是整份文档里复用率最高的部分。这份文档定义了七类角色：系统管理员（最高权限）、设备管理员（设备维护）、物资管理员（耗材物资）、样品管理员（样品管理）、实验室负责人（实验室负责人）、检验人员（具体检测任务）、实验室主任（各科室主任）。

真正让权限模型能落地的是“群组”这个概念，而它散落在各个功能条目里。位置管理写“位置具有群组权限，只有属于该群组的人员才能查看、编辑、修改”；文档管理写“人员只能查看所属部门群组的文档，或者未设置部门群组的文档”；文档查询重复了同一条规则。这就要求需求阶段就把权限模型抽出来统一表述，否则开发会出现两套实现：一套按角色判、一套按群组判，最后数据串权限。

我一般会把这类权限规则整理成一张矩阵，作为需求文档的附录：

人员管理的字段设计也印证了这一点：部门群组是“自动获取不可修改”，姓名、性别同样自动获取。需求里明确写“人员自动从系统中的用户管理中获取”，也就是说人员模块是框架用户的一次扩展，不是新建一套人员表。这条如果在需求阶段不说清，开发很可能建两张表再写同步逻辑，数据一致性从此是个黑匣子。

2.3 第三层定流程：工作流与自动排程的可配置边界

工作流这一块最容易写虚。这份文档的处理方式值得借鉴：它把工作流拆成“基础信息”和“流程图”两层。

基础信息层管理流程的名称（必填）、所属部门、流程类型（必填）、监控人员（多选）、查询人员（多选）、排序（必填）、描述。功能需求里还列了四类查询视角：待处理的流程、我申请的流程、我参与的流程、我监控的流程，并且明确“对于未完成的流程可以强制关闭”。这四类视角其实就是流程引擎的四个标准视图，写进需求就等于把首页待办、流程中心、监控面板三个界面的数据来源一次性定死了。

流程图层的需求写得更克制：“通过拖拽的方式设计流程图”“使用 B/S 端进行编辑”“能够对业务流程驱动进行二次开发”。文档还专门标注了流程图分两种：样品全流程和一般工作流，前者“为之后的图控显示、表单流程做基础”。这是一句关键约束——它说明流程图不是画完就完，要能被业务驱动执行，所以流程定义的数据结构必须包含节点、流转条件和表单绑定，而不能只存一张图片。

自动排程的需求与之呼应：实现通用的自动排程管理，例如样品自动登录、自动发送邮件，并提供排程日志查看。这里的写法很务实，没有承诺具体的调度框架，只承诺三件事——可配置的定时任务、任务能触发业务动作、有日志可查。日志这一条尤其重要，定时任务出问题时的排查全靠它。

2.4 第四层定质量：非功能需求不是填空题

文档第七章把非功能需求分成五块：可用性、可靠性、性能、安全性、软硬件环境需求。原文只给了标题层面的描述，按这个项目场景，合格的做法是把每一块写成可验证的表述，否则验收时无从判定。

我一般会这样补齐，读者可以直接改字段：

• 可用性：浏览器端为主，关键操作（样品登录、结果录入）的路径不超过三步；列表页支持按代号、名称、描述模糊查询。
• 可靠性：工作流节点流转失败要能回退到上一节点且不丢数据；自动排程任务失败要有日志记录并可手动重跑。
• 性能：常规列表查询在万级数据量下响应可接受；首页提醒一分钟刷新一次，刷新不阻塞页面操作。
• 安全性：按角色加群组双重控制数据可见性；文档上传后按月份自动归档存放；逻辑删除而非物理删除。
• 软硬件环境：客户端需安装 Office 与 PageOffice 才能在网页内查看编辑 Word、Excel 文档，这一条属于强约束，必须写进部署手册。

最后一条是典型的“写漏了就要在现场救火”的条目。文档管理需求里两处提到 PageOffice，如果非功能需求里不重复声明，实施人员部署完发现文档打不开，回头找开发，开发说需求里写了要装插件——这种扯皮在项目里太常见。

3. 功能模块拆解：把 11 项建设内容落成可开发的需求条目

3.1 基础信息七个模块的标识与字段设计

实验室基础信息管理下有七个子模块，每个都带唯一标识号：U009 位置管理、U010 采样点管理、U011 企业管理、U014 培训管理、U015 样品类型管理、U017 量纲管理、U024 实验室人员管理。这个编号体系是需求可追溯的抓手，测试用例、缺陷单、验收报告全部引用这个号，谁也不用猜“那个位置的功能”指的是哪一条。

每个需求条目的模板也值得照抄：标识号、执行者、创建者、创建日期、最后更新者、最后更新日期、使用频度、优先级、业务说明、解决问题、业务规则、先决条件、执行结果、功能需求、差异说明、备注、原型图。其中“使用频度”和“优先级”用于排期，“业务规则”用于约束实现，“先决条件”用于界定环境依赖，“差异说明”用于记录与旧系统的行为差异，这一栏在替换既有系统时价值极高。

以培训管理为例，它的数据模型把“有效期”设计得很聪明：

-- 培训课程基础表（依据需求文档数据模型整理） CREATE TABLE training_course ( course_code VARCHAR(32) NOT NULL, -- 课程代号，手动录入，必填唯一 course_name VARCHAR(128) NOT NULL, -- 课程名称，必填 course_type TINYINT NOT NULL, -- 1 内部培训 2 外部培训 hours DECIMAL(4,1), -- 学时，单位小时，保留一位小数 lecturer VARCHAR(64), -- 讲师，可为外部人员 valid_days INT, -- 有效期，单位天，为空表示长期有效 remind_days INT, -- 重测提醒日期，单位天，为空表示不提醒 remark VARCHAR(255), PRIMARY KEY (course_code) );

这段表结构的关键在 valid_days 和 remind_days 两个可空字段。可空在这里不是偷懒，而是承载业务语义：有效期为空代表这门培训长期有效，提醒天数为空代表不做重测提醒。人员培训记录里的“过期时间”由获取时间加上有效期自动算出，如果课程没有有效期，则培训一直有效；如果当前时间超过过期时间，培训状态显示已过期，并且人员不能直接改回正常状态。这条规则把“资质过期”从人工判断变成了系统判断，是 ISO/IEC 17025 里人员能力管理最容易落空的一环。

量纲管理则有个容易被忽略的细节：需求明确要求“能够显示上下标（如立方厘米 m³）”，并且“能够支持多国语言”。上下标意味着前端不能用纯文本输入框草草了事，要么用富文本，要么用上下标字段分开存。量纲类型是枚举：长度、密度、速度、重量、物资、其它。这类看起来最小的模块，往往是上线后抱怨最多的——单位显示错了，整张原始记录单的可信度就没了。

企业管理的字段数量最多，包括企业简称、中文名、企业类型（多选：供应商、客户、分包商）、英文名、描述、联系人、联系电话、传真、邮件、国家、省份、城市、地址、网址、企业代码，且要求“使用逻辑删除”。逻辑删除这一条要在需求里反复强调，因为一旦物理删除，历史样品关联的企业信息就断了，追溯链直接断掉。

3.2 标准与方法管理：分析项目、分析方法、测试项目三级关系

这一块是整个系统业务复杂度的核心，也是需求文档里最需要画清关系的地方。文档列出了四类对象：分析项目、分析方法、测试项目、控制指标，外加分析项目排序、方法群组、控制指标等级。

它们的关系可以这样理解：分析项目是实验室“能测什么”的能力清单；分析方法是“怎么测”；两者关联后形成测试项目，测试项目才是样品上真正挂的检测项，用于输入检测结果并关联控制指标。方法群组则把不同的测试项目汇总到一起，形成某类样品需要检测的完整项目集合。

-- 测试项目：分析项目 + 分析方法 的关联结果 CREATE TABLE test_item ( item_id BIGINT PRIMARY KEY, analysis_id BIGINT NOT NULL, -- 关联分析项目 method_id BIGINT NOT NULL, -- 关联分析方法 indicator_id BIGINT, -- 关联控制指标，可空 sample_type BIGINT, -- 适用样品类型 sort_no INT, -- 排序，样品模板按此顺序展示 status TINYINT DEFAULT 1 -- 1 启用 0 停用 );

这里的设计说明有两点。第一，测试项目不能直接冗余分析方法的名字和单位，否则方法版本一更新，历史样品的检测依据就跟着变了，追溯性直接报废；正确做法是引用方法主键，历史数据快照另存。第二，分析项目排序是独立需求，因为客户报表和客户查询要按实验室习惯的顺序展示项目，这个顺序跟样品模板的顺序还可能不一样，所以排序字段要允许按场景配置多套。

控制指标和指标等级是结果判定的依据。需求里写“控制指标检测结果的指标参数管理：对实验室样品、原始记录单、采样记录单等的参数进行管理配置，供相关模板使用”。翻译成实现语言就是：模板上的字段不是硬编码的，而是由指标参数配置驱动生成的。这一条如果需求阶段含糊，开发会按某个具体样品写死一张表单，第二种样品进来就得改代码。

3.3 检测业务主流程：样品登录到审批的四道关口

样品全流程管理的需求条目写得很直白：样品登录、分析结果录入、审核、审批。四个动作对应四个角色和四个状态。

样品登录是初始化操作，“能够通过模板进行样品登录操作”。样品模板的价值在于把重复劳动砍掉——同一类样品、同一批测试项目，登录时套模板自动带出项目清单和排序，检验人员只需要填样品信息和采样点。这一步的输入校验要严：样品类型决定可选测试项目，采样点决定位置归属，企业决定客户或供应商身份，三者任一为空都会导致后续报表统计口径混乱。

结果录入由检验人员完成，录入的对象是测试项目而不是样品，这一点必须在需求里说清。审核环节需求写了两级退回能力：“能够退回整个样品，也可以退回单个测试项目”。这是个很实用的设计——整批退回适用于样品信息错误，单项退回适用于某个指标复测。审批环节的退回规则与审核相同。两级退回的粒度差异要写进状态机，否则开发容易做成只支持整单退回，现场就得靠删数据重来。

工作流与这四个动作的关系是：流程定义负责描述节点和流转，业务动作负责在节点上执行。文档特意说明流程图“为之后的图控显示，表单流程做基础”，意思就是流程节点要能绑定表单。这就把工作流引擎和业务表单的耦合点提前暴露了，需求阶段说清楚，比开发到一半发现流程跑不通要省事得多。

3.4 仪器、物资与提醒：三条容易被低估的支撑线

仪器设备管理包含四块：设备信息维护（含使用记录、校准、维护、期间核查）、配件维护、维修流程、报废流程。注意“期间核查”这个词，它是 ISO/IEC 17025 的硬要求，指两次校准之间对设备进行的核查。需求里把它和校准并列，说明这个系统的设备台账不是简单的资产清单，而是带计量管理属性的台账。维修和报废走流程，则意味着这两类动作要留审批痕迹，不能直接在台账上改状态。

物资管理包含物资基本信息、库存明细（入库、验收、出库、返还）、领用申报流程（需结合工作流）、库房管理、库位管理。库位管理那条需求写得很具体：“针对一些贵重物品，需要体现具体库位时使用”。这句话实际上是在做范围裁剪——库位管理不是所有物资都要，只对贵重物品启用。需求里明确了这个边界，开发就不会给每一条耗材都加库位字段，界面也不会被塞满。

提醒管理是个小而关键的功能：登录后提示当前账户需要提醒的事项，弹出提醒框点击后可导航至待处理内容，提醒分已读未读并用颜色区分，类型分为设备、人员资质、物资三类，可查看历史记录，且“一分钟一次刷新提醒内容”。一分钟刷新这个数字属于非功能指标，写进需求就等于定了轮询间隔，避免了后来有人问“为什么提醒不及时”时没法回答。三类提醒正好对应前面三条线：设备校准到期、人员培训过期、物资库存不足，需求在这里完成了闭环。

4. 避坑与排查：这类需求文档最容易翻车的五个点

4.1 现象：功能列表很长，验收时却没法判定通过与否

原因：需求条目只写了“能够对 XX 进行增删改查操作”，没写业务规则和字段约束。查什么、改哪些字段、必填非必填、唯一性怎么保证，全是空白。

解决：每条需求至少补齐三段——业务规则（谁能看、谁能改、群组怎么算）、数据模型（字段、录入方式、是否必填、唯一性）、执行结果（操作成功后系统处于什么状态）。培训管理那条需求就是范本：字段表里明确课程代号必填唯一、学时保留一位小数、有效期为空表示长期有效。

4.2 现象：权限规则散落各处，同一份数据两个人看到的不一样

原因：群组权限写在位置管理里，部门群组权限写在文档管理里，角色权限写在角色定义章里，三处表述互不引用。开发按各自理解实现，测试也没法覆盖全。

解决：把权限抽成独立附录，做成“数据对象 × 权限维度 × 规则”的矩阵，正文功能条目只引用矩阵编号。文档管理里“人员只能查看所属部门群组的文档，或者未设置部门群组的文档”这条规则，就应该在矩阵里有唯一一条记录，被文档管理和文档查询共同引用。

4.3 现象：工作流流程图能画出来，但流程跑不动

原因：需求只写了“拖拽设计流程图”，没定义流程节点与业务表单、业务状态的绑定关系。开发把流程图画成了图片，业务驱动时无节点可执行。

解决：在流程图需求里显式声明流程定义的要素：节点标识、节点类型、绑定表单、流转条件、处理角色。并写明“能够对业务流程驱动进行二次开发”具体指什么——是开放接口、开放脚本还是开放配置，三者的实现成本差一个量级。

4.4 现象：非功能需求写成了形容词，上线后性能和安全问题集中爆发

原因：可用性、可靠性、性能、安全性只写了标题和一句概述，没有量化口径。首页提醒一分钟刷新这类明确指标反而被埋在功能需求里。

解决：非功能需求逐条改写成“场景 + 指标 + 验证方式”。比如性能写成“常规列表查询在万级数据量下响应可接受，验证方式为造数后压测”；安全性写成“按角色加群组双重控制，验证方式为用两个不同群组账号交叉访问同一数据对象”。

4.5 现象：需求文档与原型、数据模型三方对不上

原因：文档里写了原型图章节但图未附、字段表与功能需求描述不一致，比如企业类型在功能需求里写“多选”，在别处又被当成单选处理。

解决：定一条硬规矩——凡是有数据模型的模块，字段表是唯一事实来源，功能需求描述里出现的字段必须能在字段表中找到且类型一致。评审时按模块逐个对表，对不上的当场改。这条规矩坚持下来，后面做设计和建表会顺很多。

5. 验收与答辩：用需求条目做追溯矩阵，把“做完了”变成“可证明”

需求文档最实际的用途，是它同时是验收依据。我在做这类项目的验收准备时，习惯从需求条目反推一张追溯矩阵，而不是从代码或界面去凑清单。具体做法是拿每个需求标识号（U009 到 U055 这一套）做行，横向拉四列：设计文档章节、实现模块、测试用例编号、验收结论。这张表填满，答辩时任何“这个功能做了吗”的问题都能当场定位。

填表时有几个技巧。第一，优先级高、使用频度高的条目必须逐条有独立用例，比如企业管理、培训管理、样品类型管理、量纲管理、实验室人员管理这几条；频度低优先级的条目（如位置管理、采样点管理）可以合并用例，但合并后仍要保留标识号引用，不能整条消失。第二，非功能需求单独一张表，按可用性、可靠性、性能、安全性、软硬件环境五行展开，每行写清验证方法和结论，尤其 PageOffice 这类环境依赖，要在部署环境的机器上实测一遍，别在开发机上验。第三，工作流和自动排程这两块一定要有异常路径的用例：流程强制关闭、排程任务失败重跑、审核退回单个测试项目，这三条是最容易在演示时翻车的地方。

答辩环节，评委最爱问的三类问题基本可以预判：为什么这么分模块、某个业务规则为什么这么定、非功能指标怎么保证。第一类问题用系统范围和 11 项建设内容回答；第二类问题用需求条目里的业务规则原文回答，比如“培训过期后人员不能改回正常状态”是因为资质状态要由系统判定而非人工覆盖；第三类问题直接翻非功能需求那张表，说清指标和验证方式。真正能加分的，是主动说出你做了哪些裁剪以及为什么——库位管理只对贵重物品启用、文档在线编辑依赖客户端插件，这类边界说清楚，比堆功能更能体现你读懂了需求。

从那以后我每次带这类文档，都会在交付前强制走一遍追溯矩阵，一行一行对，对不上的当场补，绝不留到答辩前一晚。这份习惯救过我很多次，也希望帮到你。

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