第一篇：醫院門診系統需求分析報告

醫院門診系統 需求分析報告 目錄

1.引言........................................................................................................................................3 1.1編寫目的.........................................................................................................................3 1.2系統概況.........................................................................................................................3 2.需求概述................................................................................................................................3 2.1醫院的組織機構情況.....................................................................................................3 2.2各部門關系圖.................................................................................................................4 2.3門診部的業務活動情況.................................................................................................4 3.目標及用戶特點....................................................................................................................5 3.1目標.................................................................................................................................5 3.2用戶特點.........................................................................................................................5 4.需求規定................................................................................................................................5 4.1病人信息.........................................................................................................................6 4.2醫生信息.........................................................................................................................6 4.3各種單據的信息.............................................................................................................6 4.4各種庫存信息.................................................................................................................6 5.對功能的規定........................................................................................................................7 6.對性能的規定........................................................................................................................7 6.1安全性要求.....................................................................................................................7 6.2完整性要求.....................................................................................................................8 6.3綜合性能要求.................................................................................................................8 7.系統結構................................................................................................................................9 7.1第一層數據流圖.............................................................................................................9 7.2第二層數據流圖.............................................................................................................9 7.2.1掛號處......................................................................................................................9 7.2.2收費處....................................................................................................................10 7.2.3取藥處....................................................................................................................10 7.2.4化驗處....................................................................................................................10 1.引言

1.1編寫目的

隨著知識經濟的到來，人類已經逐步進入信息化社會。信息增長的速度越來越快，人們希望利用先進的管理理論方法手段來得到并處理越來越多的信息，以提高工作效率和管理水平。由于信息資源對人們生活的重要性，不斷提高信息的收集，傳輸，加以利用等活動，日益成為人們社會生活的重要組成部分。醫院的高效運作也離不開信息系統的開發與利用。因為目前在中國，對于公民來說，看病是一個難題，而醫院的系統不夠完善是導致病人看病不及時或看病麻煩的一個重要原因。為了加快醫院系統的信息化步伐，提高醫院的業務水平，建設和完善醫院信息系已變得十分必要。一般的公立醫院需要有一套完整的掛號、看病、做檢查、取藥、住院等連貫的信息系統，才能有效的管理病人看病的過程，從而有效的管理醫院。

1.2系統概況

本需求分析報告包含醫院門診管理系統的需求分析。

2.需求概述

2.1醫院的組織機構情況

一所醫院的主要構成部分為：門診部和住院部，醫院的所有日常工作都是圍繞這兩大部門進行的。門診部門和住院部門各下設若干科室，如門診部門下設口腔科、內科、外科、皮膚科等，住院部門下設內科、外科、骨科等，二者下設的部分科室是交叉的，各科室都有相應的醫生、護士，完成所承擔的醫療工作。

為了支持這兩大部門的工作，醫院還設置了藥庫、中心藥房、門診藥房、制劑室、設備科、財務科、后勤倉庫、門診收費處、門診掛號處、問訊處、住院處、檢驗科室、檢查科室、血庫、病案室、手術室，以及為醫院的日常管理而設置的 行政部門等。

2.2各部門關系圖

骨科 手術室 中心藥房 住院處 制劑室 住院部 檢驗科室 檢查科室 外科 內科 病案室 藥庫 設備科 財務科 后勤倉庫 門診部 問訊處 門診收費處 門診藥房 口腔科 門診掛號處

2.3門診部的業務活動情況

首先，門診病人需要到門診掛號處掛號（如果病人有需要，可以設置人工咨詢臺對所要就診的相應醫科進行查詢，可查詢該醫科的當班醫生及其基本情況，然后再去掛號），掛號處分為初診病人和復診病人的掛號處，如果是初診病人，需要在門診掛號處登記其基本信息，如姓名、年齡、住址、聯系方式等，由掛號處根據病人所提供的信息制成掛號卡，發放給病人，每個病人對應一個專有的病歷號，這樣方便管理病人的病歷，也方便病人以后再來醫院看病的時候掛號使用；復診病人掛號只需要刷掛號卡就能排號就診，由掛號處管理病人的病歷。

其次，病人持掛號單和繳費收據到相應醫科就醫，經醫生診療后，由醫生開出診斷結果或者處方，檢查或檢驗申請單，如為處方，則病人需持處方單到門診收費處劃價交費，劃價交費的同時，該病人所要領取的處方藥在藥房的系統中自動顯示，藥房人員根據藥方給該病人拿藥，然后病人持收費證明到門診藥房取藥； 如為檢查或檢驗申請單，則病人需持申請單到門診收費處劃價交費，收費處根據交費的先后順序，把所有做檢查的病人排號，然后病人持交費收據到檢查科室進行檢查。

對于門診藥房來說，接到取藥處方后，要進行配藥和發藥，所有藥都在藥房管理系統中進行管理，當藥房庫存的藥品減少到一定量的時候，藥房人員應到藥庫辦理藥品申領，領取所需的藥品，而藥房需對藥品的出庫、入庫和庫存進行管理；

