需求分析

基于SpringBoot框架的中医药经典方例分享平台

一、项目背景
随着大家对健康的关注度越来越高，中医药作为传统文化的瑰宝，逐渐受到更多人的喜爱。但现在中医药经典文献散落在古籍、教材、网络文章中，无论是中医药学生、从业者，还是对中医感兴趣的普通人，都很难高效地找到系统的学习资源。作为大学生团队，我们希望通过开发一个基于 Spring Boot 的线上平台，整合经典文献、案例经验、专家讲解等内容，打造一个集学习、交流、分享于一体的空间，让中医药知识更易获取，助力传统文化的传承与传播。
平台核心功能包括：
•文献检索与学习：收录《黄帝内经》《伤寒论》等经典著作及现代研究资料，支持关键词搜索、分类浏览；
•案例与经验分享：用户可上传临床案例、学习笔记，促进实践经验交流；
•专家互动模块：定期举办线上讲座、答疑直播，邀请行业专家解读经典；
•辅助工具：提供 AI 问诊（基础症状咨询）、药性图解等小工具，降低学习门槛。
二、用户需求概述
1.按不同角色分类详细描述用户群体及其需求：
角色 1：普通用户（中医爱好者 / 学习者）
1.日常工作任务或业务流程需求：传统模式下，普通用户获取方剂信息，主要依靠查阅书籍或网络搜索。但这些信息不仅零散，权威性也难以保障。用户渴望拥有一个平台，能实现便捷的方剂查询、分类浏览、收藏及评论交流功能，以此突破信息获取的困境，提升学习与交流的效率。
2.对系统功能的期望：
(1)方剂查询：支持通过关键词、症状、药材等多种方式搜索，助力用户精准定位所需方剂。
(2)分类浏览：可依据朝代、病症、药材等维度分类查看方剂，便于用户系统了解不同类型方剂。
(3)个人收藏：能收藏常用方剂，方便后续快速查阅。
(4)评论互动：可针对经典方剂展开讨论，分享使用经验，促进用户间的交流学习。

角色 2：中医从业者（医生 / 药师）
1.日常工作任务或业务流程需求：在日常诊疗或配药工作中，中医从业者需要快速获取方剂的组成、适用症状、禁忌等信息。他们期待系统具备权威的方剂数据库、配伍禁忌提醒以及临床案例参考等功能，辅助诊断与配药流程。
2.对系统功能的期望：
(1)方剂详情：能够查看方剂完整组成、煎服方法、禁忌说明等详细内容。
(2)配伍分析：系统自动检测方剂中 “十八反”“十九畏” 等药材冲突，保障用药安全。
(3)案例库：可查看其他医生的临床使用反馈，为自身诊疗提供参考。
(4)导出功能：支持将方剂信息导出为 PDF 或 Word 格式，便于打印存档。

角色 3：管理员（平台运营者）
1.日常工作任务或业务流程需求：管理员负责审核用户提交的方剂、管理用户权限以及维护系统数据。期望系统提供后台管理面板、数据统计、用户管理等功能，确保平台平稳运行及数据准确无误。
2.对系统功能的期望：
(1)内容审核：审核用户提交的方剂，保证数据准确可靠。
(2)用户管理：可封禁违规用户，并进行权限分配，如专家认证等操作。
(3)数据统计：分析热门方剂、用户活跃度等数据，为平台运营提供决策支撑。

角色 4：医学科研人员
1.日常工作任务或业务流程需求：医学科研人员在开展中医方剂相关研究时，需要获取大量方剂的原始数据、研究文献以及实验结果。他们期望系统能提供全面且精准的方剂数据资源，涵盖方剂的历史演变、药理研究进展等，助力科研工作的开展。
2.对系统功能的期望：
(1)深度数据挖掘：能够对海量方剂数据进行深度挖掘，例如分析方剂的潜在活性成分、作用机制等。
(2)文献关联：关联与方剂相关的科研文献，方便科研人员了解研究动态与前沿成果。
(3)数据对比分析：支持对不同方剂进行对比分析，辅助科研人员筛选研究对象与研究方向。

