軟件需求案例分析

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

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

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

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

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

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

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

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

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

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

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

12、患者確認(rèn)預(yù)約信息 為了實(shí)現(xiàn)患者確認(rèn)預(yù)約信息的目標(biāo)，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)擁有預(yù)約信息確認(rèn)頁(yè)面以及預(yù)約提交按鈕：系統(tǒng)的預(yù)約信息確認(rèn)頁(yè)面會(huì)顯示預(yù)約的醫(yī)生和時(shí)段，患者的個(gè)人信息，以及預(yù)約提交按鈕，患者可以在提交預(yù)約前核對(duì)這些信息。（2）系統(tǒng)接收到預(yù)約提交請(qǐng)求：當(dāng)患者點(diǎn)擊提交按鈕，系統(tǒng)可以接收到預(yù)約提交請(qǐng)求。（3）患者被告知預(yù)約提交結(jié)果：系統(tǒng)可以對(duì)預(yù)約是否提交成功進(jìn)行判定，并彈出對(duì)話框給予患者相應(yīng)提示。l 非功能性需求1.安全的系統(tǒng) 為了保證預(yù)約掛號(hào)系統(tǒng)的安全性，系統(tǒng)應(yīng)完成的需求如下。（1）用戶程序安全：系統(tǒng)應(yīng)明確區(qū)分不同類(lèi)別用戶的權(quán)限。并且在用戶登錄時(shí)，輸入的密碼不可見(jià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ù)庫(kù)安全：數(shù)據(jù)庫(kù)中存儲(chǔ)的數(shù)據(jù)應(yīng)具備完整性，且密碼應(yīng)在加密后被存儲(chǔ)到數(shù)據(jù)庫(kù)中。此外，數(shù)據(jù)庫(kù)中的數(shù)據(jù)應(yīng)該可以被備份和恢復(fù)。2.低成本的系統(tǒng) 為了保證預(yù)約掛號(hào)系統(tǒng)的低成本，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)開(kāi)發(fā)成本低：開(kāi)發(fā)團(tuán)隊(duì)?wèi)?yīng)具備合理的項(xiàng)目管理，且在開(kāi)發(fā)前應(yīng)盡可能明確系統(tǒng)的需求。（2）系統(tǒng)運(yùn)營(yíng)成本低：系統(tǒng)在運(yùn)行過(guò)程中，應(yīng)該盡可能少的占用資源。（3）系統(tǒng)維護(hù)成本低：系統(tǒng)應(yīng)該健壯可靠，出現(xiàn)問(wèn)題后應(yīng)該易于修復(fù)，且系統(tǒng)的功能應(yīng)該易于擴(kuò)展?？紤]到系統(tǒng)健壯可靠與系統(tǒng)開(kāi)發(fā)成本低存在一定的沖突，因此需要進(jìn)行一定的權(quán)衡。4.2.3 用戶特

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

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

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