當檢查科室接到病人的申請后，對病人進行檢查，并將檢查結果存入系統中，同時也存入該病人的電子病歷中，如果檢查報告單需要等待一段時間才出結果，病人可以持自己的病歷卡到自助查詢機器上打印化驗結果單。

病人可持檢查或檢驗的結果再到原醫科進行復診，直至醫生開出處方或提出醫療建議，最終病人痊愈離院。

3.目標及用戶特點

3.1目標

該系統為醫院提供一個集門診劃價、收費、發藥、化驗、住院于一體的管理信息系統，可實現信息存儲、更新、查詢等多項功能，為醫務工作者和病人提供方便。

3.2用戶特點

該系統的用戶大多是醫院的醫務工作者、后勤工作人員、藥劑師等，工作時間緊張，所以需要系統的運作使工作效率有大幅度提高，因此對系統的要求需要很完善，涉及到工作人員每一個工作細節。

4.需求規定

由于系統的使用主體是醫院的管理人員，因此對系統的信息要求可分為以下 幾個方面：

4.1病人信息

病人的基本信息應該包括病人的姓名、性別、出生年月、年齡、家庭住址、聯系方式等。對于門診病人，還需要就診時間，就診醫科，就診結果，處方記錄，檢查時間，檢查項目，檢查結果，檢驗時間，檢驗項目，檢驗結果等。對于住院病人，還需要入院時間，所在病區，所在醫科，床位號，主治醫師，用藥記錄，檢查時間，檢查項目，檢查結果，檢驗時間，檢驗項目，檢驗結果，手術時間，手術相關記錄，病人病情變化記錄，相關體檢記錄，出院時間等。

4.2醫生信息

醫生的基本信息包括醫生的姓名、性別、出生年月、家庭住址、聯系方式、所在醫科、工齡、職稱、工號等。對于門診醫生，還需要掛號單價，當天工作量，出診時間等。對于住院醫生，還需要所在病區，負責病人，診斷記錄及手術記錄等。

4.3各種單據的信息

各種單據，證明，如醫生診斷書，處方單，檢驗申請單，檢查申請單，檢驗結果報告單，檢查結果報告單，收款單，病人醫療記錄，手術申請單，手術通知單，病人入院登記單，轉科申請單，病人情況登記單，藥品提領單，藥品發放記錄，藥品出庫單，藥品入庫單，設備使用記錄，器械領用單，器械使用記錄等。

4.4各種庫存信息

各種庫存，如藥品、制劑、設備、器械以及后勤勞保用品等的信息，包括入庫記錄，出庫記錄，庫存量，單價等。5.對功能的規定

系統應當完成以下的信息處理：

（1）存儲病人的信息、醫生信息、單據、庫存信息，以供查詢。

（2）對病人信息、醫生信息、庫存信息進行及時的更新和統計，如根據醫生的出診情況、工齡、工作量、職稱等，得出醫生工資中相應的應得金額，完成對醫生工資的計算和統計，供發放。

（3）病人的電子病歷可以存儲在IC卡中，病人復診的時候能夠刷卡掛號，查詢化驗結果的時候能在自助查詢機上刷卡進行查詢，以便提高醫院工作的效率。（4）各種單據、證明以及記錄，根據實際需要，進行更新，統計，自動處理，等等，如對病人病情的記錄的及時更新，對藥品提領情況的及時統計，通過系統，自動生成一些單證，如系統將手術申請單進行相應的處理，根據所存儲的信息得出相關信息，如手術可進行時間，手術室地點安排等，進而生成手術通知單。（5）對各種庫存信息的及時更新和統計以及相關的自動處理，系統應根據庫存量，入庫量，出庫量，自動得出新的即時的庫存量，完成更新，當庫存少到一定程度，系統應提出警告，提示管理人員庫存不足，使管理人員做出相應的處理。（6）對醫院所需的各種報表能根據計算機的統計，自動生成，例如統計圖形、趨勢圖等，以便研究工作中寫分析報告，也可以對科研做貢獻。

（7）所有原始數據和統計數據進行相關分析，如門診收入，住院收入，藥品收支，物資情況，醫療信息，病區床位利用率，床位周轉率等。

6.對性能的規定

6.1安全性要求

系統應對不同用戶設置不同的權限，區分不同的用戶，如區分病人（只能查詢醫生的出診情況，醫科設置，醫生簡介和本人的信息），醫生（只能查詢本醫科診治的病人資料，本人的信息，醫院的公共信息等），管理人員（可查詢醫院相關的運作情況，并可根據其工作內容，錄入相關的信息，修改相關的記錄），系統管理員（可對系統進行日常維護，包括數據更新，權限設置等），院長（可查詢醫院所有運作情況（包括醫院的醫療管理、經濟管理、行政管理等）的數據，醫生的信息，以及各種統計和分析結果等）。

