【正文】 隨著計算機科學與技術學院學院人數(shù)不斷增加，畢業(yè)生的人數(shù)也會逐步增長，畢業(yè)生就業(yè)管理的難度也在不斷加大，所有我們認為建立一個計算機科學與技術學院畢業(yè)生就業(yè)管理系統(tǒng)是在將來的影響和效益是不可估量。第五篇：軟件需求案例分析問題描述許多醫(yī)院存在高峰期掛號排隊時間長，就診等待時間長，倒號現(xiàn)象頻發(fā)的問題。因此，構建一個網(wǎng)上預約掛號系統(tǒng)，通過推薦患者使用該系統(tǒng)進行出診信息查詢和醫(yī)生預約，可以緩解就診壓力、節(jié)約患者的時間，并且可以在一定程度上保證預約者和就診者一致，有利于提高醫(yī)院的服務質量。為了更好的設計并實現(xiàn)這一系統(tǒng)，對系統(tǒng)進行需求建模和分析是十分必要的。情景描述的主要成分、該系統(tǒng)所涉及的用戶本系統(tǒng)的用戶包含患者、醫(yī)生以及管理員三類。而且該三類用戶各自的特征和所要面對的情景也是截然不同的。對于患者來說，他們在年齡、計算機使用能力等方面存在較大差異，但面對的情景都一樣，就是要預約掛號，掛號成功過后就診。對于醫(yī)生來說，普遍具備較高的學歷，在醫(yī)療方面具備專業(yè)知識，有一定的計算機使用能力。所面對的情景有查看掛號信息，確定要就診的病人。對于管理員來說，他們負責對出診信息進行管理，是醫(yī)院工作的安排者，具備較強的計算機使用能力。不同的用戶，對系統(tǒng)的要求也不相同?；颊呦Ｍㄟ^完成注冊和登錄后能夠進行掛號預約，查詢醫(yī)生的出診信息和個人預約信息，并且能夠在規(guī)定的時間內完成掛號預約或者取消已有的預約；醫(yī)生則希望能夠在登錄系統(tǒng)后可以查看病人的預約情況；而管理員希望可以修改出診信息和調整預約掛號。這些都是功能性的需求。同時對于所有用戶都希望該系統(tǒng)是易用的，而且能夠對自己的信息起到保護即系統(tǒng)安全性的要求，還有比如說系統(tǒng)的性能比較高效，能夠及時處理自己的預約申請。當然開發(fā)系統(tǒng)的成本如果也能較低就更好了。這些都是非功能需求。、情景描述的主要成分l 目標和關鍵成功因素預約掛號情景的目標是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預約記錄，患者能夠取消已有預約，患者能夠查詢出診信息。關鍵成功因素，要保證系統(tǒng)能夠24小時正常穩(wěn)定的運行，系統(tǒng)里的信息要是實時變化的，即可以預約的醫(yī)生要和實際在值班的醫(yī)生要匹配，不能出現(xiàn)掛上號了卻沒有醫(yī)生就診的情況。l 物理上下文和邏輯上下文 物理上下文：醫(yī)院用于掛號的計算機可以正常的使用，情景中的可以被預約的醫(yī)生應該是在醫(yī)院值班的；而對于患者可以選擇在醫(yī)院進行預約，也可選擇在家中進行預約，只要在預約時間內能到達醫(yī)院就可。邏輯上下文：事件發(fā)生的條件是患者在系統(tǒng)中進行了預約，然后管理員會根據(jù)現(xiàn)有的資源（可以預約的醫(yī)生）對預約進行處理，如果同意，下一步就是醫(yī)生就診；如果沒有可以預約的醫(yī)生或合適的時間，患者的預約就不成功，患者需要重新選擇醫(yī)生或時間進行預約。l 組成情景的主要事件和活動 主要事件：患者預約掛號，管理員對預約掛號的處理，醫(yī)生就診。主要活動：患者注冊、登錄系統(tǒng)，患者在系統(tǒng)中查詢可以預約的醫(yī)生和時間，患者取消已有預約，患者進行就診；管理員接受或拒絕預約，管理員分配醫(yī)生；醫(yī)生查詢預約信息。l 涉及的執(zhí)行者和其他參與者執(zhí)行者：醫(yī)院的醫(yī)生，預約掛號系統(tǒng)的管理員。其他參與者：醫(yī)院的相關人員，比如患者，前臺咨詢員等。l 要使用的信息和資源 要使用的信息和資源包括，可以預約的醫(yī)生數(shù)量，所在科室等，醫(yī)院中的設備，病房等。l 要考慮的約束條件和要使用的規(guī)則 約束條件：同一醫(yī)生同一時間段內只能接受一名患者的預約，根據(jù)醫(yī)療設備的屬性決定是否要排他性的使用。情景需求分析的步驟, 目標分析在第2部分情景描述的主要成分中已經(jīng)對目標進行了分析，即：預約掛號情景的目標是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預約記錄，患者能夠取消已有預約，患者能夠查詢出診信息。 輸入事件分析對于該系統(tǒng)的輸入事件可能會包括如下情況：初始使用該系統(tǒng)的用戶需要先注冊，而對于已經(jīng)注冊的用戶在使用系統(tǒng)預約掛號時首先要登錄系統(tǒng)。這是最基本的兩個輸入事件。 刻畫系統(tǒng)輸出對于系統(tǒng)輸出我們要考慮系統(tǒng)輸出的形式，比如消息顯示，對話框等形式。不如用戶在登錄系統(tǒng)是輸入的用戶名和密碼不匹配的時候要給出對應的提示信息，比如用戶名未注冊或密碼不對等。在提交預約掛號申請后系統(tǒng)也應給出預約成功與否的提示。對于輸出需求要根據(jù)用戶的輸入給出對應的輸出。比如用戶輸入查詢請求，那么系統(tǒng)應該能夠給出詳細的信息。系統(tǒng)只給出對應的輸出還不夠，同時要考慮輸出的信息是否合適。比如用戶要查詢眼科醫(yī)生的資料，系統(tǒng)的輸出就應該只是眼科醫(yī)生的信息，而沒有必要把所有醫(yī)生的信息都輸出。 社會影響分析在進行社會影響分析時要同時考慮到積極和消極兩個方面的問題。系統(tǒng)是否可以提高效率，減少人員的工作量。同時也要考慮過多的自動化是否會削弱人對整個系統(tǒng)的意識，導致人對意外處理的能力降低，比如系統(tǒng)臨時出現(xiàn)問題，是否有一套應急措施使醫(yī)院日常工作能夠正常的進行。需求說明文檔基于之前構建的模型，并參照IEEE 8301998標準模板，撰寫的系統(tǒng)需求說明文檔如下。 引言引言部分將對本文檔的編寫目的、系統(tǒng)的開發(fā)目的、名詞定義以及參考資料進行說明，并對文檔的后續(xù)內容進行概述。 編寫目的網(wǎng)上預約掛號系統(tǒng)是基于Web開發(fā)技術完成的網(wǎng)站。為了更好的設計并實現(xiàn)這一系統(tǒng)，對系統(tǒng)進行需求建模和分析是十分必要的。因此，基于之前構建的各類模型，撰寫系統(tǒng)的需求說明文檔，并將其作為后續(xù)項目設計、項目開發(fā)和項目測試的指導。本文檔連同之前構建的模型，可用來與客戶進一步明確需求，同時可供項目經(jīng)理、設計人員、開發(fā)人員參考。 系統(tǒng)目的許多醫(yī)院存在高峰期掛號排隊時間長，就診等待時間長，倒號現(xiàn)象頻發(fā)的問題。因此，構建一個網(wǎng)上預約掛號系統(tǒng)，通過推薦患者使用該系統(tǒng)進行出診信息查詢和醫(yī)生預約，可以緩解就診壓力、節(jié)約患者的時間，并且可以在一定程度上保證預約者和就診者一致，有利于提高醫(yī)院的服務質量。 名詞定義 l 患者預約系統(tǒng)網(wǎng)上預約掛號系統(tǒng)的子系統(tǒng)，主要用于為患者提供預約掛號、信息查詢等功能。l 醫(yī)生工作查詢系統(tǒng)網(wǎng)上預約掛號系統(tǒng)的子系統(tǒng)，主要用于為醫(yī)生提供各時段預約患者的信息。l 醫(yī)務管理系統(tǒng)網(wǎng)上預約掛號系統(tǒng)的子系統(tǒng)，主要用于為管理員提供出診信息修改、預約掛號調整等功能。l 賬號控制系統(tǒng)網(wǎng)上預約掛號系統(tǒng)的子系統(tǒng)，主要用于用戶賬號的注冊及登錄控制。l 安全保障系統(tǒng)網(wǎng)上預約掛號系統(tǒng)的子系統(tǒng)，主要用于保障系統(tǒng)的程序、網(wǎng)絡及數(shù)據(jù)庫安全。 參考資料[1]Objectiver: A KAOS (2004)[2]吳雙兵,[J].醫(yī)學信息學雜志, 2015, 36(1): 文檔概述需求說明文檔主要分為三個部分。本節(jié)屬于引言部分，主要用于對文檔本身進行定義和描述。文檔的第二部分為系統(tǒng)的整體描述，包括系統(tǒng)的預期目標、限制條件以及用戶的需求、特征。文檔的第三部分是需求說明，包含對系統(tǒng)需求的明確定義。 整體描述本節(jié)將對系統(tǒng)預期、用戶需求、用戶特征、條件與限制、假定與依賴以及需求分配進行說明。 系統(tǒng)預期為了方便用戶在不需安裝任何軟件的情況下使用系統(tǒng)，本系統(tǒng)整體采用B/S結構，用戶可以通過瀏覽器對其進行訪問。 用戶需求參照之前完成的目標模型，對用戶的需求進行整理和定義。由于系統(tǒng)整體較為復雜，因此本小節(jié)只包含已構建目標模型的功能性需求和非功能性需求。l 功能性需求為了實現(xiàn)患者進行預約選擇的目標，系統(tǒng)應完成的需求如下。（1）系統(tǒng)擁有患者預約頁面以及預約按鈕：系統(tǒng)的預約頁面可以顯示未來1至3天的出診醫(yī)生及其所有可被預約的出診時段。其中，尚未被預約的時段擁有預約按鈕；已被預約的時段無法被其他患者預約，因此無預約按鈕。（2）系統(tǒng)接收到預約請求：當患者點擊預約按鈕，系統(tǒng)可以接收到預約請求。（3）患者被告知預約選擇結果：系統(tǒng)可以對患者是否預約成功進行判定，如果成功則跳轉至信息確認頁面，否則彈出對話框給予患者相應提示。為了實現(xiàn)患者確認預約信息的目標，系統(tǒng)應完成的需求如下。（1）系統(tǒng)擁有預約信息確認頁面以及預約提交按鈕：系統(tǒng)的預約信息確認頁面會顯示預約的醫(yī)生和時段，患者的個人信息，以及預約提交按鈕，患者可以在提交預約前核對這些信息。（2）系統(tǒng)接收到預約提交請求：當患者點擊提交按鈕，系統(tǒng)可以接收到預約提交請求。（3）患者被告知預約提交結果：系統(tǒng)可以對預約是否提交成功進行判定，并彈出對話框給予患者相應提示。l 非功能性需求 為了保證預約掛號系統(tǒng)的安全性，系統(tǒng)應完成的需求如下。（1）用戶程序安全：系統(tǒng)應明確區(qū)分不同類別用戶的權限。并且在用戶登錄時，輸入的密碼不可見、不可復制。（2）系統(tǒng)網(wǎng)絡安全：系統(tǒng)應采取安全的網(wǎng)絡傳輸協(xié)議，網(wǎng)絡數(shù)據(jù)在被傳輸前應進行加密。（3）數(shù)據(jù)庫安全：數(shù)據(jù)庫中存儲的數(shù)據(jù)應具備完整性，且密碼應在加密后被存儲到數(shù)據(jù)庫中。此外，數(shù)據(jù)庫中的數(shù)據(jù)應該可以被備份和恢復。 為了保證預約掛號系統(tǒng)的低成本，系統(tǒng)應完成的需求如下。（1）系統(tǒng)開發(fā)成本低：開發(fā)團隊應具備合理的項目管理，且在開發(fā)前應盡可能明確系統(tǒng)的需求。（2）系統(tǒng)運營成本低：系統(tǒng)在運行過程中，應該盡可能少的占用資源。（3）系統(tǒng)維護成本低：系統(tǒng)應該健壯可靠，出現(xiàn)問題后應該易于修復，且系統(tǒng)的功能應該易于擴展?？紤]到系統(tǒng)健壯可靠與系統(tǒng)開發(fā)成本低存在一定的沖突，因此需要進行一定的權衡。 用戶特征本系統(tǒng)的用戶包含患者、醫(yī)生以及管理員三類，其特征如下。l 患者個體間在年齡、計算機使用能力等方面存在較大差異。l 醫(yī)生普遍具備較高的學歷，在醫(yī)療方面具備專業(yè)知識，有一定的計算機使用能力。l 管理員負責對出診信息進行管理，是醫(yī)院工作的安排者，具備較強的計算機使用能力。 條件與限制為了保證系統(tǒng)的可移植性和可擴展性，本系統(tǒng)應使用Java語言進行開發(fā)。 假定與依賴本系統(tǒng)假定提供的大、中、小三種字體大小可以滿足不同患者的需求，并且患者可以在系統(tǒng)的引導和提示下正常使用系統(tǒng)。 需求分配由于文檔中并未列出系統(tǒng)的全部需求，因此無法對所有需求進行優(yōu)先級排序。但已經(jīng)列出的均為系統(tǒng)較為核心的功能性需求和非功能性需求，應具有高優(yōu)先級。 需求說明需求說明部分將參照之前完成的模型，對系統(tǒng)結構、對象模型以及操作過程模型進行詳細描述。 系統(tǒng)結構本部分將主要參照圖 31所示的責任模型，根據(jù)主體對需求進行劃分。考慮到系統(tǒng)較為復雜，因此只列出主體“患者預約系統(tǒng)”的相關需求。l 患者預約系統(tǒng)系統(tǒng)擁有患者預約頁面以及預約按鈕。系統(tǒng)接收到預約請求?；颊弑桓嬷A約選擇結果。系統(tǒng)擁有預約信息確認頁面及預約提交按鈕。系統(tǒng)接收到預約提交請求?；颊弑桓嬷A約提交的結果。 對象模型本部分將主要對圖 41所示的對象模型的結構進行解釋。網(wǎng)上預約掛號系統(tǒng)可以被詳細劃分為患者預約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務管理系統(tǒng)、賬號控制系統(tǒng)、安全保障系統(tǒng)等五個子系統(tǒng)?；颊哳A約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務管理系統(tǒng)的使用者分別為患者、醫(yī)生和管理員，這些用戶通過系統(tǒng)提供的頁面與系統(tǒng)進行交互。 操作過程模型本部分將主要對圖 51，圖 53和圖 54所示的操作過程模型進行說明，并以表格的形式列出各操作過程的參與主體及對應需求。l 患者進行預約選擇患者點擊預約按鈕后，患者預約系統(tǒng)會收到患者的預約請求，并觸發(fā)預約驗證操作，得到預約驗證結果。接下來，患者預約系統(tǒng)會以得出的預約結果為基礎，進行預約結果判定，進而執(zhí)行頁面跳轉或消息框彈出操作。l 患者確認預約信息患者點擊提交按鈕后，患者預約系統(tǒng)會收到患者的預約提交請求，并觸發(fā)預約提交操作。接下來，患者預約系統(tǒng)會根據(jù)提交結果彈出包含相應信息的提示框。以上部分涉及到的操作過程及與之對應的主體、需求如下表所示。以上部分涉及到的操作過程及與之對應的主體、需求如表 41所示。操作 預約驗證 參與主體對應需求患者預約系統(tǒng) 系統(tǒng)接收到預約請求，患者被告知預約選擇結果預約結果判定 患者預約系統(tǒng) 患者被告知預約選擇結果 預約提交 患者預約系統(tǒng) 系統(tǒng)接收到預約提交請求，患者被告知預約提交結果