# 00 编写说明与术语约定 ## 0.1 文档目的 本文件用于统一本目录的编写口径，避免在后续需求分析、数据库设计和课程报告撰写过程中出现术语混乱、编号不统一、分析层次混杂的问题。 本目录中的全部文档均服务于以下目标： - 作为课程设计报告“需求分析”章节的正式素材 - 作为概念结构设计、逻辑结构设计和物理结构设计的前置依据 - 作为答辩时说明数据库设计合理性的论证材料 ## 0.2 编写边界 本目录属于需求分析阶段，因此重点回答以下问题： - 系统为什么要建设 - 系统服务于哪些用户和场景 - 系统需要实现哪些功能 - 系统需要保存哪些数据 - 数据之间存在什么联系 - 系统需要满足哪些完整性和质量要求 - 存在哪些可选方案以及为什么选择当前方案 本目录原则上不展开以下内容： - 最终表结构字段级 SQL 实现 - 完整 E-R 图绘制结果 - 详细索引定义与 DDL 脚本 - 具体接口参数与页面实现细节 如果在需求分析中提前提及主键、外键、约束、触发器等内容，其目的仅是说明需求会如何导向后续数据库设计，而不是在本阶段直接完成实现。 ## 0.3 需求编号规则 为便于后续设计、测试和答辩，本目录对需求采用统一编号规则。 ### 0.3.1 功能需求编号 - 平台基础子系统：`FR-PC-xx` - 功能房预约子系统：`FR-FA-xx` - 课程资源分享子系统：`FR-CR-xx` - 数字图书馆扩展：`FR-LB-xx` 其中： - `FR` 表示 Functional Requirement - `PC` 表示 Platform Core - `FA` 表示 Facility Reservation - `CR` 表示 Course Resources - `LB` 表示 Library ### 0.3.2 数据需求编号 - 平台基础子系统：`DR-PC-xx` - 功能房预约子系统：`DR-FA-xx` - 课程资源分享子系统：`DR-CR-xx` 其中 `DR` 表示 Data Requirement。 ### 0.3.3 非功能需求编号 - `NFR-xx` 其中 `NFR` 表示 Non-Functional Requirement。 ## 0.4 优先级约定 - `高` - 为课程设计主线中的核心需求，必须进入正式设计与实现范围 - `中` - 建议实现，可显著提升系统完整性和数据库表现力 - `低` - 可作为扩展或加分项，不影响主线成立 ## 0.5 术语与缩略语 | 术语 | 含义 | |------|------| | 校园生活平台 | 本课题总题目名称 | | 平台基础子系统 | 指身份与鉴权、组织结构、RBAC、数据范围、审计日志等公共底座能力 | | 功能房预约 | 指校园内部功能房、活动室、会议室等资源的预约管理业务 | | 课程资源分享 | 指围绕专业和课程进行资料投稿、审核、发布、下载统计的业务 | | 数字图书馆 | 作为可选扩展的电子图书/资料共享业务 | | Portal | 面向普通用户的前台使用界面 | | Console | 面向管理人员的后台管理界面 | | BFF | Backend For Frontend，用于承接前台/后台请求并访问数据库的服务层 | | RBAC | Role-Based Access Control，基于角色的访问控制 | | 数据范围 | 在已经具备某功能访问权的前提下，进一步限制其可见数据范围的机制 | | 审计日志 | 对关键管理行为进行追加记录、便于追溯责任和排查问题的数据 | ## 0.6 角色简称约定 在后续文档中，主要角色采用如下简称： - `user`：普通用户 - `staff`：工作人员 - `major_lead`：专业负责人 - `admin`：管理员 - `super_admin`：超级管理员 - `librarian`：图书管理员 ## 0.7 文档使用说明 ### 0.7.1 面向报告撰写 若需要直接撰写课程设计报告，建议优先参考： - `10-正式需求分析稿.md` 再根据需要从支持文档中补充： - 可行性分析 - 功能需求规格 - 数据需求分析 - 方案比较与选型依据 ### 0.7.2 面向数据库设计 若需要继续推进数据库课程设计，建议从以下文档开始： - `05-业务流程分析.md` - `06-功能需求规格.md` - `07-数据需求分析.md` - `11-需求到数据库设计跟踪矩阵.md` ## 0.8 本目录的质量要求 本目录的文档应满足以下要求： - 语言正式、术语规范 - 逻辑完整、章节清晰 - 能与课程设计大纲要求对应 - 能自然衔接到 E-R 图、关系模式、约束和 SQL 设计 - 能在答辩时解释“为什么这样设计数据库”