需求分析

基于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 | 五 |