6.2完整性要求

a、各種信息記錄的完整性，信息記錄內容不能為空； b、各種數據間相互的聯系的正確性； c、相同的數據在不同記錄中的一致性。

6.3綜合性能要求

模快化設計，具有良好的可擴充性，以適應醫院不同階段的發展需要。方便的系統剪裁功能，各子系統間任意選擇是否聯網。信息共享、準確及時交流信息：發揮網絡功能，減少重復操作，提高工作效率。徹底改變手工或單機管理對信息收集處理中的重復、混亂和容易出錯的狀況，充分利用計算機網絡及關系型數據庫的資源共享、數據共享等技術。一個環節錄入信息，其它環節可以共享，確保數據的準確性和一致性。基本信息錄入采用拼音輸入方式，鼠標操作，基本不需輸入漢字，大大提高工作效率。7.系統結構

7.1第一層數據流圖

刷卡掛號、掛號單門診掛號處病人基本信息病人收據藥品門診藥房處結果報告單門診病歷處方單、化驗申請單復診時查詢上次病歷診斷完錄入病歷病歷、檢查報告單收處方據單、化驗申請單門診收費處檢查申請單、收據醫生診斷檢查化驗科

7.2第二層數據流圖 7.2.1掛號處

病人基本信息初診病人電子病歷、IC卡錄入病人基本信息并讀入IC卡病人基本信息IC卡復診病人掛號處理門診病歷掛號單病人 7.2.2收費處

檢查申請單掛號單病人劃價處理收費明細繳費開收據收費證明病人處方單門診病歷

7.2.3取藥處

劃價病人藥品清單進入藥房管理系統取藥單藥房配藥并發藥藥品藥品庫存信息入系統病人

7.2.4化驗處

化驗處化驗申請單、病歷病人病歷情況醫生診療化驗報告單、病歷病人門診病歷

第二篇：醫院門診管理系統數據庫需求分析

醫院門診管理系統一、引言

門診是醫院管理的重要組成部分，人流量大，手續較為繁瑣。在人工的情況下，醫護人員要做大量不必要的重復的工作、效率低、準確性差、不方便管理、影響工作效率。這些都會造成病人得不到合理快速的解決方案。隨著社會的不斷發展進步，計算機的發展亦十分迅速，在各大領域都發揮著不可忽視的作用。因此，我們選擇利用計算機設計一個醫院的門診管理系統。它可以實現數據的信息管理，在一定程度上實現自動化。

二、需求分析

本系統的主要功能是對醫院門診患者信息進行有效管理，形成一個完整的體系。主要任務是用計算機來對患者進行管理，如掛號、診斷、計價、收費、取藥等。系統可以詳細記錄病人從掛號處掛號到門診繳費，以及經醫生診斷后取藥的過程中的所有信息。

三、主要要求

系統要滿足以下幾個方面：

（1）病人管理

在此管理模式中，維護病人的基本信息，如姓名、性別、聯系方式等。同時也可以刪除、修改、添加病人的信息。

（2）掛號系統管理

輸入病人信息，系統會自動生成掛號費用，掛號之后會自動生成病號信息到病號信息庫中。病歷號必須唯一，以供全系統共享調用，整個系統通過這個唯一病歷號貫通一體，大夫和病人都可以藉此查詢所有的就診歷史信息，并實現劃價收費、藥房取藥等操作。若病號庫中已存在該病號，則可以直接進行掛號操作。

（3）醫生管理

醫生管理模塊中存儲醫生的基本信息。此模塊也實現信息化管理醫生收發病例。

（4）藥品管理

藥品發放由藥房管理人員完成操作，藥房通過收款單來給病人發藥。在病人繳費后，可直接到藥房取藥。發藥的同時減少藥品庫存量。通過查詢病號來確定藥品名稱及數量。

（5）處方管理

處方管理是要完成病歷上病情、病史的記載，以及醫囑的開立和實施。

四、系統功能圖

五、數據字典

六、數據約束條件

（1）一個醫院中有多個診室，一個診室中可有多個員工，但一個員工只屬于一個診室。

（2）員工由員工號來唯一標識，存儲員工的相關信息，格式為：workDatime+流水號；病人由病人編號唯一標識，存儲病人的相關信息，格式為：病人第一次看病時間+流水號；藥品由藥品編號唯一標識，格式為：p/s+國藥準字；掛號由掛號編號唯一標識，格式為：日期+流水號；處方由處方單號唯一標識，格式為：R+日期+流水號。

（3）在同一時間段，藥品發放只為一位病人；在同一時間段，醫生只為一位病人看病。

（4）員工工作年齡超過18歲，滿足工作年齡要求。

（5）聯系電話不超過11位數

七、數據流圖

病人信息 掛號單

繳費 繳費憑證

診斷 處方

取藥憑證 藥物

掛號請求

