軟件需求案例分析

1、1、問題描述 許多醫(yī)院存在高峰期掛號排隊時間長，就診等待時間長，倒號現(xiàn)象頻發(fā)的問題。因此，構(gòu)建一個網(wǎng)上預(yù)約掛號系統(tǒng)，通過推薦患者使用該系統(tǒng)進(jìn)行出診信息查詢和醫(yī)生預(yù)約，可以緩解就診壓力、節(jié)約患者的時間，并且可以在一定程度上保證預(yù)約者和就診者一致，有利于提高醫(yī)院的服務(wù)質(zhì)量。為了更好的設(shè)計并實現(xiàn)這一系統(tǒng)，對系統(tǒng)進(jìn)行需求建模和分析是十分必要的。2、情景描述的主要成分2.1、該系統(tǒng)所涉及的用戶本系統(tǒng)的用戶包含患者、醫(yī)生以及管理員三類。而且該三類用戶各自的特征和所要面對的情景也是截然不同的。對于患者來說，他們在年齡、計算機(jī)使用能力等方面存在較大差異，但面對的情景都一樣，就是要預(yù)約掛號，掛號成功過后就診。對

2、于醫(yī)生來說，普遍具備較高的學(xué)歷，在醫(yī)療方面具備專業(yè)知識，有一定的計算機(jī)使用能力。所面對的情景有查看掛號信息，確定要就診的病人。對于管理員來說，他們負(fù)責(zé)對出診信息進(jìn)行管理，是醫(yī)院工作的安排者，具備較強(qiáng)的計算機(jī)使用能力。不同的用戶，對系統(tǒng)的要求也不相同?；颊呦Ｍㄟ^完成注冊和登錄后能夠進(jìn)行掛號預(yù)約，查詢醫(yī)生的出診信息和個人預(yù)約信息，并且能夠在規(guī)定的時間內(nèi)完成掛號預(yù)約或者取消已有的預(yù)約；醫(yī)生則希望能夠在登錄系統(tǒng)后可以查看病人的預(yù)約情況；而管理員希望可以修改出診信息和調(diào)整預(yù)約掛號。這些都是功能性的需求。同時對于所有用戶都希望該系統(tǒng)是易用的，而且能夠?qū)ψ约旱男畔⑵鸬奖Ｗo(hù)即系統(tǒng)安全性的要求，還有比如說系統(tǒng)

3、的性能比較高效，能夠及時處理自己的預(yù)約申請。當(dāng)然開發(fā)系統(tǒng)的成本如果也能較低就更好了。這些都是非功能需求。2.2、情景描述的主要成分l 目標(biāo)和關(guān)鍵成功因素預(yù)約掛號情景的目標(biāo)是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標(biāo)包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預(yù)約記錄，患者能夠取消已有預(yù)約，患者能夠查詢出診信息。關(guān)鍵成功因素，要保證系統(tǒng)能夠24小時正常穩(wěn)定的運行，系統(tǒng)里的信息要是實時變化的，即可以預(yù)約的醫(yī)生要和實際在值班的醫(yī)生要匹配，不能出現(xiàn)掛上號了卻沒有醫(yī)生就診的情況。l 物理上下文和邏輯上下文物理上下文：醫(yī)院用于掛號的計算機(jī)可以正常的使用，情景中的可以被預(yù)約的醫(yī)生應(yīng)該

4、是在醫(yī)院值班的；而對于患者可以選擇在醫(yī)院進(jìn)行預(yù)約，也可選擇在家中進(jìn)行預(yù)約，只要在預(yù)約時間內(nèi)能到達(dá)醫(yī)院就可。邏輯上下文：事件發(fā)生的條件是患者在系統(tǒng)中進(jìn)行了預(yù)約，然后管理員會根據(jù)現(xiàn)有的資源（可以預(yù)約的醫(yī)生）對預(yù)約進(jìn)行處理，如果同意，下一步就是醫(yī)生就診；如果沒有可以預(yù)約的醫(yī)生或合適的時間，患者的預(yù)約就不成功，患者需要重新選擇醫(yī)生或時間進(jìn)行預(yù)約。l 組成情景的主要事件和活動主要事件：患者預(yù)約掛號，管理員對預(yù)約掛號的處理，醫(yī)生就診。主要活動：患者注冊、登錄系統(tǒng)，患者在系統(tǒng)中查詢可以預(yù)約的醫(yī)生和時間，患者取消已有預(yù)約，患者進(jìn)行就診；管理員接受或拒絕預(yù)約，管理員分配醫(yī)生；醫(yī)生查詢預(yù)約信息。l 涉及的執(zhí)行者和