角色 5：教育工作者（中医院校教师等）
1.日常工作任务或业务流程需求：教育工作者在教学过程中，需要丰富的教学素材来讲解方剂知识，提升学生的学习兴趣与理解能力。他们希望平台能够提供多样化的教学资源，用于课堂教学、课后作业布置以及学生自主学习指导。
2.对系统功能的期望：
(1)教学资源整合：整合方剂的多媒体教学资料，如动画演示方剂的煎煮过程、案例视频讲解方剂应用等。
(2)作业与测试功能：支持布置与方剂知识相关的作业、测试，并能自动批改与分析学生的学习情况。
(3)学生学习跟踪：可跟踪学生在平台上的学习轨迹，如浏览方剂记录、参与讨论情况等，以便针对性地进行教学辅导。

2.共性与差异
共性：所有角色都需要系统提供准确、全面的方剂信息。普通用户和中医从业者都有查询方剂的需求，而管理员需要确保方剂信息的质量。
差异：普通用户更注重方剂的查询、收藏和交流功能；中医从业者侧重于方剂的详细信息、配伍分析和临床案例参考；管理员则主要负责平台的管理和数据统计工作。
核心需求点：提供准确、权威的方剂信息，满足不同角色的个性化需求，确保平台的稳定运行和数据安全。核心需求引导项目应注重方剂数据的质量和系统功能的针对性开发。

三、功能性需求
功能模块 1：方剂管理模块
功能 1.1：方剂查询
3.输入内容：用户输入关键词，如方剂名、症状、药材等。
4.操作流程：系统在数据库中进行检索，支持模糊查询，以匹配相关方剂。
5.输出结果：返回方剂列表，包含方剂名称、简介、适用症状等信息。

功能 1.2：方剂详情
1.输入内容：用户点击某一方剂。
2.操作流程：系统加载该方剂的详细信息，包括组成、用法、禁忌、来源等。
3.输出结果：展示完整的方剂信息，并提供 “收藏” 和 “评论” 入口。

与其他功能模块的交互：
与用户模块交互，记录用户的收藏和评论信息。
与分类模块交互，可按分类筛选方剂，方便用户查找特定类型的方剂。

功能模块 2：用户交互模块
功能 2.1：评论与评分
1.输入内容：用户填写评论内容并给出评分。
2.操作流程：系统将评论信息存储到数据库，并更新方剂的评分。
3.输出结果：显示最新的评论内容，并计算方剂的平均评分。

功能 2.2：个人收藏夹
1.输入内容：用户点击 “收藏” 按钮。
2.操作流程：系统记录用户 ID 和方剂 ID 的关联信息。
3.输出结果：用户可以在 “我的收藏” 中查看已收藏的方剂。
4.与其他功能模块的交互：与方剂模块交互，获取方剂的相关数据，以便用户进行收藏和评论操作。

功能模块 3：后台管理模块
功能 3.1：内容审核
1.输入内容：管理员查看待审核的方剂。
2.操作流程：管理员进行审核，决定通过或驳回，并通知提交者。
3.输出结果：更新方剂的状态，如公开或隐藏。

功能 3.2：数据统计
1.输入内容：管理员选择统计维度，如时间、方剂类别等。
2.操作流程：系统根据选择的维度生成访问量、热门方剂等报表。
3.输出结果：以可视化图表（如柱状图、饼图）的形式展示统计结果。
4.与其他功能模块的交互：与数据库交互，拉取所需的统计数据，为管理员提供决策支持
用例图：

系统结构图：