掛號單 掛號信息 掛號記錄

繳費 收費記錄 收費記錄

收費 醫生信息

醫生記錄

看病

處方 診斷信息 診斷記錄

取藥

藥物信息

藥物 藥物記錄

八、邏輯設計

關系模式：

（1）病人（病人編號、病人姓名、性別、年齡、身份證號、電話、過敏藥物）

（2）病歷（病歷編號、就診日期、主要癥狀）

（3）員工（員工編號、姓名、性別、年齡、身份證號、電話、職位、工資、工作日期、工作年限）

（4）科室（科室編號、科室名稱、科室位置、負責人、電話、科室介紹）

（5）掛號單（掛號單編號、掛號時間、掛號費）；

（6）藥品（藥品編號、藥品名稱、藥品類別、單價、主要成分、主要功能、用法用量、供應商、生產日期、有效日期、庫存量）

（7）處方（處方編號、就診日期、病人編號、員工編號、藥品名稱、藥品數量）

九、E-R圖

第三篇：系統需求分析報告

系統需求分析報告

目錄

目錄.............................................................................................................I

1、項目描述...............................................................................................1 1.1 背景................................................................................................1 1.2研究意義........................................................................................1

2、需求分析...............................................................................................1 2.1功能需求分析................................................................................2 2.1.1 系統管理功能......................................................................2 2.1.2 流量劫持功能....................................................................2 2.2性能需求分析................................................................................2

I

1、項目描述

1.1 背景

隨著網絡的普及，網絡業務應用向深度和廣度不斷發展，方便用戶的同時，也因用戶終端存在網絡安全漏洞或用戶網絡安全意識的疏忽，使得網絡上涉及如：電子商務、在線游戲、DNS授權服務、網銀支付系統、社交網站、論壇、博客、門戶網站等在線業務受到黑客及網絡犯罪份子的攻擊，對個人用戶信息（網銀、支付錢包賬號密碼等）的保密和對國家互聯網信息管理與審計構成嚴重威脅。

1.2研究意義

本項目針對以上問題，主要利用了以下兩種技術：僵尸網絡反制技術及HTTP/HTTPS協議通信的監控技術。

網絡攻擊已嚴重威脅著網絡的安全，及時的發現網絡攻擊并在必要的時候劫持與反制網絡攻擊，成為保障互聯網正常運行、保障在線業務系統正常訪問的重要方法。

2、需求分析

經過與項目委托方多次討論，設計系統的目的是為實現對特定非法用戶Web（HTTP/HTTPS協議）通信進行監控及反制，具體要求實現的功能有：監控系統遠程控制、針對特定非法用戶上網流量劫持、針對特定非法用戶Web通信進行JS腳本注入、獲取非法用戶賬號和密碼、獲取非法用戶訪問某些網站的Cookie。

第 1 頁 2.1功能需求分析

根據監控系統的要求對系統的功能進行分析，明確了系統需要實現的功能。系統的功能結構模塊：系統管理功能、流量劫持功能、監控與反制功能。

2.1.1 系統管理功能

系統管理模塊主要負責系統登錄、系統遠程控制、黑名單庫配置、數據存儲和展示。數據展示包含數據存儲和數據展示，數據存儲負責接收后端和前端JS探針采集的數據并存儲到數據庫，數據展示負責提取數據庫數據并顯示。

2.1.2 流量劫持功能

本文流量劫持指DNS協議劫持，主要由四個部分組成：報文捕獲、協議解析、IP及域名查找匹配、DNS協議欺騙。

2.2性能需求分析

1.DNS流量劫持成功率

為了達到項目委托單位的要求，需要對特定用戶訪問特定網站的流量進行準確監控，同時保證流量劫持的成功率（90%以上）。

2.監控與反制系統并發量

監控與反制系統服務器的并發性能直接決定同時能夠監聽的用戶數。當被監控用戶數過大，監控與反制系統并發處理能力到極大挑戰。

3.系統運行穩定性

第 2 頁 系統穩定性是系統最基本也是最重要的要求，運行穩定性關系到系統能否長時間穩定運行。系統的穩定性體現在：隨著運行時間的增加，系統并不會出現內存泄露、甚至系統崩潰等情況。其中內存泄露可通過內存消耗、CPU使用率指標度量。

第 3 頁

第四篇：醫院血庫管理系統需求分析

醫院血庫管理系統

需求分析

學生姓名：張曉楓 學院：信息工程學院 專業：信息管理與信息系統 班級：

B1602班 學號：

0916160217 指導教師：金鳴鏑

遼東學院

Eastern Liaoning University

一、可行性分析報告

系統開發的有關背景：

醫院血庫管理系統是一個醫院不可缺少的部分。人工管理方式存在著許多缺點：效率低，保密性差，另外時間一長，將產生大量的文件和數據，這對于查找，更新和維護都帶來不少困難。隨著科學技術的不斷提高，計算機學日漸成熟。它已進入人類社會的各個領域并發揮重要作用。使用計算機檔案信息管理，有好多好處：查找方便，可靠性高，存儲量大，保密性好，成本低等，能夠極大提高管理的效率，也是醫院信息管理的科學化，與世界接軌的重要條件。