5、其他參與者執(zhí)行者：醫(yī)院的醫(yī)生，預(yù)約掛號系統(tǒng)的管理員。其他參與者：醫(yī)院的相關(guān)人員，比如患者，前臺咨詢員等。l 要使用的信息和資源要使用的信息和資源包括，可以預(yù)約的醫(yī)生數(shù)量，所在科室等，醫(yī)院中的設(shè)備，病房等。l 要考慮的約束條件和要使用的規(guī)則約束條件：同一醫(yī)生同一時間段內(nèi)只能接受一名患者的預(yù)約，根據(jù)醫(yī)療設(shè)備的屬性決定是否要排他性的使用。3、情景需求分析的步驟3.1 目標(biāo)分析在第2部分情景描述的主要成分中已經(jīng)對目標(biāo)進(jìn)行了分析，即：預(yù)約掛號情景的目標(biāo)是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標(biāo)包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預(yù)約記錄，患者能夠取消已有預(yù)約，患者能夠查

6、詢出診信息。3.2 輸入事件分析對于該系統(tǒng)的輸入事件可能會包括如下情況：初始使用該系統(tǒng)的用戶需要先注冊，而對于已經(jīng)注冊的用戶在使用系統(tǒng)預(yù)約掛號時首先要登錄系統(tǒng)。這是最基本的兩個輸入事件。3.3 刻畫系統(tǒng)輸出對于系統(tǒng)輸出我們要考慮系統(tǒng)輸出的形式，比如消息顯示，對話框等形式。不如用戶在登錄系統(tǒng)是輸入的用戶名和密碼不匹配的時候要給出對應(yīng)的提示信息，比如用戶名未注冊或密碼不對等。在提交預(yù)約掛號申請后系統(tǒng)也應(yīng)給出預(yù)約成功與否的提示。3.4輸出需求分析對于輸出需求要根據(jù)用戶的輸入給出對應(yīng)的輸出。比如用戶輸入查詢請求，那么系統(tǒng)應(yīng)該能夠給出詳細(xì)的信息。系統(tǒng)只給出對應(yīng)的輸出還不夠，同時要考慮輸出的信息是否合適。

7、比如用戶要查詢眼科醫(yī)生的資料，系統(tǒng)的輸出就應(yīng)該只是眼科醫(yī)生的信息，而沒有必要把所有醫(yī)生的信息都輸出。3.5 社會影響分析在進(jìn)行社會影響分析時要同時考慮到積極和消極兩個方面的問題。系統(tǒng)是否可以提高效率，減少人員的工作量。同時也要考慮過多的自動化是否會削弱人對整個系統(tǒng)的意識，導(dǎo)致人對意外處理的能力降低，比如系統(tǒng)臨時出現(xiàn)問題，是否有一套應(yīng)急措施使醫(yī)院日常工作能夠正常的進(jìn)行。4、需求說明文檔 基于之前構(gòu)建的模型，并參照IEEE 830-1998標(biāo)準(zhǔn)模板，撰寫的系統(tǒng)需求說明文檔如下。4.1 引言 引言部分將對本文檔的編寫目的、系統(tǒng)的開發(fā)目的、名詞定義以及參考資料進(jìn)行說明，并對文檔的后續(xù)內(nèi)容進(jìn)行概述。4.

8、1.1 編寫目的 網(wǎng)上預(yù)約掛號系統(tǒng)是基于Web開發(fā)技術(shù)完成的網(wǎng)站。為了更好的設(shè)計并實現(xiàn)這一系統(tǒng)，對系統(tǒng)進(jìn)行需求建模和分析是十分必要的。因此，基于之前構(gòu)建的各類模型，撰寫系統(tǒng)的需求說明文檔，并將其作為后續(xù)項目設(shè)計、項目開發(fā)和項目測試的指導(dǎo)。 本文檔連同之前構(gòu)建的模型，可用來與客戶進(jìn)一步明確需求，同時可供項目經(jīng)理、設(shè)計人員、開發(fā)人員參考。4.1.2 系統(tǒng)目的 許多醫(yī)院存在高峰期掛號排隊時間長，就診等待時間長，倒號現(xiàn)象頻發(fā)的問題。因此，構(gòu)建一個網(wǎng)上預(yù)約掛號系統(tǒng)，通過推薦患者使用該系統(tǒng)進(jìn)行出診信息查詢和醫(yī)生預(yù)約，可以緩解就診壓力、節(jié)約患者的時間，并且可以在一定程度上保證預(yù)約者和就診者一致，有利于提高醫(yī)

