# 08 非功能需求

## 8.1 说明

非功能需求用于描述系统在性能、安全、可靠性、可维护性和可测试性等方面应达到的质量要求。对于数据库课程设计而言，非功能需求的重点并不在于超大规模互联网指标，而在于：

- 数据完整性是否有保障
- 并发一致性是否被考虑
- 权限与审计是否清晰
- 查询与统计是否具备基本性能支撑
- 设计、实现和测试是否可追溯

## 8.2 非功能需求清单

| 编号 | 类别 | 需求内容 | 验收或衡量口径 |
|------|------|----------|----------------|
| NFR-01 | 性能 | 常规分页查询应在可接受时间内返回结果 | 主线模块典型列表查询具备稳定响应 |
| NFR-02 | 性能 | 房间占用查询和排行统计应具备基本可用的响应性能 | 核心查询需有明确索引支撑 |
| NFR-03 | 性能 | 统计类需求应尽量依托结构化事实数据实现 | 排行和统计不依赖人工汇总 |
| NFR-04 | 安全 | 未登录用户不得访问受保护业务数据 | 访问控制与身份校验有效 |
| NFR-05 | 安全 | 管理端操作必须经过角色权限校验 | 后台写操作受 RBAC 保护 |
| NFR-06 | 安全 | 已授权用户也只能访问其数据范围内的数据 | 数据范围控制在后端生效 |
| NFR-07 | 安全 | 敏感信息不得在业务库中明文暴露 | 密码、密钥等不以明文存储 |
| NFR-08 | 一致性 | 多表联动操作应通过事务保证原子性 | 关键流程需具备事务边界 |
| NFR-09 | 一致性 | 同一房间同一时间段不应出现冲突预约 | 应存在明确冲突控制方案 |
| NFR-10 | 一致性 | 资源状态与审核、发布时间字段应保持一致 | 数据库层或事务层具备一致性保障 |
| NFR-11 | 一致性 | 积分和下载统计应避免重复和错乱 | 关键事件具备幂等或唯一性控制 |
| NFR-12 | 可靠性 | 关键业务失败时不应留下明显不一致数据 | 多表更新失败可回滚 |
| NFR-13 | 可靠性 | 审计日志应长期保留关键管理行为记录 | 审计数据具备追加性和可追溯性 |
| NFR-14 | 可维护性 | 需求文档、设计文档和实现应保持一致 | 需求与设计存在明确映射 |
| NFR-15 | 可维护性 | 数据结构命名应规范、清晰、可解释 | 表名、字段名和约束命名规范化 |
| NFR-16 | 可维护性 | 关键业务规则应尽量通过数据库结构和约束表达 | 不应全部散落在应用层判断中 |
| NFR-17 | 可用性 | 普通用户应能完成预约、查询和投稿等核心操作 | 主流程清晰、错误提示可理解 |
| NFR-18 | 可用性 | 管理端应便于找到审核、配置和统计入口 | 后台操作路径清晰 |
| NFR-19 | 可测试性 | 系统应能针对完整性约束和异常输入进行测试 | 至少具备约束失败样例和业务流程测试 |
| NFR-20 | 文档质量 | 课程设计报告应格式规范、结构清晰、术语准确 | 可直接服务于课程评审与答辩 |

## 8.3 性能需求分析

### 8.3.1 查询性能需求

本课题的典型查询包括：

- 用户、角色、部门等后台分页查询
- 房间按楼房、楼层和时间窗口查询
- 课程资源按专业、课程和关键词查询
- 下载榜、积分榜和房间使用榜查询

由此可得出以下性能导向：

- 高频过滤字段应具备索引支撑
- 时间范围查询需重点考虑组合索引或范围索引
- 统计查询应尽量建立在结构化事件数据之上

### 8.3.2 性能边界说明

本课题并不以超高并发互联网场景为目标，因此性能目标重点在于：

- 在课程演示规模下运行稳定
- 对关键查询有可解释的物理设计依据
- 能说明为什么需要某些索引或统计结构

## 8.4 安全需求分析

### 8.4.1 认证与授权安全

- 未登录用户不能访问需要登录的数据
- 管理端功能需要角色权限控制
- 模块访问权与数据可见范围应分层控制

### 8.4.2 数据访问安全

- 普通用户默认只能访问自己的预约和资源投稿等个人数据
- 专业负责人只能访问其负责专业范围内的数据
- 管理员访问行为需要受权限和审计共同约束

### 8.4.3 敏感数据保护

- 密码不应在业务库中明文保存
- 审计记录中应避免泄露不必要的敏感内容
- 文件下载和管理动作应通过受控流程完成

## 8.5 一致性与可靠性需求分析

### 8.5.1 事务一致性需求

以下操作在后续实现中应明确为重点事务场景：

- 用户状态变更与相关日志记录
- 预约创建及参与人写入
- 预约审核与审计日志写入
- 资源审核与积分事件写入

### 8.5.2 并发一致性需求

本课题最典型的并发风险包括：

- 两个用户同时预约同一房间同一时间段
- 同一资源重复提交导致重复审核或重复计分
- 同一资源多次推荐导致统计失真

这些风险要求后续数据库设计提供更明确的一致性保障方案。

## 8.6 可维护性与可扩展性需求

- 平台基础子系统应能够复用到多个业务模块
- 新增业务模块时，应尽量沿用既有用户、组织、权限和审计模型
- 需求分析、数据库设计和实现应形成可追溯链路
- 关键业务规则应优先沉淀到数据库层或统一服务层，而非零散分布

## 8.7 可测试性需求

本课题除了正常流程测试外，还应强调数据库课程设计特有的验证内容：

- 非法数据插入是否会被数据库约束拒绝
- 外键是否能阻止非法引用
- 唯一约束是否能阻止重复记录
- 状态和辅助字段不一致时是否能被拒绝

如果后续答辩中能够展示部分“约束失败样例”，将更能体现数据库在系统中的主动作用。

## 8.8 非功能需求结论

本课题的非功能需求重点不是“界面是否华丽”，也不是“框架是否先进”，而是：

- 数据是否正确
- 规则是否清晰
- 权限是否明确
- 审计是否可追溯
- 查询是否有支撑
- 文档是否规范

这也决定了后续数据库设计阶段必须优先考虑完整性约束、事务控制、索引设计、审计机制和需求可追溯性。