系統開發項目的目標：

目標：提高工作效率，建立數據一致性和完整性強,數據安全性好的數據庫，開發功能完備、易使用的前端應用程序。

可能性分析：當前，計算機價格已經十分低廉，性能卻有了長足的進步。它已經應用于許多領域。現在我國的病人及醫師管理水平絕大部分停留在紙介質的基礎上，這樣的機制已經不能適應時代的發展，因為它浪費了許多人力和物力，在信息時代，這種傳統的管理方法必然被以計算機為基礎的信息管理所取代。因此，血庫管理信息系統的建立具備很大的可能性。

必要性分析：血庫管理系統是每個醫療機構管理病人和醫生必不可少的管理信息系統，它的內容對于醫療機構的管理者來說是至關重要的，所以血庫管理系統應該能夠為每一個醫療機構的管理者提供充足的信息和快捷的查詢手段，大大的方便醫療機構的管理者的合理管理。

計算機的成熟應用已經進入各個行業領域，血庫管理的工作必然要借助計算機技術。

使用計算機對血庫進行管理，具有手工管理無可比擬的優點：檢索迅速、查找方便、可靠性高、存儲量大、保密性好、壽命成本低等。能夠極大地提高管理效率。這些優點能夠極大地提高病人及醫師管理的效率，也是醫療機構理財的科學化、正規化管理與先進科學技術接軌的重要條件。

因此，開發這樣一套管理系統是很有必要的，從某種意義上講也是將計算機應用于現實管理的一次很有意義的實踐活動。

系統主要功能結構: 第一，系統維護包括用戶管理、密碼管理、數據庫備份、背景設置、退出等選項。第二，血液管理包括入庫信息與出庫信息。第三，系統查詢包括血液庫存及出入庫查詢和打印。第四，系統幫助包括系統關于及輔助文件。

系統開發可行性分析：

一、技術可行性：

本系統將采用Microsoft SQL Server 2005技術。SQL是英文Structured Query Language的縮寫，意思為結構化查詢語言。SQL語言的主要功能就是同各種數據庫建立聯系，進行溝通。按照ANSI(美國國家標準協會)的規定，SQL被作為關系型數據庫管理系統的標準語言。SQL語句可以用來執行各種各樣的操作，例如更新數據庫中的數據，從數據庫中提取數據等。目前，絕大多數流行的關系型數據庫管理系統，如Oracle, Sybase, Microsoft SQL Server, Access等都采用了SQL語言標準。

Microsoft SQL Server 2005是一個全面的數據庫平臺，使用集成的商業智能(BI)工具提供了企業級的數據管理。Microsoft SQL Server 2005數據庫引擎為關系型數據和結構化數據提供了更安全可靠的存儲功能，使您可以構建和管理用于業務的高可用和高性能的數據應用程序。Microsoft SQL Server 2005數據引擎是該企業數據管理解決方案的核心。此外Microsoft SQL Server 2005結合了分析、報表、集成和通知功能。這使企業可以構建和部署經濟有效的BI解決方案，幫助您的團隊通過記分卡、Dashboard、Web services和移動設備將數據應用推向業務的各個領域。與 Microsoft Visual Studio、Microsoft Office System以及新的開發工具包（包括Business Intelligence Development Studio）的緊密集成使Microsoft SQL Server 2005與眾不同。無論您是開發人員、數據庫管理員、信息工作者還是決策者，Microsoft SQL Server 2005都可以為您提供創新的解決方案，幫助您從數據中更多地獲益。

二、經濟可行性：

一個系統從開發到投入使用要考慮到很多的費用開銷，主要包括設備的購買費用，軟件的開發費用，系統的維護費用等等，而本系統的開發周期不是很長，運行時對硬件的配置要求也不是很高，管理員經過簡單的培訓就可以勝任，維護起來也方便。

三、管理可行性：

本系統操作簡單，管理員經過一段時間的培訓以后，就可以獨立完成對本系統的管理。通過三個方面的分析，可以明確該系統的設計是可行的，具有經濟，技術，管理等方面的支持，滿足了系統開發的基礎和前提條件的要求，為系統開發的進一步實施明確了目標。

二、業務流程圖

輸血申請表做相關處理，以滿足輸血條件病人輸血前檢查 不合格申請表合格申請表血庫血液余量無所需血液需血單配血掃描條碼、血液出庫有所需血液記錄并聯系其他醫院血庫輸血及輸血后檢查不良反應記錄獻血者獻血登記表無不良反應記錄血庫管理人員核查信息不合格登記表記錄輸血情況排查過期血液集中處理合格登記表輸血存檔血液采集，貼標簽血液入庫廢血存檔血庫存檔匯總存檔單