四、非功能性需求
1.日常业务场景：
在日常使用中，系统应保证大部分用户请求的响应时间在 1 - 3 秒内。例如，用户进行方例查询、浏览文章等操作时，能够快速得到结果，这样可以提供流畅的使用体验，使用户不会因等待时间过长而感到不耐烦。
2.高峰时段：
即使在访问量达到高峰时，系统也应确保核心功能的响应时间不超过 5 秒。例如，多个用户同时进行方例分享、评论等操作时，虽然系统处理压力增大，但仍要保证用户能够在较短时间内看到操作结果，避免出现长时间等待或系统卡顿的情况。
3.复杂操作场景：
对于一些复杂的操作，如大数据量的方例批量下载或复杂的全文检索，响应时间可以适当延长，但一般也应控制在 10 - 15 秒内。这样可以让用户知道系统正在处理请求，而不是出现无响应的状态。
4.存储结构设计：
采用高效的数据库存储结构，如关系型数据库结合 NoSQL 数据库，对于结构化的方例数据（如方剂组成、功效主治等）使用关系型数据库存储，以保证数据的一致性和完整性；对于非结构化的用户分享内容（如图片、视频、心得体会等）使用 NoSQL 数据库存储，便于快速存储和灵活扩展。同时，建立合理的索引结构，以提高数据插入和查询的效率。
五、系统架构需求
1.总体架构设计
·架构模式
采用微服务架构。将系统拆分为多个相对独立的微服务，划分原则如下：
专家咨询服务：负责处理用户与中医专家的咨询业务流程，包括专家选择、支付流程（与支付服务协作）、咨询过程管理及报告生成等。
社区交流服务：专注于用户在中医相关社区的交流功能，如帖子发布、审核、显示以及用户反馈处理等。
AI 问诊服务：处理用户通过 AI 进行问诊的业务，包括问题接收、反馈生成以及关联问题推荐等。
经典案例共享服务：主要负责中医经典案例的存储、检索（支持搜索和热门推荐）以及案例反馈等功能。
支付服务：独立处理支付相关业务，包括生成支付订单、选择支付方式、处理支付结果并更新支付状态等。
选择微服务架构的原因：中医经典方例系统功能多样且业务逻辑复杂，微服务架构可使各服务专注自身功能，降低耦合度，便于开发、维护和部署。同时，能针对不同服务的特点进行灵活的资源调配和优化，更好满足业务需求。
2.扩展性需求
·功能扩展
新功能模块方向：未来可能添加中医药材科普模块，用于介绍各类中药材的特性、功效、使用禁忌等知识；还可能增加在线课程服务，邀请中医专家录制课程，供用户学习中医理论和经典方例应用等。
预留扩展接口：在各微服务设计时，采用 RESTful API 规范定义接口。例如，在经典案例共享服务中，预留用于接入新案例数据源的接口，当需要引入更多中医古籍案例时，可通过该接口进行对接，而不影响其他服务。对于新功能模块，可通过定义标准接口实现与现有微服务的集成，如中医药材科普模块可与 AI 问诊服务集成，在问诊过程中提供相关药材知识提示。
·性能扩展
集群部署：针对每个微服务，采用容器化技术（如 Docker）进行集群部署。当用户量增加时，可快速创建多个服务实例，组成服务集群。例如，在业务高峰时期，可增加专家咨询服务的实例数量，分担用户请求压力。
负载均衡：使用负载均衡器（如 Nginx），将用户请求均匀分配到各个微服务实例上。以社区交流服务为例，当大量用户同时发布帖子时，负载均衡器可根据各实例的负载情况，合理分配请求，避免单个实例因过载而影响系统性能，确保系统在用户量和数据量增长时仍能长期稳定运行。