9、院的服務(wù)質(zhì)量。4.1.3 名詞定義l 患者預(yù)約系統(tǒng) 網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于為患者提供預(yù)約掛號、信息查詢等功能。l 醫(yī)生工作查詢系統(tǒng) 網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于為醫(yī)生提供各時段預(yù)約患者的信息。l 醫(yī)務(wù)管理系統(tǒng) 網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于為管理員提供出診信息修改、預(yù)約掛號調(diào)整等功能。l 賬號控制系統(tǒng) 網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于用戶賬號的注冊及登錄控制。l 安全保障系統(tǒng) 網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于保障系統(tǒng)的程序、網(wǎng)絡(luò)及數(shù)據(jù)庫安全。4.1.4 參考資料1Objectiver: A KAOS tutorial. Respect-It (2004)2吳雙兵,劉偉

10、.網(wǎng)上預(yù)約掛號系統(tǒng)設(shè)計與實現(xiàn)J.醫(yī)學(xué)信息學(xué)雜志, 2015, 36(1):36-39.4.1.5 文檔概述 需求說明文檔主要分為三個部分。本節(jié)屬于引言部分，主要用于對文檔本身進(jìn)行定義和描述。文檔的第二部分為系統(tǒng)的整體描述，包括系統(tǒng)的預(yù)期目標(biāo)、限制條件以及用戶的需求、特征。文檔的第三部分是需求說明，包含對系統(tǒng)需求的明確定義。4.2 整體描述 本節(jié)將對系統(tǒng)預(yù)期、用戶需求、用戶特征、條件與限制、假定與依賴以及需求分配進(jìn)行說明。4.2.1 系統(tǒng)預(yù)期 為了方便用戶在不需安裝任何軟件的情況下使用系統(tǒng)，本系統(tǒng)整體采用B/S結(jié)構(gòu)，用戶可以通過瀏覽器對其進(jìn)行訪問。4.2.2 用戶需求 參照之前完成的目標(biāo)模型，對

11、用戶的需求進(jìn)行整理和定義。由于系統(tǒng)整體較為復(fù)雜，因此本小節(jié)只包含已構(gòu)建目標(biāo)模型的功能性需求和非功能性需求。l 功能性需求1. 患者進(jìn)行預(yù)約選擇 為了實現(xiàn)患者進(jìn)行預(yù)約選擇的目標(biāo)，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)擁有患者預(yù)約頁面以及預(yù)約按鈕：系統(tǒng)的預(yù)約頁面可以顯示未來1至3天的出診醫(yī)生及其所有可被預(yù)約的出診時段。其中，尚未被預(yù)約的時段擁有預(yù)約按鈕；已被預(yù)約的時段無法被其他患者預(yù)約，因此無預(yù)約按鈕。（2）系統(tǒng)接收到預(yù)約請求：當(dāng)患者點擊預(yù)約按鈕，系統(tǒng)可以接收到預(yù)約請求。（3）患者被告知預(yù)約選擇結(jié)果：系統(tǒng)可以對患者是否預(yù)約成功進(jìn)行判定，如果成功則跳轉(zhuǎn)至信息確認(rèn)頁面，否則彈出對話框給予患者相應(yīng)提示。2.

12、患者確認(rèn)預(yù)約信息 為了實現(xiàn)患者確認(rèn)預(yù)約信息的目標(biāo)，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)擁有預(yù)約信息確認(rèn)頁面以及預(yù)約提交按鈕：系統(tǒng)的預(yù)約信息確認(rèn)頁面會顯示預(yù)約的醫(yī)生和時段，患者的個人信息，以及預(yù)約提交按鈕，患者可以在提交預(yù)約前核對這些信息。（2）系統(tǒng)接收到預(yù)約提交請求：當(dāng)患者點擊提交按鈕，系統(tǒng)可以接收到預(yù)約提交請求。（3）患者被告知預(yù)約提交結(jié)果：系統(tǒng)可以對預(yù)約是否提交成功進(jìn)行判定，并彈出對話框給予患者相應(yīng)提示。l 非功能性需求1.安全的系統(tǒng) 為了保證預(yù)約掛號系統(tǒng)的安全性，系統(tǒng)應(yīng)完成的需求如下。（1）用戶程序安全：系統(tǒng)應(yīng)明確區(qū)分不同類別用戶的權(quán)限。并且在用戶登錄時，輸入的密碼不可見、不可復(fù)制。（2）系