三、數據流程圖

血庫血液管理信息系統頂層數據流程圖

輸血申請 病人 輸血信息，登記血液管理系統血液信息血液余量信息血庫管理人員獻血申請獻血者獻血信息

血庫血液管理信息系統中層數據流程圖

病人申請信息P1病人輸血申請處理審批意見D1輸血記錄血庫管理人員P2血液出庫登記D2血庫余量獻血者P4血液入庫登記血液信息申請信息D3獻血記錄P5過期血液排查P3獻血申請處理審批意見D4廢血記錄

輸血申請處理（P1）數據流程底圖

病人申請信息P1.1申請審核合格的申請信息P1.2輸血登記D1輸血記錄血庫管理人員病人輸血信息P1.3病人信息更新

血液出庫（P2）數據流程底圖

血庫管理人員P2.2血液出庫登記輸血申請成功信息確認成功血液出庫P2.3更新血庫信息P2.1審核D2血庫余量

獻血申請處理（P3）數據流程底圖 獻血者申請信息P3.1申請審核合格的申請信息P3.2獻血登記D1獻血記錄

血液入庫（P4）數據流程底圖

血庫管理人員P4.2血液入庫登記獻血申請成功信息確認成功血液入庫P4.3更新血庫信息P4.1審核D2血庫余量過期血液排查（P5）數據流程底圖

四、數據字典

（1）數據結構的定義

數據結構編號:DT01 數據結構名稱:輸血申請單

簡 述:患者所需血量、血型等信息 數據結構組成:姓名+性別+申請原因

數據結構編號:DT02 數據結構名稱:明細單

簡 述:每一條進出庫詳細信息

數據結構組成: DS002+入庫信息+出庫信息

（2）數據流定義 數據流編號：DT03 數據流名稱：血液出庫單 簡述：血庫批準通過的申請單 數據流來源：血庫管理者

數據流組成：領用血量+血型+日期+領用科室（數據流量：10袋/天高峰流量：25袋/天）

數據流編號：DT04 數據流名稱：血液入庫單 簡述：采集血量的詳細信息 數據流來源：采血人員 數據流去向：血液入庫模塊

數據流組成：獻血量+日期+血型+獻血人員的詳細信息（數據流量：8袋/天高峰流量：18袋/天）

（3）處理邏輯的定義

處理邏輯編號:P1 處理邏輯名稱:輸血申請處理 簡 述:根據患者病情

輸入的數據流:患者病情、庫存單、用血量、血型、日期 輸出的數據流:合格輸血申請單 處 理:再根據庫存單、用血量判定血量是否足夠等信息最后得到合格清單。

處理邏輯編號:P2 處理邏輯名稱:血液出庫處理

簡 述:對用血的相關信息進行的記錄 輸入的數據流:患者姓名、血型、日期、用血量。輸出的數據流:出庫單

處 理:根據患者姓名核對用血信息；根據日期判定其過期與否；根據血型、用血量得到最終的出庫單。

處理邏輯編號:P4 處理邏輯名稱:血液入庫處理

簡 述:對采血相關信息進行錄入，形成庫存記錄 輸入的數據流:獻血人員姓名性別、采血量、日期 輸出的數據流:血液入庫單

處 理:對獻血人員姓名性別、采血量、日期進行錄入、整合，得到規范的庫存記錄。

處理邏輯編號:P3 處理邏輯名稱:獻血申請處理 簡 述:按照獻血標準

輸入的數據流:獻血人員姓名性別、采血量、日期、采血人員姓名，性別，工作編號

輸出的數據流:合格獻血申請單

處 理:根據獻血人員姓名性別、采血量、日期得到合格的入庫報表。

（4）數據存儲的定義

數據存儲編號：D2 數據存儲名稱：庫存記錄 簡述：血庫中各種血型的存量 數據存儲組成：血型+數量+日期 關鍵字：血型

相關聯的處理： P2，P3，P4

數據存儲編號：D1、D3 數據存儲名稱：血庫工作記錄 簡述：血液出入庫的詳細記錄

數據存儲組成：用血數據+采血數據 關鍵字：用血量，采血量

相關聯的處理：P1，P2，P3，P4

（5）外部實體的定義

外部實體編號：E1 外部實體名稱：用血病人 輸入的數據流：患者詳細信息 輸出的數據流：用血申請單

外部實體編號：E2 外部實體名稱：獻血者

輸入的數據流：獻血人員的詳細信息 輸出的數據流：獻血單 外部實體編號：E3 外部實體名稱：血庫管理部門 簡述：血庫管理部門工作人員 輸入的數據流：明細單

輸出的數據流：管理決策文檔

第五篇：工資管理系統需求分析報告

工資管理系統需求分析報告

引言

1.編寫目的