六、数据需求
1.数据实体​
·用户（User）​
主键：user_id（UUID / 自增）​
属性：username、password、email、phone、register_time、last_login、status、role（普通用户 / 管理员 / 医生）、license_number（医生执业编号）、hospital（所属机构）、avatar（头像 URL）、bio（简介）​
·中医药经典（Classic）​
主键：classic_id​
属性：title、author、dynasty、content、create_time、update_time、category_id（外键）​
·分类（Category）​
主键：category_id​
属性：name（分类名称）、description​
·药材（Herb）​
主键：herb_id​
属性：name、property（性味）、efficacy（功效）​
·评论（Comment）​
主键：comment_id​
属性：user_id（外键）、classic_id（外键）、parent_comment_id（自关联外键）、content、create_time、status​
·私聊消息（PrivateMessage）​
主键：message_id​
属性：sender_id（外键）、receiver_id（外键）、content、send_time、is_read​
·病历（MedicalRecord）​
主键：record_id​
属性：patient_id（外键）、doctor_id（外键）、visit_date、symptoms、diagnosis、prescription（JSON）、status、created_time​
·诊断附件（DiagnosisAttachment）​
主键：attachment_id​
属性：record_id（外键）、file_type、file_path​
·医生审核（DoctorAudit）​
主键：audit_id​
属性：user_id（外键）、license_image、status、audit_comment​
关联表（Collection）：联合主键 user_id + classic_id（用户收藏经典的记录）​
关联表（Classic_Herb）：联合主键 classic_id + herb_id（经典与药材的引用关系）​
数据关系（ER 图关系描述）​
用户相关关系​
用户 ↔ 评论（1:N）：一个用户可发表多条评论，评论必须属于一个用户。​
用户 ↔ 私聊消息（发送 / 接收）：sender_id、receiver_id 外键引用用户表，用户作为发送者 / 接收者均为 1:N 关系。​
用户 ↔ 收藏经典（M:N）：通过关联表 Collection 实现，用户可收藏多篇经典，经典可被多个用户收藏。​
用户 ↔ 病历：patient_id、doctor_id 外键关联用户表，患者、医生与病历均为 1:N 关系。​
用户 ↔ 医生审核（1:N）：用户可提交多次资质审核。​
经典相关关系​
经典 ↔ 分类（N:1）：一篇经典仅属于一个分类，一个分类包含多篇经典。​
经典 ↔ 药材（M:N）：通过关联表 Classic_Herb 实现，经典可引用多种药材，药材可被多篇经典引用。​
经典 ↔ 评论（1:N）：一篇经典可有多条评论，评论必须关联一篇经典。​
病历相关关系：病历 ↔ 诊断附件（1:N）：一个病历可关联多个附件。​
其他关系：评论自关联（1:N）：评论可回复其他评论，parent_comment_id 指向同一表的 comment_id。

