38 KiB
健康CQ升级项目 - 产品需求文档(PRD)
所属端:健康CQ升级项目共性需求说明 模块路径:
platform-prototype/最后更新:2026-04-17
一、文档概述
本文档为“健康CQ升级项目”的产品需求规格说明书(以下简称PRD),旨在系统性地定义本次升级的业务目标、功能范围、用户角色及非功能性需求,为项目团队(包括产品、设计、研发、测试等角色)提供统一的需求基线。该文档适用于“健康CQ升级项目”的全生命周期,涵盖需求分析、系统设计、原型设计、测试验证、交付验收各阶段。
文档目的
-
明确本次升级的核心目标与建设范围,确保各方对项目方向达成一致理解;
-
详细描述各功能模块的业务逻辑、交互流程及数据要求,作为设计与开发的直接依据;
-
规范验收标准与质量指标,为后续测试与上线交付提供参考。
读者对象
-
项目管理人员:用于把控项目范围、进度与风险;
-
产品与设计人员:作为功能设计与交互设计的输入依据;
-
研发人员:用于理解业务逻辑,进行技术方案设计与编码实现;
-
测试人员:用于编写测试用例,验证系统功能与非功能性指标;
-
客户方相关人员:用于确认需求内容,参与评审与验收。
文档内容
-
项目背景与目标:阐述“健康CQ升级项目”的建设背景、升级动因及总体目标,明确本次项目的价值定位;
-
项目需求分析:拆解面向平台管理员、能源员工、健康咨询专家、应急就医服务人员等用户群体用户画像分析,概述本次项目的具体交付成果,对核心业务板块做简要说明;
-
共性需求说明:针对交付产物(PC端或移动端)通用能力进行统一说明,包括用户权限管理、通用样式布局、操作一致性、数据字典等跨模块的公共需求;
-
功能需求详细设计:围绕系统管理、健康咨询、应急就医、健康体检、档案管理、健康监测、一线医疗点、健康干预、体重管理等模块,逐一描述业务场景、功能流程、界面要求及业务规则;
-
非功能性需求:明确系统在性能、安全、可用性、兼容性、可扩展性等方面的质量要求与量化指标;
-
技术实现方案:阐述系统整体技术架构、技术选型、数据库设计、第三方系统对接(如智能手表)、系统安全与可用性、系统部署与运维等方案。
二、项目背景与目标
(一)项目背景
原健康CQ项目是CQ能源公司内部使用的综合性员工健康管理服务平台,旨在整合健康咨询、应急就医、健康体检、档案管理、健康监测、系统管理、健康干预、健康评估、一线医疗点及体重管理等多元功能,为能源员工提供全周期的健康保障。
随着系统业务数据量的不断攀升、企业健康管理要求的不断提升及人工智能技术的快速发展,现有系统在功能完整性、交互体验、数据处理效率及智能服务能力等方面已无法完全满足日益增长的业务需求。为此,启动本次“健康CQ升级项目”,通过对原有系统的全面升级,进一步提升平台的业务支撑能力与用户使用体验。
(二)项目目标
本项目立足于能源员工健康管理的实际业务场景,围绕“性能提升、功能升级与优化、智能化改造”三大方向展开,具体目标如下:
-
性能提升:优化系统架构与数据处理能力,提升系统在高并发场景下的响应速度与稳定性,保障健康监测数据、体检数据等关键信息的高效流转与存储。
-
功能优化:重构平台功能规划、针对现有功能模块进行梳理与重构,优化用户操作流程,提升业务闭环的完整性与易用性,覆盖平台管理员、能源员工、健康咨询专家、应急就医服务人员等核心用户角色的使用场景。
-
智能化改造:引入智能化技术与数据分析能力,强化健康预警、风险识别、个性化干预等应用场景,提升平台在主动健康管理方面的服务能力,实现从“被动响应”向“主动守护”的升级。
(三)交付标准
为确保项目成果符合预期,本次升级项目将依据以下标准进行验收与交付。所有交付内容需经客户方及我方项目主观部门双重确认。
性能与稳定性标准
-
并发处理能力:系统需支持高峰时段(如全员体检季、健康数据同步、全员体重管理高峰期)不低于 3000用户同时在线,核心业务接口响应时间控制在 3秒以内。
-
数据同步时效:健康监测(手表)数据从设备端到平台端的同步延迟不超过 5分钟,确保健康监测的实时性。
-
系统可用性:系统在试运行期间可用性达到 99.6% 以上,无重大级生产事故。
功能完整性标准
-
模块全覆盖:完成对健康咨询、应急就医、健康体检、档案管理、健康监测、系统管理、一线医疗点、健康干预、体重管理九大核心模块的升级改造,所有功能均需通过预设的测试用例。
-
业务流程闭环:关键业务流程(如应急就医从发起、调度到反馈的全过程;健康干预从风险评估到方案执行的全链路;员工档案从建立到速查)需实现端到端的业务闭环,无逻辑断点。
-
权限准确率:平台管理员、能源员工、健康咨询专家、应急就医服务人员四类角色的数据隔离与操作权限准确率达到100%。
智能化改造标准
-
主动预警能力:基于健康监测与体检数据通过数据中台和AI赋能,实现对异常指标(如心率、血压、血糖等)的自动识别与预警推送,预警准确率不低于 80%。
-
数据辅助决策:支持生成多维度的健康数据分析报告(如团队健康画像、高风险人群分布),为健康干预策略的制定提供数据支撑。
文档与技术资产交付
-
开发文档:提供完整的《系统详细设计说明书》《软件产品需求文档》《接口文档》(包含与智能手表、智能体重秤、环境监测IOT设备等第三方系统的对接规范)。
-
部署运维文档:提供《部署手册》《服务器环境清单》《系统监控与运维手册》及《常见问题处理指南》,确保系统具备可持续运维能力。
-
测试报告:提供功能测试报告、性能测试报告及安全测试报告,明确各项测试结论。
三、项目需求分析
(一)用户画像分析
| 用户角色 | 角色定义 | 核心使用场景 | 核心诉求 | 当前痛点 |
|---|---|---|---|---|
| 能源员工 | CQ能源一线员工及管理人员,平台的最终受益者 | 查看健康档案、监测数据、发起健康咨询、申请应急就医、参与健康干预活动、记录体重管理 | 操作便捷、信息及时、响应迅速、隐私安全 | 原系统操作流程较为烦琐;健康数据呈现不够直观;应急就医入口不够显眼;缺乏主动健康提醒 |
| 平台管理员 | 能源健康管理部门的后台运营人员 | 用户管理、权限配置、数据统计、系统监控、体检安排、健康干预活动发布 | 管理效率高、数据可视化、权限控制灵活 | 后台数据统计维度单一;批量操作能力弱;干预活动发布流程复杂;缺乏数据导出与报表功能 |
| 健康咨询专家 | 提供健康咨询服务的专业医师/健康管理师 | 接收员工咨询、回复问题、查看咨询历史、辅助健康评估 | 咨询界面清晰、历史记录可追溯、辅助工具完善 | 咨询消息通知不及时;无法快速查看咨询用户的健康档案;缺乏常用回复模板 |
| 应急就医服务人员 | 负责应急就医调度与协调的后台人员 | 接收应急就医申请、核实信息、协调资源、跟踪处理进度、反馈结果 | 响应高效、信息完整、流程闭环、异常可预警 | 应急流程缺乏自动化提醒;处理进度跟踪困难;与一线医疗点信息联动不足 |
| 医疗点工作人员 | CQ能源各一线医疗点的医护人员,负责为能源员工提供现场医疗服务 | 根据员工的健康状况、记录员工现场就诊信息、周期性就行慢病随访、体检报告解读等 | 信息同步及时、操作简便、与上级机构协同顺畅 | 平台响应效率慢;就诊记录与平台数据同步困难,重复录入工作量大 |
(二)项目交付成果分析
| 交付成果 | 终端定位 | 使用人群 | 核心功能要点 |
|---|---|---|---|
| 健康CQ平台(Web管理端) | 平台统一管理后台,支撑全系统配置与数据管理 | 平台管理员、健康管理部门人员 | 用户权限管理、组织架构维护、数据统计报表、体检安排、健康干预活动发布、应急就医调度监控、系统配置与日志审计 |
| 员工端Android版APP | 能源员工日常健康管理移动端入口(安卓设备) | 能源员工 | 健康档案查看、健康监测数据(手表)展示、发起健康咨询、申请应急就医、参与健康干预、体重管理、消息通知接收 |
| 员工端iOS版APP | 能源员工日常健康管理移动端入口(苹果设备) | 能源员工 | 功能与Android版一致,覆盖健康档案、健康监测、健康咨询、应急就医、健康干预、体重管理等核心模块 |
| 健康应急Android版APP | 应急场景专用移动端,服务于咨询专家、应急人群及咨询助手(安卓设备) | 健康咨询专家、应急就医服务人员、咨询小助手 | 咨询专家:接收咨询、回复问题、查看用户健康档案、快捷回复模板;应急人群:应急申请进度跟踪、资源调度查看;咨询小助手:辅助答疑、常见问题推送、数据统计 |
| 健康应急iOS版APP | 应急场景专用移动端,服务于咨询专家、应急人群及咨询助手(苹果设备) | 健康咨询专家、应急就医服务人员、咨询小助手 | 咨询专家:接收咨询、回复问题、查看用户健康档案、快捷回复模板;应急人群:应急申请进度跟踪、资源调度查看;咨询小助手:辅助答疑、常见问题推送、数据统计 |
| 应急大屏 | 应急指挥可视化看板,用于实时监控应急事件与资源调度 | 应急就医服务人员、平台管理员、应急指挥人员 | 应急事件实时地图展示、应急资源分布(医疗点、车辆)、事件处理进度追踪、异常事件预警、数据大屏可视化 |
| 医疗点pad端 | 一线医疗点专用移动终端,用于现场医疗服务与应急协同 | 一线医疗点工作人员 | 应急就医通知接收、现场就诊记录录入、医疗点资源(药品、设备)状态更新、与应急调度中心协同、员工健康档案快速查询 |
| 微信小程序 | 轻量化服务入口,满足员工便捷访问需求 | 能源员工 | 膳食营养监控、健康档案快速查看、健康监测数据摘要、消息通知、体重管理 |
| 服务监控平台 | 系统运行状态监控与运维管理后台,保障平台稳定运行 | 系统运维人员、技术支撑人员 | 服务健康状态监控、接口调用链路追踪、异常告警与通知、日志聚合分析、性能指标监控、资源使用情况监控、告警规则配置、运维报表统计 |
| 体检医生工作台 | 能源员工体检医院医生端工作台 | 医院体检医生 | 用于能源员工体检时医院医生进行信息核查和数据录入 |
(三)核心业务分析
| 核心业务 | 业务概述 | 现状问题 | 升级方向 |
|---|---|---|---|
| 系统管理 | 用户管理、角色权限、组织架构、系统配置、数据字典,保障平台安全稳定运行 | 权限颗粒度粗、日志不完善、无历史版本留存与操作记录、配置分散 | RBAC精细化权限、完整操作、统一配置管理、结合数据中台构建数据档案 |
| 健康评估 | 基于交大健康干预算法模型、中新惠尔风险与心理评估模型生成健康风险评估报告,识别风险等级 | 评估模型单一、报告样式单一、结果准确度不高、缺少系统自动评估机制和风险预警机制 | 借助AI平台优化评估模型、可视化报告、实现评估结果自动预警和主动风险预测 |
| 应急就医 | 应急申请、资源调度、进度跟踪、结果反馈的全流程管理。 | 应急业务并未形成完整闭环,应急过程以人为干预为主缺少智能的应急指导 | 完善业务流程闭环、就近资源自动匹配、超时升级提醒 |
| 专家咨询 | 员工在线健康咨询,连接专家,支持图文咨询与视频咨询 | 消息回复时效差、无有效的消息提醒机制,平台咨询助手强依赖于人工介入,智能化程度低 | 实时推送消息提醒、增加智能咨询助手 |
| 健康体检 | 体检预约、报告管理、历年数据对比,支撑健康管理基础数据 | 预约流程烦琐、部分报告上传依赖人工处理、数据量庞大导致业务性能表现差 | 优化体检预约流程、打通数据自动上传通道、历年趋势可视化、数据自动同步档案 |
| 健康监测 | 智能手表采集心率、血压、血氧、睡眠等数据,实现动态跟踪 | 同步延迟高、仅展示无分析、缺异常告警 | 优化同步延迟、趋势图可视化、借助AI实现异常自动识别告警、扩展设备兼容性 |
| 一线医疗 | 管理一线员工健康档案、开展慢病管理、随访管理、健康宣教、日常诊疗等医疗服务 | 数据权限管理混乱、信息更新滞后、部分业务性能表现差、大部分业务依赖人工介入智能化程度低 | 信息实时维护更新、优化数据权限以及业务响应速度、通过大数据+AI赋能提高诊疗业务中的智能化程度 |
| 营养管理 | 员工日常用餐记录、膳食指导、营养分析、饮食建议、风险预测助力健康生活方式 | 系统故障频发、功能单一、数据实时性差、与健康数据关联弱 | 提升系统功能卡永兴、完善个性化膳食建议、营养数据分析业务、打通与健康数据联动的壁垒 |
| 体重管理 | 体重记录、目标设定、进度追踪、激励反馈,科学管理体重 | 仅支持记录、缺目标激励、智能化引导和建议较弱 | 目标设定与进度追踪、趋势图表、因人而异提供更科学的减重建议和指导意见 |
| 知识普及 | 健康资讯、科普文章、视频课程,提升健康素养 | 更新慢、缺分类搜索、形式单一、阅读数据未利用 | 多形式内容、分类搜索推荐、点赞评论互动、阅读行为记录、优化智能推荐体系 |
| 运动管理 | 运动数据记录、目标设定、运动计划推荐,促进规律运动 | 数据来源单一、缺目标计划、与健康模块联动弱 | 手动录入补充、目标设定与进度、个性化运动推荐、联动体重营养 |
| 心脑血管病预防 | 高风险人群识别、预警推送、干预方案、科普教育专项管理 | 评估准确性较差、评估与干预脱节、缺少高风险预警措施 | 自动识别高风险人群、风险预警推送、专项干预方案、科普专区 |
| 糖尿病预防 | 血糖监测、风险预警、饮食运动指导,服务高风险及前期人群 | 评估准确性较差、血糖监控难落实、建议缺乏针对性、管理分散 | 血糖记录与趋势分析、自动识别高风险、个性化饮食运动建议、专项干预计划 |
| 癌症预防 | 常见癌症科普、早期筛查提醒、风险评估与预防建议 | 内容覆盖不全、缺评估工具、筛查提醒缺失 | 科普知识库、风险评估问卷、筛查提醒推送、筛查结果入档 |
| 健康数据 | 汇聚系统中所有健康数据,提供可视化分析、报表导出、统计能力 | 数据分散、统计维度单一、导出功能弱 | 统一数据中心、多维度可视化分析、灵活报表导出 |
| 健康档案 | 统一归集体检、监测、咨询、干预等数据,形成个人健康时间轴 | 个别业务未留存历史数据、数据分散未统一视图、数据资产管理方式混乱、数据统计与导出不完善 | 补全历史数据留存环节、实现多源数据整合统一视图、提供灵活的数据统计与导出方案 |
| 待办通知 | 待处理事项、系统消息、预警推送、活动提醒,保障流程推进 | 通知方式单一、缺强提醒、待办分散 | 统一待办中心、多渠道推送(App/短信/微信)、消息分类状态管理、超时升级提醒 |
四、共性需求说明
本章节对平台各端(PC端、移动端)的通用交互规范、数据展示规则、权限控制及跨端一致性要求进行统一定义,所有功能模块的设计与开发须遵循本章节规范,不得与之冲突。
(一)PC端共性需求
1.布局与框架
-
整体采用顶部导航&左侧导航栏 + 右侧内容区的经典后台布局,内容区支持自适应拉伸
-
无权限的菜单项、按钮直接隐藏
-
导入功能使用统一弹窗布局,支持模板下载、拖拽上传、文件预览
-
列表分页默认每页 10 条,支持切换每页条数(10 / 20 / 50/100)
-
列表表格支持列宽拖动、根据每列内容合理规划列宽(如手机号、身份证号、性别、年龄、工号等长度固定的字段)、列显隐配置,配置状态本地持久化
-
超长文本单行截断显示"...",鼠标悬浮展示完整内容(Tooltip)
-
无数据、加载中、接口异常、空白页使用统一样式组件
-
详情页与编辑页排版结构与新增页保持一致
2.表单设计规范
-
必填字段在标签前标注红色星号(*),选填字段不做标注
-
字段标签统一左对齐,同一表单内标签宽度保持一致
-
校验时机:输入框失焦时触发单字段校验,提交时触发全量校验
-
只读态字段使用纯文本展示,不使用禁用输入框
-
下拉选项超过 10 条时,支持关键词搜索过滤
-
日期/时间选择统一使用系统日期组件,不允许纯手动输入
-
表单提交后按钮进入 loading 状态,防止重复提交
-
表单离开未保存时,弹出"是否放弃修改?"二次确认弹窗
-
常规校验:如电话、邮箱、身份证号必须加正则校验,姓名(格式+长度)校验,数值类型(如身高、体重、距离、金额等)根据常规知识灵活加校验(如体重不能为负数,身高不能大于300CM等)
-
字段字数限制规范:所有表单输入字段须按下表设置最大字数限制,前端通过
maxlength属性控制,后端同步校验
| 字段类型 | 最大字数 | 说明 |
|---|---|---|
| 姓名/人名 | 20 | 中文姓名+少数民族长名 |
| 手机号 | 11 | 固定位数,正则校验 |
| 座机号 | 12 | 正则校验,正则校验 |
| 身份证号 | 18 | 固定位数,正则校验 |
| 标题/名称 | 50 | 如任务标题、模块名称 |
| 短文本输入 | 100 | 如地址、单位名称、一句话备注 |
| 多行备注/描述 | 500 | 如简介、问题说明 |
| 搜索框 | 50 | 关键词搜索 |
| 验证码 | 6 | 短信/邮箱验证码 |
| 密码 | 12~30 | 必须包含至少一个小写字母; 必须包含至少一个大写字母; 必须包含至少一个数字; 必须包含至少一个特殊符号(可以根据需要修改特殊符号的定义); 密码长度必须大于等于12 |
| 邮箱 | 50 | 常规邮箱地址 ,正则校验 |
| URL链接 | 200 | 网址输入 |
- 多行文本框右下角实时显示字数计数提示,格式为"已输入 X / Y 字"
- 达到字数上限后禁止继续输入
- 提交校验时,必填字段为空提示"请输入XXX",超限提示"XXX不能超过N个字"
3.搜索与筛选规范
-
搜索框支持回车键触发搜索,与点击搜索按钮效果一致
-
多条件筛选区域默认展开,条件较多时可折叠收起
-
已选筛选条件以标签形式展示在筛选区下方,支持单独点击删除
-
筛选条件变更后需手动点击"查询"按钮触发,不自动触发(避免频繁请求)
-
提供"重置"按钮,一键清空所有筛选条件并恢复默认列表
-
列表页搜索/筛选状态不跨页面保留,刷新后恢复默认
4.交互与操作
-
删除、清空、重置、批量操作前必须弹出二次确认弹窗,明确说明操作影响
-
批量操作按钮在未选中数据时置灰禁用,选中后激活并显示已选数量
-
所有按钮做防连点控制,同一接口短时间内不可重复触发
-
接口请求期间按钮进入 loading 状态,内容区显示骨架屏或 loading 遮罩
-
导出规范:小数据量(≤1000条)即时导出;大数据量(>1000条)异步导出,生成任务后提示"请在导出任务中查看";按钮文案统一为"导出列表数据",导出成功后 Toast 提示
-
所有字段校验采用前端校验 + 后端校验双重保障
5.数据展示
-
时间展示统一格式:YYYY-MM-DD HH:mm:ss;日期类型统一格式:YYYY-MM-DD
-
金额类型保留两位小数;百分比保留一位小数
-
浮点型数据无特别说明时默认保留两位小数
-
手机号、固定电话、身份证号使用统一正则验证规则
-
表格中数字列右对齐,文本列左对齐
-
空值/无数据字段统一展示为"—",不展示空字符串或 null
6.文件处理规范
-
上传入口处明确标注支持的文件类型与大小上限
-
图片文件支持在线预览;PDF、Word、Excel 支持在线预览(不强制下载)
-
大文件上传(>5MB)显示上传进度条,支持取消上传
-
下载文件统一通过浏览器下载,文件命名格式:模块名_数据名_时间戳
-
批量下载超过 10 个文件时,自动打包为 ZIP 后下载
7.反馈与提示
-
操作成功/失败:使用顶部居中 Toast 提示,3 秒后自动消失;提示词保持格式统一,如:‘删除成功’、‘删除成功’、‘保存成功’、‘保存失败’...
-
关键操作(删除、提交、发布):使用 Confirm 确认框,需用户主动确认
-
接口报错:统一提示"系统繁忙,请稍后重试",详细错误信息仅输出至控制台
-
网络断开:全局顶部展示"网络连接已断开"横幅提示,恢复后自动消失
-
操作日志:新增、修改、删除、导出等关键操作自动记录操作日志,支持审计追溯
8.权限控制
-
应用权限:根据登录用户角色动态显示主页应用模块,无权限模块不可见
-
菜单权限:根据用户角色动态渲染菜单,无权限菜单项直接隐藏
-
按钮权限:页面内操作按钮根据权限控制显示/隐藏或启用/禁用
-
数据权限:所有业务数据默认按组织架构层级与登录用户管理范围进行隔离,禁止数据越权访问(如涉及到员工信息的业务数据、单位活动、监测设备信息等),需要特殊处理或不做数据权限控制的板块会在对应板块的PRD文档中备注说明
-
接口权限:核心业务接口必须加权限校验,普通员工 Token 无法访问后台统计接口,管理员 Token 无法访问 APP 专用接口
(二)移动端共性需求
1.布局与导航
-
整体采用单列布局,内容区上下滑动
-
员工端 APP、健康应急 APP 使用底部 Tab 栏导航,Tab 不超过 5 个,当前选中项高亮
-
顶部导航栏显示页面标题,左侧返回按钮(一级页面无返回),右侧可放置更多操作入口
-
适配主流手机分辨率(iOS:iPhone 12 及以上;Android:主流全面屏),支持安全区域适配
-
支持左滑返回上一页;列表支持下拉刷新、上拉加载更多
2.表单设计规范
-
表单采用单列纵向排列,标签置于输入框上方
-
必填字段标注红色星号(*)
-
输入框获取焦点时键盘自动弹起,内容区自动上移,避免键盘遮挡输入框
-
点击空白区域收起键盘
-
选择类控件使用底部弹出 Picker 或 ActionSheet,不使用 PC 式下拉框
-
长表单建议分步骤展示,每步不超过 5 个字段,顶部显示步骤进度条
-
表单提交后按钮进入 loading 状态,防止重复提交
-
字段字数限制规范:与PC端保持一致,所有表单输入字段须按以下规范设置最大字数限制
| 字段类型 | 最大字数 | 说明 |
|---|---|---|
| 姓名/人名 | 20 | 中文姓名+少数民族长名 |
| 手机号 | 11 | 固定位数,正则校验 |
| 座机号 | 12 | 正则校验,正则校验 |
| 身份证号 | 18 | 固定位数,正则校验 |
| 标题/名称 | 50 | 如任务标题、模块名称 |
| 短文本输入 | 100 | 如地址、单位名称、一句话备注 |
| 多行备注/描述 | 500 | 如简介、问题说明 |
| 搜索框 | 50 | 关键词搜索 |
| 验证码 | 6 | 短信/邮箱验证码 |
| 密码 | 12~30 | 必须包含至少一个小写字母; 必须包含至少一个大写字母; 必须包含至少一个数字; 必须包含至少一个特殊符号(可以根据需要修改特殊符号的定义); 密码长度必须大于等于12 |
| 邮箱 | 50 | 常规邮箱地址 ,正则校验 |
| URL链接 | 200 | 网址输入 |
- 多行文本框右下角实时显示字数计数提示,格式为"已输入 X / Y 字"
- 达到字数上限后禁止继续输入
3.交互与操作
-
可点击区域不小于 44×44pt,确保手指触控友好
-
主按钮使用圆角大按钮,宽度占满或居中,置于页面底部悬浮或跟随内容流
-
删除、清空等危险操作使用底部弹出 ActionSheet 或居中模态框,需二次确认
-
键盘弹起时底部悬浮按钮自动上移,避免被键盘遮挡
-
列表支持下拉刷新,刷新时顶部显示 loading 动画
4.数据展示
-
图表采用移动端适配的简化版本,支持手势缩放查看详情
-
无数据时显示统一占位图 + 提示文案,提供引导操作
-
空值统一展示为"—"
5.图片与文件处理
-
图片上传支持拍照和相册选取两种方式,入口明确区分
-
上传前自动压缩,单张图片大小不超过 2MB
-
图片预览支持双指缩放、左右滑动切换多张图片
-
文件下载显示进度,完成后提示"下载完成,点击打开"
-
上传失败时提示具体原因(如"文件格式不支持"、"文件超出大小限制")
6.反馈与提示
-
操作反馈使用 Toast 轻提示,1.5~2 秒自动消失,不阻断操作
-
异步请求使用全屏或局部 Loading,避免用户重复点击
-
待办事项、未读消息在入口处显示红点或数字角标
-
关键操作(如问卷提交)成功后,给予明确的成功状态页,而非仅 Toast
7.网络异常处理
-
请求超时时间统一设置为 10 秒,超时后提示"服务器繁忙,请稍后在再试"并提供重试按钮
-
网络断开时,页面顶部展示"当前无网络连接"横幅,恢复后自动消失并刷新数据
-
弱网环境下优先展示缓存数据,并标注"网络不佳数据可能存在延迟"
-
关键操作(如应急就医发起)在网络恢复后自动重试,并通知用户操作结果
-
首屏关键数据优先加载,非关键内容懒加载;图片使用缩略图 + 懒加载策略
(三)跨端通用规范
1.品牌与视觉一致性
-
PC 端与移动端采用统一的品牌色、字体、圆角、阴影等视觉语言
-
全平台功能命名、按钮文案、提示文案保持一致(如"应急就医"不出现"紧急就医"等变体)
-
时间显示格式统一:近 24 小时内显示"X 小时前",超过 24 小时显示具体日期
-
错误提示文案统一维护,避免不同模块出现不同表述
-
同一用户在不同端操作,数据实时同步,无延迟感知
2.数据安全与隐私保护
-
所有数据传输使用 HTTPS 加密,禁止明文传输敏感信息
-
敏感字段(手机号、身份证号、健康指标数据)在列表中默认脱敏,详情页按权限展示完整信息
-
会话超时时间设置为 30 分钟无操作后自动登出,跳转登录页并提示"登录已过期,请重新登录"
-
移动端禁止对健康敏感数据页面进行截图分享(系统级限制,如条件不允许则在界面层提示禁止截图)
-
用户登出后本地缓存的敏感数据立即清除
3.字典与枚举规范
-
所有状态值、类型值统一在后台数据字典中维护,前端不硬编码枚举含义
-
前后端枚举值保持严格一致,接口文档中明确枚举定义
-
字典数据由后端统一下发,前端缓存使用;字典变更时主动通知前端刷新缓存
-
列表筛选、表单选项中的枚举值均从字典接口动态获取
4.无障碍规范
-
正文字体最小不低于 12px(PC),移动端正文不低于 14px
-
文字与背景色对比度不低于 4.5:1(WCAG AA 标准)
-
所有图标按钮需配备文字说明或 aria-label 属性
-
表单字段需关联 label 标签,支持屏幕阅读器识别
-
关键操作结果(成功/失败)需通过文字或图标明确告知,不能仅依赖颜色区分
五、功能需求详细设计
(一)系统管理
健康CQ升级项目产品需求文档-系统管理.docx
(二)健康评估
健康CQ升级项目产品需求文档-健康评估.docx
(三)应急就医
(四)专家咨询
六、非功能性需求
(一)性能要求
业务指标
| 指标 | 定义 | 简称 | 本系统标准 |
|---|---|---|---|
| 请求响应时间 | 指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束,整个过程所耗费的时间。 | Response Time: RT | 平均响应在1s以下; 统计查询接口3s以下 |
| 系统处理能力 | 指系统在利用系统硬件平台和软件平台进行信息处理的能力。 系统处理能力通过系统每秒钟能够处理的交易数量来评价。 |
HPS(每秒点击次数) TPS(系统每秒处理交易数) QPS(系统每秒处理查询次数) |
HPS:10000次/秒 TPS:3000笔/秒 QPS:5000次/秒 |
| 并发用户数 | 指在同一时刻内,登录系统并进行业务操作的用户数量。在测试中,采用虚拟用户来模拟现实中用户进行业务操作。 | Virtual User: VU | 正常负载下支持用户并发数3000+ |
| 错误率 | 指系统在负载情况下,失败交易的概率。 | Failure Ratio: FR | 错误率低于千分之六,即成功率高于99.6% |
服务器资源指标
| 指标 | 定义 | 简称 | 本系统标准 |
|---|---|---|---|
| CPU | 中央处理器是一块超大规模的集成电路,是一台计算机的运算核心(Core)和控制核心( Control Unit)。它的功能主要是解释计算机指令以及处理计算机软件中的数据。 | Central Processing Unit:CPU | CPU sys%小于30% CPU wait%小于5%。 CPU Load小于CPU 核数。 |
| 内存 | 内存是计算机中重要的部件之一,它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的,因此内存的性能对计算机的影响非常大。 | Memory就是内存的简称 | 本系统据其优秀的系统架构设计,合理的运用内存,在一般情况下不会利用到SWAP空间,自身的内存完全能够支撑项目的运行 |
| 磁盘吞吐量 | 指在无磁盘故障的情况下单位时间内通过磁盘的数据量。 | Disk Throughput | 在分布式架构下,一般磁盘繁忙率要低于70% |
| 网络吞吐量 | 指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。用于衡量系统对于网络设备或链路传输能力的需求。 | Network Throughput | 网络吞吐量指标主要有每秒有多少兆流量进出,一般情况下不能超过设备或链路最大传输能力的70% |
前端应用指标
| 指标 | 二级指标 | 解释 | 本系统指标 |
|---|---|---|---|
| 页面展示 | 首次显示时间 | 在浏览器地址栏输入URL按回车到用户看到网页的第一个视觉标志为止 | 秒级别响应 |
| OnLoad事件时间 | 浏览器触发onLoad事件的时间,当原始文档和所有引用的内容完全下载后才会触发这个事件 | 秒级别响应 | |
| 完全载入的时间 | 所有onLoad JavaScript 处理程序执行完毕,所有动态的或延迟加载的内容都通过这些处理程序触发的时间 | 秒级别响应 | |
| 页面数量 | 页面大小 | 整个页面大小 | 所有页面Body大小为KB级别 |
| 请求数量 | 从网站下载资源时所有网络请求的总数,尽量少 | ||
| 网络所花时间 | DNS时间 | DNS查找时间 | 秒级别响应 |
| 连接时间 | 浏览器与Web服务器建立TCP/IP连接的时间 | 秒级别响应 | |
| 服务器时间 | 服务器处理时间 | 秒级别响应 | |
| 传输时间 | 内容传输所用时间 | 秒级别响应 | |
| 等待时间 | 等待某个资源释放的时间 | 秒级处理 |
稳定性、可靠性指标
| 指标 | 解释 | 本系统标准 |
|---|---|---|
| 稳定性指标 | 系统按照最大容量的80%或标准压力(系统的预期日常压力)情况下运行,能够稳定运行的最短时间 | 本系统能提供7*24运行的系统稳定运行能力。 |
| 集群 | 集群中某个节点出现故障时,系统是否有业务中断情况出现 在集群中新增一个节点时,是否需要重启系统 当故障节点恢复后,加入集群,是否需要重启系统 当故障节点恢复后,加入集群,系统是否有业务中断情况出现 节点切换需要多长时间 |
当系统出现故障时,故障节点会自动从集群中剔除,业务无需中断,当节点恢复时自动加入集群,实现无感知切换,纳秒级切换。 |
| 备份和恢复 | 备份是否成功及其消耗时间 备份是否使用脚本自动化完成 恢复是否成功及其消耗时间 恢复是否使用脚本自动化完成 |
备份策略采用全量和增量的方式进行,以小时为单位,周期性循环备份,并以天或周为单位周期性循环实现全量备份,为数据提供基础底层保障。 |
(二)兼容性要求
| 应用名称 | 系统性质 | 操作系统/浏览器内核兼容性要求 | 操作系统版本/browser版本要求 | 终端适配要求 | 备注 |
|---|---|---|---|---|---|
| 客户端APP | 移动APP | 1. 需同时兼容 Android、iOS、HarmonyOS 三类主流手机操作系统。 2. 需进行充分兼容性测试并输出测试报告。 |
Android 系统:需兼容 Android 10.0 及以上版本,推荐 Android 12 及以上。 | 1. 机型适配:需兼容市面主流屏幕类型(全面屏、打孔屏、折叠屏等)。 2. 屏幕分辨率:1080×2400 及以上,支持安全区域适配。 3. 运行内存:4GB 及以上。 |
1. 测试需覆盖所有功能点。 2. 品牌、系统、分辨率兼容性测试可使用第三方测评平台,需出具测试报告。 |
| iOS 系统:需兼容 iOS 16 及以上版本,推荐 iOS 17 及以上。 | 1. 适配 iPhone 12 及以上机型。 2. 屏幕分辨率:1170×2532 及以上。 3. 支持 Face ID 安全区域适配。 |
||||
| HarmonyOS 系统:需兼容 HarmonyOS 4.0 及以上版本,推荐 HarmonyOS 6.0。 | 1. 适配华为、荣耀品牌近 3 年内主流机型。 2. 屏幕分辨率:1080×2340 及以上。 3. 运行内存:4GB 及以上。 |
||||
| 客户端WEB | B/S应用 | 1. 主要适配内核:Blink(Chromium)、Gecko、WebKit。 2. 不再支持 IE 浏览器(Trident 内核已废弃)。 3. 需适配 PC 端主流浏览器。 |
Chromium 内核:Chrome 100+;Edge 100+;360极速浏览器(Chromium内核)13+;QQ浏览器 14+;搜狗浏览器 12+;Opera 85+。 | 1. 显示器分辨率:最低 1366×768,推荐 1920×1080 及以上,支持 2K(2560×1440)。 2. 显示器尺寸:13in–34in。 |
1. 推荐使用 Chrome 浏览器以获得最佳体验。 2. 不再支持 IE 浏览器,访问时提示升级。 3. 兼容性测试以浏览器版本为主,需同时注明内核版本。 4. 终端适配以分辨率为准,显示器尺寸为参考值。 |
| Gecko 内核:Firefox 100+。 WebKit 内核:Safari 16+(仅适用于 macOS 用户)。 企业微信内置浏览器(Chromium 内核):需兼容企业微信 PC 端及移动端内置浏览器,版本跟随企业微信最新版本。 |