編寫該文檔是為了分析人工管理企業工資的流程，把人工模式抽象為可在計算機上處理的自動模式，對企業工資的科學管理進行分析與總結，便于開發小組成員對系統整體功能的認識，通過該文檔，確定了系統的目的和功能，以及管理的流程和方法，同時也為使用者提供參考。

2.背景

隨著企業的快速發展，企業規模越來越大，在職員工的數量也越來越多，企業工資管理更加的復雜，而工資管理是一項瑣碎、復雜而又十分細致的工作，工資計算、發放、核算的工作量很大，一般不允許出錯，如果實行手工操作，每月發放工資須手工填制大量的表格，這就會耗費工作人員大量的時間和精力，計算機進行工資發放工作，不僅能夠保證工資核算準確無誤、快速輸出，而且還可以利用計算機對有關工資的各種信息進行統計，服務于財務部門其他方面的核算和財務處理，同時計算機具有著手工管理所無法比擬的優點.例如:檢索迅速、查找方便、可靠性高、存儲量大、保密性好、壽命長、成本低等。這些優點能夠極大地提高人事工資資管理的效率,也是企業的科學化、正規化管理,與世界接軌的重要條件。這就對企業工資管理提出了新的要求，用計算機管理系統來管理企業工資已經成為目前的趨勢，使用計算機可以高速，快捷地完成以上工作。在計算機聯網后，數據在網上傳遞，可以實現數據共享，避免重復勞動，規范數據管理行為，從而提高了管理效率和水平。企業工資管理系統便是以計算機為工具，通過對工資管理所需的信息管理，不僅把管理人員從繁瑣的數據計算處理中解脫出來，而且優化了管理體系，使其高效化，簡易化，智能化，也提高了透明度和互動性。

3.功能定義

（1）員工基本信息的添加，修改，刪除，查找和輔助查詢。

（2）工資標準設定功能。具體包括工資，出行費，醫療保險,養老金，水電費，其他費用，補貼，獎金標準的設定。

（3）工資信息瀏覽。

（4）員工工資表創建。

（5）工資調整管理。

（6）工資統計。

為完善系統管理功能，增加工資系統用戶管理功能，包括系統用戶數據的添加，修改和刪除。教職員工為系統普通用戶，只能運行系統個人工資查詢功能；系統管理員則能運行系統所有功能，從而有效保證系統數據的安全性。

4.功能描述

用例模型

順序模型（管理員查詢工資）

活動模型(登陸)

4.1員工基本檔案信息管理功能描述：

凡屬于本部門的員工，都需要對其基本的檔案信息做好記錄存儲處理。以方便高級管理人員時時的了解或查閱其員工基本信息。對員工基本信息的操作包括添加信息、修改信息、查詢信息，同時在數據庫中要形成員工基本信息表。

4.2工資管理功能描述： 工資計算：

在進行工資計算之前，管理員首先應該根據部門的實際業務情況確定好各個部門中所需要的工資項目及分別對工資項目進行計算的方式，然后按照系統工資種類的設定，對每個員工分別依次實際工資項目構成情況，如考勤情況工資、底薪工資、獎懲工資、提成工資、應交所得稅等等項目，錄入相應的工資金額數，再計算出總的應得工資、實得工資的工資項目。在數據的錄入過程中系統會根據用戶 3

誤輸、錯誤輸入智能提示引導用戶錄入數據的正確性。要形成的數據庫中的表為員工工資信息表。

工資統計分析：

對員工工資數據計算完后，同時要將工資信息統計分析，如匯總統計，工資項目明細數據的匯總等，又分為對員工個人工資統計分析、部門工資統計分析、月份工資統計分析、季度工資統計分析、年工資分析統計。

4.3工資查詢功能描述：

在查詢這個模塊里，系統能支持用戶在客戶端按照各種不同的字段名稱進行工資信息的查詢。同時，迅速的響應用戶的查詢請求，不同級別的人系統會根據其權限級別的大小享有不同程度的功能。不同級別的人不能越權進行操作。在查詢過程中，為避免由于在同一時刻里訪問人數過多造成響應緩慢時，每登錄的一個用戶，系統記數器自動加一，當記數大于峰值時，系統彈出對話框提示用戶進行等待，從而有效的避免了系統在查詢過程中快速響應的優點。

4.4系統維護：

用戶在第一次使用系統時，在服務器端需要用戶做系統初始化的處理，包括； 1． 設置工資項目種類、相應工資項目的計算

2．設置系統使用用戶及口令、權限的級別，對公司不同要求用戶授不同權限，可限制一次性訪問數據庫用戶數量。對每個訪問數據庫的登陸用戶有日志記錄。由系統管理員維護。在系統運行過程中，數據庫管理員在系統運行過程中，還可以即使的進行系統數據的更改，如：對員工工資數據的更改，對工資項目計算方式的更改，定期做好系統數據的備份操作、還原、清理等。

5.非功能性需求： 5.1可靠性

1． 可恢復性

