简介《实验室信息管理系统用户需求说明书》是软件生命周期需求阶段的关键文档面向系统分析师、项目经理及开发维护人员用于统一需求理解、减少后期返工可作为美和易思大一卓越项目A类需求规格说明书的参考范本。压缩包内共1个Word文档大小6.25MB完整收录这份76页说明书。文档系统覆盖实验室基础信息管理、工作流管理、自动排程、仪器设备管理、物资管理、标准与方法管理、检测业务管理等核心模块并明确系统管理员、设备管理员、样品管理员、实验室主任等角色职责同时遵循ISO/IEC 17025:2005标准兼顾可用性、可靠性、性能、安全性与软硬件环境等非功能性要求为构建合规LIMS提供全面指引。全文按引言、系统概述、系统范围、功能性需求、非功能性需求等章节组织附有功能列表与业务规则便于开发团队直接对照实施。现有1296人学习下载是实验室信息化建设及课程设计项目的重要参考资料。1. 这是一份可以当“设计蓝图”用的 LIMS 需求规格说明书做实验室信息管理系统LIMS的人十有八九都经历过这种开场甲方扔过来一份几十页的 Word 文档目录里写着“目的、范围、角色、功能性需求、非功能性需求”翻开正文全是表格和 U0xx 编号读起来枯燥却没人敢说它没用。这份《实验室信息管理系统用户需求说明书》正是典型代表——它把 LIMS 拆成了实验室基础信息、工作流、自动排程、仪器设备、物资、标准方法、检测业务、编码规则、首页、报表等十二个功能域每一条功能都带执行者、使用频度、优先级和业务规则。它解决的不只是“界面上有哪些按钮”而是“谁在什么状态下能做什么、数据怎么流转、退回粒度是样品级还是项目级”。适合正在做 LIMS 新建或升级的产品经理、后台开发以及准备照着写需求文档的人。2. 拆解需求文档骨架角色、标准与十二个功能域2.1 先读角色表六类角色的权限边界决定模块设计文档第五章把系统角色定义得很清楚系统管理员、设备管理员、物资管理员、样品管理员、实验室负责人、检验人员、实验室主任。这些角色不是摆设它们决定了每个功能模块的数据权限边界。文档在位置管理、采样点管理、文档管理等需求中反复出现“群组权限”这四个字意思是同一套界面里不同部门或群组的人看到和执行的数据范围完全不同。这不是菜单权限能解决的必须做成实体级的数据权限在表结构上留好群组标识字段。角色主要功能入口数据权限系统管理员全部模块全量数据设备管理员仪器设备管理本群组设备数据物资管理员物资管理本群组物资库存样品管理员样品登录、样品类型管理本群组样品检验人员分析结果录入分配到个人的测试项目实验室负责人审核、审批、首页报表本部门数据实验室主任审批、人员管理、宏观报表本部门及下级科室这张角色表最大的价值是能直接推导出权限模型的粒度。我一般会先把角色表转成“角色 × 模块 × 数据范围”的权限矩阵再拿矩阵去核对每个功能模块有没有漏控。如果某个模块需求里没写群组权限多半是需求方默认了评审时一定要追问一句这里到底按全量看还是按群组看问清楚再进设计否则后期补权限过滤会动到所有查询接口。2.2 标准与边界ISO/IEC 17025:2005 约束和系统假定项目要求遵循 ISO/IEC 17025:2005《检测和校准实验室能力的通用要求》。很多人把它当成一张证书贴在文档里就完事实际上它直接催生了培训、设备校准、期间核查、文档管理和样品追溯这些功能。标准要求人员经过培训并保持记录所以有了培训管理和人员资质过期提醒标准要求设备校准溯源所以仪器管理里必须包含校准和期间核查标准要求记录可追溯所以样品从登录到批准的全流程每一步都要留痕。写 LIMS 需求的诀窍就是把标准条款“翻译”成功能点而不是在文档开头引用一句标准编号就结束。文档里还有两条容易被忽略的约束。一是时间约束系统要求在 2016 年 12 月底前完成意味着需求方对上线时间有硬性要求排优先级时不能无限展开。二是假定约束这是对现有 LIMS 进行优化同时满足上一代商用 LIMS 产品已经具备的核心功能。这个约束意味着要做旧数据迁移、旧流程兼容不能推倒重来。我遇到这种场景时会把“旧系统数据迁移清单”单独建一个风险跟踪项逐项确认旧编码、历史样品、存量设备档案怎么搬这类工作才是上线延期的最大变数。2.3 一张功能域清单看清十二个模块文档的系统范围部分列出的功能类别按功能性需求列表展开正好是十二个功能域。把它们并成一张总表能避免在细碎的需求条目里迷失方向。功能类别包含模块一句话说明实验室基础信息管理位置、采样点、企业、培训、样品类型、量纲、人员系统的元数据层系统管理优化文档管理、文档查询、提醒管理、系统公告通用后台与辅助能力工作流管理工作流基础信息、样品流程图、一般工作流流程图可配置的流程引擎自动排程自动排程、排程日志定时任务与日志仪器设备管理设备信息、配件、维修、报废设备全生命周期物资管理基本信息、库存明细、领用流程、库房、库位物资与库存管理标准与方法管理分析项目、分析方法、测试项目、方法群组、控制指标实验室方法库检测业务管理样品登录、结果录入、审核、审批核心业务闭环编码规则自动编号配置全局编号生成首页待处理流程、样品数据入口登录后的工作台报表样品数据查询、报告样品查询、设备查询、消耗品统计查询与统计框架系统管理复用框架1.0平台级能力复用光看这个表容易把“检测业务管理”当成唯一的业务实际 LIMS 的价值恰恰在前几类配置能力上。做项目时我的建议是严格按功能类别建需求分组每个组指定一个负责人去跟开发对字段否则需求条目混在一起后面做需求追溯时会非常痛苦。3. 把功能性需求落成功能清单从元数据到检测闭环3.1 需求条目怎么读以 U009 位置管理为例需求文档中每个功能点都有一组固定属性标识号、执行者、创建日期、使用频度、优先级、业务说明、业务规则、先决条件、执行结果、功能需求、差异说明、备注。以位置管理 U009 为例执行者是系统管理员使用频度低、优先级低但业务规则里有三个字“多层级”——位置中能够包含子位置如一厂下有三条生产线。这就是建表的关键约束位置要有群组标识做数据权限隔离要有父标识做树形结构默认类型是工厂和装置。这种“同一类实体无限层级 按群组隔离”的设计在 LIMS 里到处都是采样点、样品类型、文档目录都带子结构。我一般会在需求评审时统一确认三件事哪些实体需要树形结构最大深度是多少哪些字段非必填哪些是逻辑删除群组权限为空时代表什么含义——文档里写的是“群组数据可以为空”那空值就必须解释成“所有人可见”这个语义不确认清楚前端做权限过滤时就会漏掉空值数据。3.2 元数据层基础信息管理七个子模块怎么读基础信息管理覆盖位置、采样点、企业、培训、样品类型、量纲、人员。其中企业管理支持供应商、客户、分包商三种类型多选并明确使用逻辑删除这条直接决定数据库设计里不能物理删行只能打删除标记。培训管理给了一份完整数据模型课程代号手动录入且唯一、课程类型分内部/外部培训、学时保留一位小数、有效期单位天、重测提醒日期单位天。“保留一位小数”这种细节说明需求方对 ISO 记录要求很严格字段精度从一开始就要定好。培训过期和人员状态是联动计算的若当前时间过了培训过期时间人员状态必须显示为已过期且不能手动改回正常。这套逻辑不能只靠前端判断我在落地时通常做两层查询接口实时计算培训过期时间同时每小时跑一次批量任务把过期状态落到人员资质表上避免列表页每次打开都做全表计算。量纲管理里还有个前端大坑量纲要能显示上下标比如 m³还要支持多国语言。普通输入框存纯文本没问题但展示到表格和报表时需要处理 Unicode 上下标提前跟前端声明不要用富文本强解。3.3 系统管理优化文档、提醒与公告的交互细节文档管理和文档查询是一对一个负责上传维护一个负责全局检索。需求里明确“附件上传至服务器后按照月份自动存放”这意味着文件存储路径要按年月建目录文档类型用下拉维护包括原始记录、作业指导书、体系文件、国家标准等还要支持在网页上联机查看编辑 Word、Excel 文档这在 B/S 架构下通常依赖在线 Office 控件客户端环境兼容性是个隐藏风险点后面第 5 章会专门说。提醒管理是登录后的弹窗要求一分钟刷新一次已读和未读用颜色区分。这个功能实现不难但轮询接口要做轻量化。我一般会这样写// 每分钟拉取一次未读提醒避免全量加载历史记录 async function pollReminders() { const params new URLSearchParams({ pageSize: 10, unreadOnly: true, }); const res await fetch(/api/reminder/unread?${params}); if (!res.ok) return; const { rows } await res.json(); // rows: [{id, type: device|person|material, title, readFlag, navigateUrl}] rows.forEach((item) { if (!item.readFlag) { appendToReminderBox(item); } }); } setInterval(pollReminders, 60 * 1000); // 与需求一致1分钟一次 pollReminders();代码里的 pageSize 限制为 10 条、unreadOnly 只查未读是为了让轮询接口在低配服务器上也能稳定跑。navigateUrl 由后端按提醒类型拼好前端不用关心业务跳转逻辑。如果提醒表数据量继续增大可以再加一个增量游标把“查最近未读”变成“查上次轮询之后的新增”进一步降低数据库压力。系统公告模块则简单很多标题、内容、创建人、时间、是否置顶、状态发布/草稿支持附件和 HTML 编辑注意多条置顶公告同时存在时的排序规则即可。3.4 工作流与自动排程用状态机语言翻译“退回与监控”工作流基础信息包含流程名称、所属部门、流程类型、监控人员、查询人员、排序、描述。需求里特别提到两类人员配置监控人员能够查看流程监控信息对于未完成的流程可以强制关闭查询人员能查相关流程信息。这说明工作流需要有“强制终止”的后门不能只有正常流转路径。流程图通过 B/S 端拖拽设计包含样品全流程和一般工作流两类——这会带出流程定义的版本管理问题旧流程实例在新版本发布后如何继续流转需求文档没写但实施时必须问清楚。自动排程负责样品自动登录、自动发送邮件等任务并记录日志。常见实现是给每种排程任务设计一个配置模板配合 cron 表达式执行。样品登录、审核、审批几个环节更关注状态流转单个测试项目的回退和整个样品的回退粒度完全不同。给一个最小状态机骨架sample_registered: label: 已登录 transitions: - to: result_entry action: 开始录入 - to: cancelled action: 作废 result_entry: label: 录入中 transitions: - to: pending_review action: 提交审核 - to: result_entry action: 项目回退 pending_review: label: 审核中 transitions: - to: pending_approval action: 审核通过 - to: result_entry action: 样品回退 pending_approval: label: 审批中 transitions: - to: approved action: 批准发布 - to: pending_review action: 审批退回 approved: label: 已批准 transitions: []这个 YAML 表达的是状态转移的最小集合。注意回退动作的流向项目回退要回到结果录入状态供检测人员重录样品回退也要回到结果录入状态但触发的是整个样品维度而不是单条项目。转发表里每个 transition 都要带上触发角色和条件表达式前端设计器才能把拖拽出来的图生成可执行的流程定义否则图只是好看的摆设。3.5 仪器、物资与标准方法三个需要先行建模的模块仪器设备管理覆盖设备信息维护、使用记录、校准、维护、期间核查、配件维护、维修流程、报废流程。这类数据的核心特征是状态多在用、校准到期、维修中、报废待批。校准到期要接进提醒管理作为设备类提醒的源头否则评审员来检查时会现场翻车。物资管理在基础信息之上增加了库存明细入库、验收、出库、返还领用要结合工作流审批。如果实验室有多个库房还要做库房和库位管理。最容易出问题的数据模型是“批次”一批试剂拆分成多个库位存放时库存明细要记录到批次加库位粒度不能只记总数。标准与方法管理是 LIMS 区别于普通业务系统的“配方库”分析方法与分析项目关联后形成测试项目测试项目挂控制指标方法群组决定一份样品需要做哪些测试项目。分析项目排序用于生成客户报表和查询。读这个模块时要抓住“分析项目、分析方法、测试项目”三个实体的关系很多 LIMS 项目做不下去就是把这三张表只建了两张导致检测结果无法关联到具体的分析方法和控制指标。我一般会先画一张实体关系草图确认三张表的主外键关系再往下拆字段。3.6 检测业务管理样品登录到批准的四步状态机检测业务管理是核心链路样品登录、分析结果录入、审核、审批。样品登录能用模板批量登记减少重复录入审核和审批都能退回整个样品或单个测试项目。这里隐含两个数据要求一是样品要有“样品状态”和“项目状态”两个维度二是回退之后要让对应角色在待办列表里立刻看到。审核动作发生后检验人员录入的结果要进入只读或可重录状态这些都要在状态机里定义清楚。首页和报表模块则把以上数据汇总展示首页提供待处理流程、样品数据入口报表区提供样品数据查询、报告样品查询、设备查询、消耗品统计。消耗品统计在需求里标注“待定”说明这一项需求还不完整排期时要单独列出来不要当成已完成需求写进合同。4. 隐性约束比功能更坑编码规则、提醒、性能与安全的注意4.1 编码规则自动编号配置的边界与坑编码规则模块负责样品编号、报告编号等系统自动生成编号。需求只写了“根据定义的编码自动生成编号”但真正落地时并发、唯一、重置、删除回收全是问题。常见配置长这样{ ruleName: 样品编号, prefix: SL, datePart: { enabled: true, format: yyyyMM }, seq: { length: 4, start: 1, reset: monthly }, isUnique: true }参数说明prefix 是固定前缀datePart 决定编号里带不带年月seq.length 决定流水号位数start 是起始值reset 按月还是按年重置直接影响编号连续性isUnique 表示全库唯一一般靠数据库唯一索引兜底不能只靠应用层判断。这里有个经典坑删除了一条样品记录编号要不要允许重新使用如果重新使用审计时按编号追溯就会错乱。我一般会采用“删除标记但保留编号”的方案编号一旦分配就不回收算是给审计留了一颗后悔药。4.2 提醒管理一分钟刷新背后的实现约束提醒来源有三个设备、人员资质、物资。设备到期校准、人员培训过期、物资库存不足都会产生提醒。登录后弹窗展示一分钟轮询一次。这里有两个教训第一轮询接口千万不要返回全量历史提醒否则用户一多数据库查询会越来越慢要限定未读加最近 N 条第二已读状态要落库不然用户每次刷新都看到同一个弹窗会被当成系统 bug 提上来。技术上也可以优先考虑在登录时全量拉取一次登录后靠 WebSocket 或 SSE 推送增量提醒。一分钟轮询适合提醒量小、服务器压力不大的场景如果想先按文档做轮询也一定要把推送方案的接口预留好后面对接消息中心时不用改前端结构。4.3 非功能性需求性能、安全与软硬件环境的落地考量文档列出了可用性、可靠性、性能、安全性、软硬件环境但没有写具体指标这需要在需求评审阶段继续澄清。按我在 LIMS 项目上的经验至少确认三组参数并发用户数——实验室往往是几十人同时录结果并发不高但月底报表查询压力大数据保留周期——样品数据按年归档归档策略直接影响表分区设计文件存储方式——文档附件走独立文件服务器还是数据库走数据库会拖垮性能独立文件服务器要考虑备份和恢复。非功能类别需求原文要点落地时的注意可用性界面友好首页要聚合待办、提醒、样品数据入口可靠性数据可靠回退、审核操作需要事务和操作日志性能快速响应报表查询建索引附件走独立存储安全性权限管控菜单权限加群组数据权限双重控制软硬件环境未明确确认服务器型号、客户端控件、浏览器兼容范围文档里最容易被跳过的是“框架系统管理复用框架 1.0”很多开发以为不用动最后所有权限、用户、菜单都卡在框架上。建议把它当作一个独立任务至少留出两天的联调时间跟新功能模块的权限点逐个对齐。5. 常见问题排查需求落地时踩过的五个坑5.1 优先级“高”了半年没开发现象需求清单中十几个模块的使用频度和优先级都标“高”开发排期排不下最后上线只交付了检测业务管理其他模块全部延后。原因使用频度反映的是操作频率优先级反映的是业务紧迫性文档里把两个概念混在一起等于没有区分开发只能按自己理解挑模块做。解决用 MoSCoW 方法重新排序。必须做的是样品登录、结果录入、审核、审批、报表应该做的是工作流、自动排程、仪器维修可以做的是培训、文档管理暂缓的是框架优化。每次评审拿到需求先重排一遍不迷信文档上的“高”字。5.2 多级位置做成了两层现象需求写明“位置能够包含子位置如一厂下有三条生产线”前端树控件建完只能建两级第三条线挂不上去。原因实现时只做了单层父子关联没有考虑递归查询和无限制深度表结构和查询逻辑都没为多层预留。解决表结构用父标识自关联查询时按层级路径字段加速前端树组件开启懒加载只有展开节点时才请求子节点对深度不预设上限但要在界面上提示当前层级数量。5.3 培训过期状态“算不对”现象培训记录的有效期自动计算了但人员列表里状态一直显示“正常”即使培训过期时间已经过了。原因需求原文说的是“若当前时间已超过培训过期时间则状态显示已过期”但谁去算、多久算一次、算完存哪里没人实现前端也不做判断。解决在人员查询接口里实时比较“当前时间大于培训过期时间”来动态判断状态同时加每小时批处理把过期人员的培训状态统一置为“已过期”。不要让前端拿本地时间自己判断前后端时钟偏差会直接导致显示不一致而且不同终端看到的结果会互相矛盾。5.4 工作流设计器拖完了发布就崩现象拖拽设计流程图时看着正常发布后流程实例跑到一半找不到下一步节点流程直接卡死。原因图形编辑器只保存了画布坐标没有保存节点类型和转移条件或者保存了但没有校验“每个节点必须有出度和入度”导致发布了一个残缺流程定义。解决设计器保存时输出统一的流程定义 JSON发布前校验节点唯一、连接完整、至少存在一条从开始到结束的通路同时对旧版本流程实例做隔离——旧实例继续用旧定义跑完新实例用新定义启动避免线上运行中的流程被新版本打断。5.5 在线编辑 Word 文档白屏现象在文档管理里点开 Word 附件网页白屏在线编辑控件一直加载不出来用户只能干瞪眼。原因在线编辑控件需要客户端安装且只支持特定浏览器和 Office 版本HTTPS 页面默认阻止控件加载或者域名白名单没配导致控件被浏览器拦截。解决实施时先验证域名协议和浏览器兼容矩阵写一个诊断脚本检查客户端是否已安装控件给出明确提示同时提供“下载到本地编辑后再上传”的兜底路径不要把在线编辑当作唯一方式否则客户端环境一变就全线卡死。6. 进阶用法把需求文档变成测试用例和追溯矩阵文档里的每个“功能需求”本质上是一条可验收的业务规则一个 U 编号对应一组测试场景这套编号体系正好能当需求 ID 用。比如 U009 位置管理测试可以拆成四组基础增删改查和必填项校验层级关系——创建子位置、删除父位置时子位置如何处理群组权限——A 组用户不能看见 B 组位置数据查询条件——代号、名称、描述模糊搜索。把这些测试用例直接绑定到 U009验收时按编号逐条核对没人能浑水摸鱼。我更常用的做法是先把文档里的编号和字段抽出来建立追溯矩阵用一个小脚本清扫一遍import re def extract_requirement_ids(text): # 匹配形如 U009_位置管理、U010_采样点管理 的编号 pattern re.compile(r(U\d{3})[_\s]([\u4e00-\u9fa5A-Za-z])) matches pattern.findall(text) seen [] for m in matches: if m not in seen: seen.append(m) return seen ids extract_requirement_ids(raw_doc_text) for code, name in ids: print(f[{code}] {name})脚本用正则把 U 开头三位数字的标识全部扫出来得到一份去重后的编号清单。拿到清单后在 Excel 里建三列需求编号、对应测试用例、开发状态每周同步一次需求覆盖度一目了然。文档里带“待定”标记的项直接列为 TBD不写入验收范围优先级富余的项按 Can 等级处理防止范围继续蔓延。最后一条经验任何 LIMS 需求文档我都会先跑一遍“主链路演练”——拿检测业务管理章节用白板画出“样品登录到结果录入、审核、审批、报表”的完整状态流转画不出来的地方就是需求缺口。画完再动手写代码后面返工的成本能少一半。从那以后我每次拿到需求文档都强制先做编号梳理和字段清单再谈界面和交互。希望帮到你。本文还有配套的精品资源点击获取
