1. ELN系统需求分析与用户角色建模

电子实验记录系统（Electronic Lab Notebook，ELN）不是把纸质记录本简单搬到浏览器里，而是把科研活动中"记录—检索—审批—导出"这条证据链数字化、可追溯化。需求分析的第一步，不是急着画界面或选数据库，而是识别谁在用系统、他们各自要完成什么任务、这些任务之间存在怎样的依赖与约束。本章围绕科研人员、实验室管理员、合规审计员三类核心角色，梳理其记录、检索、审批、导出需求，并输出可落地的用户故事与用例图。

一、从角色出发：谁在系统里做什么

ELN系统的角色划分不能按"职位高低"来分，而应按"对数据的操作权限与责任边界"来分。科研人员是数据的生产者，实验室管理员是资源与流程的协调者，合规审计员是证据的检验者。三者的关注点不同，需求自然不同。

科研人员的核心诉求是"低摩擦记录、高精度检索"。他们需要在实验过程中快速录入实验目的、材料批次、仪器参数、原始数据、观察现象与结论，并希望系统自动记录时间戳、操作者身份和版本号。检索需求集中在按项目、化合物、仪器、日期、关键词组合查询，且要求能定位到某一条具体记录而非整本笔记。

实验室管理员关注的是"流程可控、资源可查"。他们需要审批实验记录的提交与修改，管理仪器预约、试剂库存与人员权限，并确保记录在归档前完成必要的复核。审批需求包括：待办列表、审批意见、退回修改、电子签名。

合规审计员的需求是"可追溯、可导出、不可篡改"。他们不关心实验内容本身，而关心记录是否完整、修改是否有痕迹、签名是否有效、导出格式是否符合监管要求（如21 CFR Part 11、GMP）。导出需求通常要求PDF/A或带审计追踪的归档包。

二、用户故事：把需求写成可验证的句子

用户故事的价值在于把模糊的"我要一个好用的系统"转化为可验收的条件。以下示例采用"作为……我希望……以便……"的格式，并附上验收要点。

• 记录：作为科研人员，我希望在移动端也能快速新建实验记录并自动保存草稿，以便在通风橱旁不中断操作。验收：断网时本地缓存，恢复后自动同步，冲突时提示选择版本。
• 检索：作为科研人员，我希望按"项目+化合物编号+日期范围"组合检索，以便复现三个月前的一次失败实验。验收：返回结果按时间倒序，支持高亮关键词，点击可跳转到原始记录段落。
• 审批：作为实验室管理员，我希望在待办列表中看到所有待审批记录及其提交人、提交时间、变更摘要，以便在24小时内完成复核。验收：支持批量审批，退回时必须填写理由。
• 导出：作为合规审计员，我希望导出指定时间段的完整审计追踪PDF，以便应对监管检查。验收：导出文件包含记录ID、版本历史、签名证书指纹，且不可编辑。

三、用例图：看清角色与功能的边界

用例图的作用是快速呈现"哪些角色与哪些功能发生交互"。下图以三类角色为主角，展示记录、检索、审批、导出四组核心用例及其包含关系。其中"记录"包含"自动保存版本"，"审批"包含"电子签名"，"导出"包含"生成审计追踪"，这些包含关系体现了ELN区别于普通文档系统的关键约束。

四、从用例到实现：关键约束与数据字段

用例图只说明"谁做什么"，真正落地还需要明确每个用例背后的数据约束。以"记录实验"为例，一条实验记录至少应包含以下字段：记录ID（系统生成，全局唯一）、项目编号、实验标题、实验日期、操作者ID、仪器编号、材料批次号、实验步骤（结构化文本）、原始数据附件（图谱、CSV）、观察现象、结论、版本号、状态（草稿/已提交/已审批/已归档）。其中版本号与状态是ELN区别于普通文档的核心：每次保存生成新版本，旧版本不可删除；状态流转必须由具备相应权限的角色触发。

再以"导出归档"为例，合规审计员导出的不应只是内容，而应包含完整的审计追踪：谁在什么时间创建了记录、谁修改了哪个字段、修改前后的值、审批人签名与时间戳。这些信息通常以独立元数据文件或PDF附件形式随主文档一并导出，且导出动作本身也应被记录。

五、需求优先级与验证方式

识别出需求后，还需排定优先级。可采用MoSCoW方法：Must have（记录、检索、审批、导出四项核心功能）、Should have（仪器预约、试剂库存联动）、Could have（移动端离线、智能推荐）、Won't have（本期不做）。优先级判断依据是"没有它系统是否无法通过验收"。

验证方式上，建议为每个用户故事设计一条端到端测试路径。例如针对"科研人员检索三个月前失败实验"，测试路径为：登录→进入检索页→输入项目编号与化合物编号→选择日期范围→点击查询→检查返回结果是否包含目标记录→点击进入详情→核对原始数据附件是否可下载。这条路径同时覆盖了权限、检索、附件存储三个模块，比单独测试每个按钮更有价值。

最后需要强调，用户角色建模不是一次性的。随着实验室规模扩大或监管要求变化，可能出现新的角色（如"项目负责人"需要跨项目查看汇总），也可能出现角色权限的重新划分。因此，用例图与用户故事应作为活文档维护，每次迭代前重新审视角色与用例的对应关系，确保系统始终服务于真实的科研与合规场景。