如果正在使用時出現故障，為了完成做好的工資記錄，需要嘗試采用本地方案（如存儲和轉發）加以解決。對此需要更深入的分析 2． 長時間運行

每月都要對工資結算，要求系統能夠持續可靠運行，3． 容錯性

當員工不能識別，應能夠給予提示。

5.2可支持性

1．可適應性

不同型號的票據打印機打印的效果可能存在差異，軟件能夠支持市場上主流的票據打印機。2．可配置型

人員的權限會根據企業的變化而調整，系統應該能夠方便配置調整。還存在一些其他的配置要求，如打印格式、查詢項目等，對此需要進一步分析。

5.3可行性

1.評價標準

A.是否消耗太多經費，耗時太長； B.是否功能齊全，運行穩定； C.是否方便管理； D.設置是否靈活；

E.是否具有界面靈活，操作簡單的特點。

6.用例說明

本系統的設計目標是能夠對大型企業員工的基本信息和工資信息進行添加和修改，根據個人信息將工資分為職務工資，職稱工資和其他工資。能夠調整工資標準和員工信息，也能夠調整其他工資項目，根據需要對教職員工基本信息和工資信息的查詢，本系統能夠生成各個月的工資表，能夠打印報表方便保存和管理，還包括對系統的一些基本操作功能，比如為完善系統管理功能，增加工資系統用戶管理功能，系統應該包括系統用戶數據的添加，修改和刪除。員工為系統普通用戶，只能運行系統個人工資查詢功能；系統管理員則能運行系統所有功能，從而有效保證系統數據的安全性，系統應該具有簡單，易用，小巧，經典的特色，應該能夠對企業工資管理進行優化，使其系統化，高效化，智能化。并保證工資管理的準確性，簡易性，為企業財務人員提供便利。

7．系統性能需求分析：

7．1 性能需求

此工資管理系統對工資數據精度的計算能在默認情況之下精確到小數點后3位小數，即是精確到分的計算。但在用戶使用過程中，能自行根據實際情況進行小數計算精度的設定，最大能允許保留小數點后5位的精度。在時間特性上，當用戶發出命令請求時的服務器的響應時間、對數據更新處理、工資數據的查詢檢索等上，同樣要求系統響應時間不會超過0.5秒時間。系統支持多種操作系統的運行環境，多不同操作系統，不同文件格式的磁盤

上的數據均能實現信息的互通，及共享。當服務器移植到其他的系統平臺，如：Linux平臺下時，同樣能和其他的系統進行數據存取同步，不會出現系統之間互不兼容的情況，系統支持多系統之間的互連互通，系統有巨大的強健性。

7．2 運行需求

系統在進行數據的錄入、計算、統計的時候，能將數據精確到小數點后三位小數。系統接收到用戶的操作命令后（如：計算處理、查詢等），能迅速的響應其操作請求，響應時間不超過1秒。在同一時間，系統還提供支持至少10個客戶端進行同一個操作請求的響應。

系統可移植較強，在不同的平臺下運行，均不會影響系統的穩定性。同時，支持在客戶端安裝不同操作系統、瀏覽器版本，均不會影響系統的運行。

7．3安全需求

為保障系統數據的安全性，系統采用訪問控制策略，未授權者不能進入系統。同時，對不同級別的用戶授予不同的使用權限。在系統運行期間，如發生掉電尚未保存數據，或由于操作不當等原因導致系統重啟等，為保證數據的易恢復性，系統提供每隔30秒自動保存數據的機制，讓用戶的數據在發生意外時能最大程度上

得到恢復。同時，系統提供強大的容錯性能，當一臺服務器發生故障時，系統能自動切換到另外一臺服務器上，從而保障服務器能長時間的提供系統的運行支持。在輸入數據時，如果用戶輸入的數據不符合系統的要求，則系統自動提示錯誤信息，并要求用戶重新輸入，直到輸入完全正確時才允許進行下一步的操作。

7．4 系統界面需求

系統開發基于C#的開發，界面直觀、簡潔，人機交互性強。基于表單和彈出式窗口的數據錄入方式，菜單點擊的方式操作。用戶使用時，只要是按照格式和要求填入信息，系統在后臺響應用戶操作過程。讓用戶在最短時間里，不需要經過專門培訓，就可以輕松上手使用。

7．5 其他需求

數據不管是在企業內部之間傳輸，還是公司與分公司之間進行遠程數據傳輸時，防止數據被不法分析任意的修改和破壞，只有對信息解密的人員才能最終讀取數據信息。這樣，能 最大程度的防止數據在傳輸過程的安全保密性。

8.總結

在第一階段總體分析的基礎之上，我們小組進在系統需求過程中，主要是圍繞著系統數據流程圖和數據字典這兩個方面展開文檔的編輯工作。當然，在需求分析過程中，我們對系統的功能需求、性能需求、可靠性等方面做了進一步的描述，這為我們進行下一步設計階段的順利進行做好鋪墊的工作。