七、项目实施计划
阶段一：需求调研与分析（第 1-2 周）
目标：明确用户需求，确定核心功能
•调研方式：
◦设计线上问卷（使用问卷星），面向中医药专业学生、社区养生爱好者、基层中医师发放，回收有效问卷 300 + 份；
•分析成果：
◦整理《需求清单》，优先实现 “用户注册登录”“文献浏览与搜索”“案例发布与互动”“直播讲座” 四大核心功能；
◦定义用户角色：游客（浏览公开内容）、注册用户（收藏 / 评论）、认证用户（上传案例 / 申请专家入驻）。
输出：《需求调研报告》（含用户画像、功能优先级表）
阶段二：系统设计（第 3-4 周）
目标：完成技术架构、数据库、界面设计
•技术选型：
◦后端：Spring Boot 3.x，使用 Maven 管理依赖；
◦数据库：MySQL ，设计 ER 图（用户表、文献表、案例表、讲座表等）；
◦前端：Vue 3.0+ 微信小程序
•架构设计：
◦分层架构：表现层、服务层、数据层；
◦安全设计：用户密码加密存储，接口权限控制。
阶段三：开发实现（第 5-12 周）
目标：分模块编码，完成可运行原型
•任务分工：
◦后端组：负责用户模块（注册登录、权限管理）、文献模块（检索、分页、收藏）、案例模块（发布、点赞、评论）；
◦前端组：实现页面交互（文献搜索栏、案例列表），对接后端 API；
◦测试组：同步编写测试用例。
•核心功能开发：
◦文献搜索：基于 MySQL 全文索引实现关键词搜索，支持 “模糊查询 + 分类筛选”；
◦直播模块：集成第三方直播 SDK，实现讲座预告、直播回放功能；
◦移动端适配：优化小程序界面，确保手机端浏览流畅。
•代码管理：使用 Git 进行版本控制，分支策略，定期进行代码评审。
阶段四：测试与优化（第 13-14 周）
目标：发现并修复问题，提升用户体验
•测试内容：
◦功能测试：按《需求清单》逐条验证，覆盖注册、搜索、发布等流程，记录 Bug 并修复；
◦兼容性测试：在 Chrome、Edge 浏览器及安卓 /iOS 手机上测试界面显示与操作；
◦性能测试：使用 JMeter 模拟 200 + 并发用户，优化慢查询 SQL（如添加索引）；
◦用户测试：邀请 同学及老师体验，收集反馈.
阶段五：上线部署与运营
目标：系统上线，持续推广与维护
•部署方案：
◦服务器：租用华为云 ECS 服务器，使用 Nginx 部署前端，Spring Boot 项目打包为 Jar 包运行；
◦运维：定期备份数据库，监控服务器状态（CPU / 内存占用），记录运行日志。
•运营计划：
◦上线准备：发布平台介绍视频（B 站 / 抖音）；
◦推广策略：在中医药院校论坛、微信公众号发文宣传，举办 “经典文献打卡” 活动（用户签到、分享得积分）；
◦持续优化：根据用户反馈迭代版本，计划新增 “知识图谱” 功能（可视化药材关联关系）。
输出：正式上线的平台（Web 端）、运营数据周报（用户数、活跃度）
八、项目风险评估与应对
1.识别项目实施过程中可能面临的各类风险
·技术风险：
新技术应用难度大：Spring Boot 框架虽流行，但如引入新的中医数据分析算法或复杂的加密技术，可能因团队经验不足，导致开发周期延长。
技术选型失误：若选择不适合中医经典方例数据处理量和并发需求的数据库或中间件，可能造成系统性能瓶颈。
技术难题攻克不了：例如在实现精准的中医症状匹配算法或高效的方例检索功能时，可能遇到算法优化、数据结构设计等难题，影响项目进度。
·需求变更风险：
因中医业务的复杂性和多变性，临床应用反馈可能导致功能需求调整。例如，对某些方例的展示方式、搜索逻辑，随着用户深入使用，需求可能发生变化。
对用户需求理解偏差，如对医生、患者、科研人员等不同用户群体的核心需求把握不准，后续需重新调整功能。
·人力资源风险：
关键人员离职：如熟悉中医业务逻辑的开发人员或资深架构师离职，可能造成项目进度延误、技术衔接不畅。
团队协作不畅：开发、测试、产品等团队间沟通不及时、信息传递有误，导致功能实现与预期不符，需反复返工。
人员技能不足：团队成员对中医领域知识、Spring Boot 高级特性、复杂加密算法等掌握不够，影响开发效率和质量。
·外部因素风险：
政策法规变化：中医药相关政策调整，如数据合规性、医疗信息安全规定变化，可能需要对系统进行改造。
市场波动：新的中医类竞品出现，抢占市场份额，导致用户增长放缓。
第三方合作伙伴问题：如数据供应商提供的数据格式不符、质量不佳，或云服务提供商出现故障，影响系统正常运行。
·用户身份验证风险：
多因素认证实施难度大：引入短信验证码、谷歌身份验证器等多因素认证，可能面临短信发送平台不稳定、谷歌身份验证器集成复杂等问题。
生物识别认证适配问题：在支持指纹识别、面部识别时，可能因不同设备的硬件差异，导致识别准确率低。
·密码安全策略风险：
用户不遵守强密码要求：部分用户可能嫌设置强密码麻烦，仍使用简单密码，降低系统安全性。
密码加密算法漏洞：虽采用哈希算法，但算法可能存在新发现的安全漏洞，被黑客利用。
·数据加密风险：
SSL/TLS 协议漏洞：SSL/TLS 协议本身可能被攻破，导致数据传输过程中的加密失效。
加密性能问题：高强度加密可能影响数据传输速度，降低用户体验。
·权限管理系统风险：
权限配置错误：人工配置角色权限时，可能出现权限分配过多或过少的情况。
RBAC 模型局限性：对于复杂的中医业务场景，RBAC 模型可能无法完全满足细粒度的权限控制需求。
·安全审计风险：
事件记录不完整：可能遗漏某些关键安全事件，导致无法准确追溯问题。
审计分析能力不足：缺乏专业的安全审计人员，无法从大量日志中发现潜在安全威胁。
·多终端支持风险：
移动端适配困难：不同手机品牌、型号的屏幕尺寸、操作系统版本差异大，可能导致移动端界面显示异常、功能操作不便。
电脑端兼容性问题：在不同浏览器、操作系统上运行时，可能出现样式错乱、功能无法正常使用的情况。
2.针对每种风险制定具体应对策略
·技术风险应对：
提前技术预研：在项目启动前，对可能用到的新技术进行充分调研和实验，如中医数据分析算法的可行性研究。
引入专家支持：邀请中医信息技术专家或有经验的开发人员进行技术指导。
建立技术备用方案：针对关键技术点，准备多种实现方案，如不同的数据库选型、算法优化思路。
加强团队技术培训：定期组织 Spring Boot 高级应用、中医数据处理技术、加密算法等培训。
·需求变更风险应对：
建立严格需求变更流程：所有需求变更需经过申请、评估、审批等环节。
成立变更评估小组：由产品、开发、测试、业务专家组成，评估变更对项目进度、成本、质量的影响。
合理调整项目计划与资源分配：根据变更评估结果，重新规划项目进度、调配开发资源。
·人力资源风险应对：
关键岗位备份：对关键岗位人员进行技能传承，培养后备力量。
加强团队建设：定期组织团队活动，促进成员间的沟通与协作。
建立激励机制：设立项目奖金、绩效奖励等，提高员工积极性。
开展培训提升技能：针对中医业务知识、技术能力短板，开展专项培训。
·外部因素风险应对：
关注政策法规动态：安排专人跟踪中医药相关政策法规变化，及时调整项目方向。
建立市场监测机制：定期收集市场信息，分析竞品动态，调整产品策略。
与第三方签订严谨合同：明确数据质量、服务稳定性等要求及违约赔偿条款。
提前规划替代方案：如寻找多个数据供应商、备用云服务提供商。
·用户身份验证风险应对：
多因素认证实施：选择可靠的短信发送平台，做好谷歌身份验证器的集成测试，确保稳定性。
生物识别认证适配：与设备厂商合作，优化生物识别算法，提高识别准确率。
·密码安全策略风险应对：
用户教育：在注册、登录页面提示用户设置强密码的重要性及方法。
定期算法评估：关注哈希算法安全动态，及时更新加密算法。
·数据加密风险应对：
协议更新：及时更新 SSL/TLS 协议版本，修复已知漏洞。
性能优化：采用硬件加速、优化加密算法等方式，平衡加密强度与性能。
·权限管理系统风险应对：
权限审核：定期对权限配置进行审核，确保准确性。
模型扩展：根据业务需求，对 RBAC 模型进行适当扩展，满足细粒度权限控制。
·安全审计风险应对：
完善事件记录：制定全面的事件记录规范，确保关键安全事件无遗漏。
提升审计能力：对安全审计人员进行专业培训，或引入专业的安全审计工具。
·多终端支持风险应对：
移动端适配：采用响应式设计，进行多机型测试，确保移动端体验。
电脑端兼容性测试：在主流浏览器、操作系统上进行兼容性测试，及时修复问题。
个人贡献评分准则
尚娴凤：负责整理分配任务
王刚：负责第一，七部分
罗利杰：负责第二，三部分
郭超：负责第六部分
赵文达：负责第四，八部分
余长文：负责第五部分
评估贡献比例
| 姓名 |贡献比例| 完成任务 |
| 尚娴凤 | 16.6 | 整理分配 |
| 王刚 | 16.6 | 七，一 |
| 罗利杰 | 16.6 | 二，三 |
| 郭超 | 16.6 | 六 |
|赵文达 |16.6 | 四，八|
|余长文 |16.6 | 五 |