13、統(tǒng)網(wǎng)絡(luò)安全：系統(tǒng)應(yīng)采取安全的網(wǎng)絡(luò)傳輸協(xié)議，網(wǎng)絡(luò)數(shù)據(jù)在被傳輸前應(yīng)進(jìn)行加密。（3）數(shù)據(jù)庫安全：數(shù)據(jù)庫中存儲的數(shù)據(jù)應(yīng)具備完整性，且密碼應(yīng)在加密后被存儲到數(shù)據(jù)庫中。此外，數(shù)據(jù)庫中的數(shù)據(jù)應(yīng)該可以被備份和恢復(fù)。2.低成本的系統(tǒng) 為了保證預(yù)約掛號系統(tǒng)的低成本，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)開發(fā)成本低：開發(fā)團(tuán)隊?wèi)?yīng)具備合理的項目管理，且在開發(fā)前應(yīng)盡可能明確系統(tǒng)的需求。（2）系統(tǒng)運營成本低：系統(tǒng)在運行過程中，應(yīng)該盡可能少的占用資源。（3）系統(tǒng)維護(hù)成本低：系統(tǒng)應(yīng)該健壯可靠，出現(xiàn)問題后應(yīng)該易于修復(fù)，且系統(tǒng)的功能應(yīng)該易于擴(kuò)展?？紤]到系統(tǒng)健壯可靠與系統(tǒng)開發(fā)成本低存在一定的沖突，因此需要進(jìn)行一定的權(quán)衡。4.2.3 用戶特

14、征 本系統(tǒng)的用戶包含患者、醫(yī)生以及管理員三類，其特征如下。l 患者 個體間在年齡、計算機(jī)使用能力等方面存在較大差異。l 醫(yī)生 普遍具備較高的學(xué)歷，在醫(yī)療方面具備專業(yè)知識，有一定的計算機(jī)使用能力。l 管理員 負(fù)責(zé)對出診信息進(jìn)行管理，是醫(yī)院工作的安排者，具備較強(qiáng)的計算機(jī)使用能力。4.2.4 條件與限制 為了保證系統(tǒng)的可移植性和可擴(kuò)展性，本系統(tǒng)應(yīng)使用Java語言進(jìn)行開發(fā)。4.2.5 假定與依賴 本系統(tǒng)假定提供的大、中、小三種字體大小可以滿足不同患者的需求，并且患者可以在系統(tǒng)的引導(dǎo)和提示下正常使用系統(tǒng)。4.2.6 需求分配 由于文檔中并未列出系統(tǒng)的全部需求，因此無法對所有需求進(jìn)行優(yōu)先級排序。但已經(jīng)列出

15、的均為系統(tǒng)較為核心的功能性需求和非功能性需求，應(yīng)具有高優(yōu)先級。4.3 需求說明 需求說明部分將參照之前完成的模型，對系統(tǒng)結(jié)構(gòu)、對象模型以及操作過程模型進(jìn)行詳細(xì)描述。4.3.1 系統(tǒng)結(jié)構(gòu) 本部分將主要參照圖 3-1所示的責(zé)任模型，根據(jù)主體對需求進(jìn)行劃分?？紤]到系統(tǒng)較為復(fù)雜，因此只列出主體"患者預(yù)約系統(tǒng)"的相關(guān)需求。l 患者預(yù)約系統(tǒng) 系統(tǒng)擁有患者預(yù)約頁面以及預(yù)約按鈕。 系統(tǒng)接收到預(yù)約請求。 患者被告知預(yù)約選擇結(jié)果。 系統(tǒng)擁有預(yù)約信息確認(rèn)頁面及預(yù)約提交按鈕。 系統(tǒng)接收到預(yù)約提交請求。 患者被告知預(yù)約提交的結(jié)果。4.3.2 對象模型 本部分將主要對圖 4-1所示的對象模型的結(jié)構(gòu)進(jìn)行

16、解釋。 網(wǎng)上預(yù)約掛號系統(tǒng)可以被詳細(xì)劃分為患者預(yù)約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務(wù)管理系統(tǒng)、賬號控制系統(tǒng)、安全保障系統(tǒng)等五個子系統(tǒng)?；颊哳A(yù)約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務(wù)管理系統(tǒng)的使用者分別為患者、醫(yī)生和管理員，這些用戶通過系統(tǒng)提供的頁面與系統(tǒng)進(jìn)行交互。 對象模型中所涉及的名詞在4.1.3小節(jié)中有具體解釋。4.3.3 操作過程模型 本部分將主要對圖 5-1，圖 5-3和圖 5-4所示的操作過程模型進(jìn)行說明，并以表格的形式列出各操作過程的參與主體及對應(yīng)需求。l 患者進(jìn)行預(yù)約選擇 患者點擊預(yù)約按鈕后，患者預(yù)約系統(tǒng)會收到患者的預(yù)約請求，并觸發(fā)預(yù)約驗證操作，得到預(yù)約驗證結(jié)果。接下來，患者預(yù)約系統(tǒng)會以得出的預(yù)約結(jié)果為基礎(chǔ)，進(jìn)行預(yù)約結(jié)果判定，進(jìn)而執(zhí)行頁面跳轉(zhuǎn)或消息框彈出