第一篇：軟件系統需求分析案例

模擬商場關系系統需求分析

小品：模擬商場關系系統需求分析

小品角色：

主角：商場經理，系統分析員

配角：商場秘書，分析員助手

小品斷片臺詞：（可以進行適當增刪）

場景A

商場經理：我們建立一套完整的商業管理軟件系統，包括商品的進、銷、調、存管理，是總部－門店的連鎖經營模式。通過通訊手段門店自動訂貨，供應商自動結算，賣場通過條碼掃描實現銷售，管理人員能夠隨時查詢門店商品銷售和庫存情況。

系統分析員：我已經明白這個項目的大體結構框架，這個對于我們來說是非常重要的，但在制定計劃之前，我們必須收集一些需求。

商場經理：（作驚奇狀）我剛才不是告訴你我們的需求了嗎？

系統分析員：實際上，你剛才跟我說的只是整個項目的概念和目標，真正開發這個項目，我還需要跟真正將要使用這個系統的業務人員進行討論，需要了解和掌握使用系統的業務人員的工作業務流程和每個崗位、每個環節的職責，……

（商場秘書出現，打斷談話，突出經理很忙）

商場經理：他們都很忙的，你們有沒有類似的現有的系統可以參照一下，差不多就可以了！系統分析員：……（欲言）

商場經理：（電話響）我真的很忙，請你馬上開始開發，隨時將你們的進展情況告訴我 場景B

分析員助手：（電話）經理你好，我們想約一下您進行系統需求分析的調查，請問您什么時候方便？

商場經理：什么，我上次不是跟你們說過叫你們開始開發了嗎？還沒有開始的啊？我真的沒有時間啊，你們馬上開始吧，就這樣！（掛機）

（系統分析員將一個超市的管理系統進行了簡單修改送給商場使用）

場景C

商場秘書：經理，XX店說有顧客退貨，那個系統那里辦理不了，還有……

商場經理：這個小王怎么搞得，作個這樣的系統給我們，真是的搞得亂七八糟的！

第二篇：軟件需求-案例分析

1、問題描述

許多醫院存在高峰期掛號排隊時間長，就診等待時間長，倒號現象頻發的問題。因此，構建一個網上預約掛號系統，通過推薦患者使用該系統進行出診信息查詢和醫生預約，可以緩解就診壓力、節約患者的時間，并且可以在一定程度上保證預約者和就診者一致，有利于提高醫院的服務質量。為了更好的設計并實現這一系統，對系統進行需求建模和分析是十分必要的。

2、情景描述的主要成分

2.1、該系統所涉及的用戶

本系統的用戶包含患者、醫生以及管理員三類。而且該三類用戶各自的特征和所要面對的情景也是截然不同的。

對于患者來說，他們在年齡、計算機使用能力等方面存在較大差異，但面對的情景都一樣，就是要預約掛號，掛號成功過后就診。

對于醫生來說，普遍具備較高的學歷，在醫療方面具備專業知識，有一定的計算機使用能力。所面對的情景有查看掛號信息，確定要就診的病人。

對于管理員來說，他們負責對出診信息進行管理，是醫院工作的安排者，具備較強的計算機使用能力。

不同的用戶，對系統的要求也不相同。患者希望通過完成注冊和登錄后能夠進行掛號預約，查詢醫生的出診信息和個人預約信息，并且能夠在規定的時間內完成掛號預約或者取消已有的預約；醫生則希望能夠在登錄系統后可以查看病人的預約情況；而管理員希望可以修改出診信息和調整預約掛號。這些都是功能性的需求。

同時對于所有用戶都希望該系統是易用的，而且能夠對自己的信息起到保護即系統安全性的要求，還有比如說系統的性能比較高效，能夠及時處理自己的預約申請。當然開發系統的成本如果也能較低就更好了。這些都是非功能需求。

2.2、情景描述的主要成分

? 目標和關鍵成功因素

預約掛號情景的目標是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預約記錄，患者能夠取消已有預約，患者能夠查詢出診信息。關鍵成功因素，要保證系統能夠24小時正常穩定的運行，系統里的信息要是實時變化的，即可以預約的醫生要和實際在值班的醫生要匹配，不能出現掛上號了卻沒有醫生就診的情況。

? 物理上下文和邏輯上下文 物理上下文：醫院用于掛號的計算機可以正常的使用，情景中的可以被預約的醫生應該是在醫院值班的；而對于患者可以選擇在醫院進行預約，也可選擇在家中進行預約，只要在預約時間內能到達醫院就可。邏輯上下文：事件發生的條件是患者在系統中進行了預約，然后管理員會根據現有的資源（可以預約的醫生）對預約進行處理，如果同意，下一步就是醫生就診；如果沒有可以預約的醫生或合適的時間，患者的預約就不成功，患者需要重新選擇醫生或時間進行預約。

? 組成情景的主要事件和活動 主要事件：患者預約掛號，管理員對預約掛號的處理，醫生就診。主要活動：患者注冊、登錄系統，患者在系統中查詢可以預約的醫生和時間，患者取消已有預約，患者進行就診；管理員接受或拒絕預約，管理員分配醫生；醫生查詢預約信息。

? 涉及的執行者和其他參與者

執行者：醫院的醫生，預約掛號系統的管理員。其他參與者：醫院的相關人員，比如患者，前臺咨詢員等。

? 要使用的信息和資源 要使用的信息和資源包括，可以預約的醫生數量，所在科室等，醫院中的設備，病房等。? 要考慮的約束條件和要使用的規則 約束條件：同一醫生同一時間段內只能接受一名患者的預約，根據醫療設備的屬性決定是否要排他性的使用。

3、情景需求分析的步驟

需求規格說明輸入過程需求目標列表1.目標分析系統模型目標,目的使用情景用戶問題實例2.輸入事件分析初始系統模型用戶,環境事件情景腳本4.輸出需求分析3.刻畫系統輸出情景結構模型系統輸出類型信息需求5.社會影響分析Agent目標6.涉眾分析需求規格說明

3.1 目標分析

在第2部分情景描述的主要成分中已經對目標進行了分析，即：預約掛號情景的目標是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預約記錄，患者能夠取消已有預約，患者能夠查詢出診信息。3.2 輸入事件分析

對于該系統的輸入事件可能會包括如下情況：初始使用該系統的用戶需要先注冊，而對于已經注冊的用戶在使用系統預約掛號時首先要登錄系統。這是最基本的兩個輸入事件。3.3 刻畫系統輸出

對于系統輸出我們要考慮系統輸出的形式，比如消息顯示，對話框等形式。不如用戶在登錄系統是輸入的用戶名和密碼不匹配的時候要給出對應的提示信息，比如用戶名未注冊或密碼不對等。在提交預約掛號申請后系統也應給出預約成功與否的提示。3.4輸出需求分析

對于輸出需求要根據用戶的輸入給出對應的輸出。比如用戶輸入查詢請求，那么系統應該能夠給出詳細的信息。系統只給出對應的輸出還不夠，同時要考慮輸出的信息是否合適。比如用戶要查詢眼科醫生的資料，系統的輸出就應該只是眼科醫生的信息，而沒有必要把所有醫生的信息都輸出。3.5 社會影響分析

在進行社會影響分析時要同時考慮到積極和消極兩個方面的問題。系統是否可以提高效率，減少人員的工作量。同時也要考慮過多的自動化是否會削弱人對整個系統的意識，導致人對意外處理的能力降低，比如系統臨時出現問題，是否有一套應急措施使醫院日常工作能夠正常的進行。

4、需求說明文檔

基于之前構建的模型，并參照IEEE 830-1998標準模板，撰寫的系統需求說明文檔如下。

4.1 引言

引言部分將對本文檔的編寫目的、系統的開發目的、名詞定義以及參考資料進行說明，并對文檔的后續內容進行概述。4.1.1 編寫目的

網上預約掛號系統是基于Web開發技術完成的網站。為了更好的設計并實現這一系統，對系統進行需求建模和分析是十分必要的。因此，基于之前構建的各類模型，撰寫系統的需求說明文檔，并將其作為后續項目設計、項目開發和項目測試的指導。

本文檔連同之前構建的模型，可用來與客戶進一步明確需求，同時可供項目經理、設計人員、開發人員參考。4.1.2 系統目的

許多醫院存在高峰期掛號排隊時間長，就診等待時間長，倒號現象頻發的問題。因此，構建一個網上預約掛號系統，通過推薦患者使用該系統進行出診信息查詢和醫生預約，可以緩解就診壓力、節約患者的時間，并且可以在一定程度上保證預約者和就診者一致，有利于提高醫院的服務質量。4.1.3 名詞定義 ? 患者預約系統

網上預約掛號系統的子系統，主要用于為患者提供預約掛號、信息查詢等功能。? 醫生工作查詢系統

網上預約掛號系統的子系統，主要用于為醫生提供各時段預約患者的信息。? 醫務管理系統

網上預約掛號系統的子系統，主要用于為管理員提供出診信息修改、預約掛號調整等功能。? 賬號控制系統

網上預約掛號系統的子系統，主要用于用戶賬號的注冊及登錄控制。? 安全保障系統

網上預約掛號系統的子系統，主要用于保障系統的程序、網絡及數據庫安全。4.1.4 參考資料

[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吳雙兵,劉偉.網上預約掛號系統設計與實現[J].醫學信息學雜志, 2015, 36(1):36-39.4.1.5 文檔概述

需求說明文檔主要分為三個部分。本節屬于引言部分，主要用于對文檔本身進行定義和描述。文檔的第二部分為系統的整體描述，包括系統的預期目標、限制條件以及用戶的需求、特征。文檔的第三部分是需求說明，包含對系統需求的明確定義。

4.2 整體描述

本節將對系統預期、用戶需求、用戶特征、條件與限制、假定與依賴以及需求分配進行說明。

4.2.1 系統預期

為了方便用戶在不需安裝任何軟件的情況下使用系統，本系統整體采用B/S結構，用戶可以通過瀏覽器對其進行訪問。4.2.2 用戶需求

參照之前完成的目標模型，對用戶的需求進行整理和定義。由于系統整體較為復雜，因此本小節只包含已構建目標模型的功能性需求和非功能性需求。? 功能性需求

1.患者進行預約選擇

為了實現患者進行預約選擇的目標，系統應完成的需求如下。（1）系統擁有患者預約頁面以及預約按鈕：

系統的預約頁面可以顯示未來1至3天的出診醫生及其所有可被預約的出診時段。其中，尚未被預約的時段擁有預約按鈕；已被預約的時段無法被其他患者預約，因此無預約按鈕。（2）系統接收到預約請求：

當患者點擊預約按鈕，系統可以接收到預約請求。（3）患者被告知預約選擇結果：

系統可以對患者是否預約成功進行判定，如果成功則跳轉至信息確認頁面，否則彈出對話框給予患者相應提示。2.患者確認預約信息

為了實現患者確認預約信息的目標，系統應完成的需求如下。（1）系統擁有預約信息確認頁面以及預約提交按鈕：

系統的預約信息確認頁面會顯示預約的醫生和時段，患者的個人信息，以及預約提交按鈕，患者可以在提交預約前核對這些信息。（2）系統接收到預約提交請求：

當患者點擊提交按鈕，系統可以接收到預約提交請求。（3）患者被告知預約提交結果：

系統可以對預約是否提交成功進行判定，并彈出對話框給予患者相應提示。? 非功能性需求 1.安全的系統

為了保證預約掛號系統的安全性，系統應完成的需求如下。（1）用戶程序安全：

系統應明確區分不同類別用戶的權限。并且在用戶登錄時，輸入的密碼不可見、不可復制。（2）系統網絡安全：

系統應采取安全的網絡傳輸協議，網絡數據在被傳輸前應進行加密。（3）數據庫安全：

數據庫中存儲的數據應具備完整性，且密碼應在加密后被存儲到數據庫中。此外，數據庫中的數據應該可以被備份和恢復。2.低成本的系統 為了保證預約掛號系統的低成本，系統應完成的需求如下。（1）系統開發成本低：

開發團隊應具備合理的項目管理，且在開發前應盡可能明確系統的需求。（2）系統運營成本低：

系統在運行過程中，應該盡可能少的占用資源。（3）系統維護成本低：

系統應該健壯可靠，出現問題后應該易于修復，且系統的功能應該易于擴展。考慮到系統健壯可靠與系統開發成本低存在一定的沖突，因此需要進行一定的權衡。4.2.3 用戶特征

本系統的用戶包含患者、醫生以及管理員三類，其特征如下。? 患者

個體間在年齡、計算機使用能力等方面存在較大差異。? 醫生

普遍具備較高的學歷，在醫療方面具備專業知識，有一定的計算機使用能力。? 管理員

負責對出診信息進行管理，是醫院工作的安排者，具備較強的計算機使用能力。4.2.4 條件與限制

為了保證系統的可移植性和可擴展性，本系統應使用Java語言進行開發。4.2.5 假定與依賴

本系統假定提供的大、中、小三種字體大小可以滿足不同患者的需求，并且患者可以在系統的引導和提示下正常使用系統。4.2.6 需求分配

由于文檔中并未列出系統的全部需求，因此無法對所有需求進行優先級排序。但已經列出的均為系統較為核心的功能性需求和非功能性需求，應具有高優先級。

4.3 需求說明

需求說明部分將參照之前完成的模型，對系統結構、對象模型以及操作過程模型進行詳細描述。

4.3.1 系統結構

本部分將主要參照圖 3-1所示的責任模型，根據主體對需求進行劃分。考慮到系統較為復雜，因此只列出主體“患者預約系統”的相關需求。? 患者預約系統

系統擁有患者預約頁面以及預約按鈕。

系統接收到預約請求。

患者被告知預約選擇結果。

系統擁有預約信息確認頁面及預約提交按鈕。

系統接收到預約提交請求。

患者被告知預約提交的結果。4.3.2 對象模型

本部分將主要對圖 4-1所示的對象模型的結構進行解釋。

網上預約掛號系統可以被詳細劃分為患者預約系統、醫生工作查詢系統、醫務管理系統、賬號控制系統、安全保障系統等五個子系統。患者預約系統、醫生工作查詢系統、醫務管理系統的使用者分別為患者、醫生和管理員，這些用戶通過系統提供的頁面與系統進行交互。

對象模型中所涉及的名詞在4.1.3小節中有具體解釋。4.3.3 操作過程模型

本部分將主要對圖 5-1，圖 5-3和圖 5-4所示的操作過程模型進行說明，并以表格的形式列出各操作過程的參與主體及對應需求。? 患者進行預約選擇

患者點擊預約按鈕后，患者預約系統會收到患者的預約請求，并觸發預約驗證操作，得到預約驗證結果。接下來，患者預約系統會以得出的預約結果為基礎，進行預約結果判定，進而執行頁面跳轉或消息框彈出操作。? 患者確認預約信息

患者點擊提交按鈕后，患者預約系統會收到患者的預約提交請求，并觸發預約提交操作。接下來，患者預約系統會根據提交結果彈出包含相應信息的提示框。

以上部分涉及到的操作過程及與之對應的主體、需求如下表所示。

以上部分涉及到的操作過程及與之對應的主體、需求如表 4-1所示。

操作 預約驗證 參與主體

對應需求

患者預約系統 系統接收到預約請求，患者被告知預約選擇結果

預約結果判定 患者預約系統 患者被告知預約選擇結果 預約提交 患者預約系統 系統接收到預約提交請求，患者被告知預約提交結果

第三篇：軟件需求分析報告

軟件需求分析

軟件需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其它系統元素的接口細節，定義軟件的其它有效性需求。進行需求分析時，應注意一切信息與需求都是站在用戶的角度上。盡量避免分析員的主觀想象，并盡量將分析進度提交給用戶。在不進行直接指導的前提下，讓用戶進行檢查與評價。從而達到需求分析的準確性。分析員通過需求分析，逐步細化對軟件的要求，描述軟件要處理的數據域，并給軟件開發提供一種可轉化為數據設計、結構設計和過程設計的數據和功能表示。在軟件完成后，制定的軟件規格說明還要為評價軟件質量提供依據。

需求分析的任務

開發軟件系統最為困難的部分就是準確說明開發什么。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟件系統的接口。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，并且以后再對它進行修改也極為困難。目前，國內產品的龐雜，一家企業可能有幾個系統并立運行，它們之間接口是系統開發人員最頭痛的問題。對于商業最終用戶應用程序，企業信息系統和軟件作為一個大系統的一部分的產品是顯而易見的。但是對于我們開發人員來說，并沒有編寫出客戶認可的需求文檔，我們如何知道項目于何時結束？而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？然而，即便并非出于商業目的的軟件需求也是必須的。例如庫、組件和工具這些供開發小組內部使用的軟件。當然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現重復返工這種不可避免的后果，而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價，這些血的教訓正在國內的軟件開發者身上發生。近來，我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟件。不幸的是，當他們開發完這個工具后，發現這個工具不能打印出源代碼文件，使用者當然希望有這個功能。結果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構思準確，如果我們沒有編寫文檔，軟件達不到期望目標也只能是咎由自取了。相反的情況，我曾見一個要集成到“錯誤跟蹤系統”中的簡單界面寫了一頁需求說明。而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用。他們依據需求對系統進行測試時，此系統不僅非常清晰地實現了所有必需功能，而且未發現任何錯誤。事實上，需求文檔在開發過程中一直起指導作用。需求的類型

下面這些定義是需求工程領域中常見術語的定義。軟件需求包括三個不同的層次：業務需求、用戶需求和功能需求（也包括非功能需求）。1．業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。2．用戶需求(user requirement)文檔描述了用戶使用產品必須要完成的任務，這在使用實例（usecase）文檔或方案腳本說明中予以說明。3．功能需求(functional requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。在軟件需求規格說明書（SRS）中說明的功能需求充分描述了軟件系統所應具有的外部行為。軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用。對一個大型系統來說，軟件功能需求也許只是系統需求的一個子集，因為另外一些可能屬于子系統（或軟件部件）。作為功能需求的補充，軟件需求規格說明還應包括非功能需求，它描述了系統展現給用戶的行為和執行的操作等。它包括產品必須遵從的標準、規范和合約；外部界面的具體細節；性能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟件產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反

映產品功能。多角度描述產品對用戶和開發人員都極為重要。下面以一個字處理程序為例來說明需求的不同種類。業務需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器。而對應的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實現整個文檔范圍的替換。從以上定義可以發現，需求并未包括設計細節、實現細節、項目計劃信息或測試信息。需求與這些沒有關系，它關注的是充分說明你究竟想開發什么。項目也有其它方面的需求，如開發環境需求或發布產品及移植到支撐環境的需求。

第四篇：門禁系統需求分析

門禁系統建設需求分析

1.是否聯網通過RS485還是TCP/IP 方式？如果采用485，是否需要配置485 HUB?(增加通訊距離，掛接更多的控制器)如果采用TCP/IP 是直接采用網絡轉換器還是通過TCP/IP轉化器？ 2.門禁控制器類型：單門，雙門，四門，八門控制器還是門禁一體機？

3.識別方式：密碼，指紋，刷卡，識別臉等? 4.管控方向：單項刷卡還是雙向刷卡？

5.卡片類型:EM（智能采用EM 讀卡器，需要聯網）,Mifare，HID 6.讀卡器類型:韋根，485,如何發卡：通過控制器，232讀卡器，鍵盤口讀卡器，輸入卡號？

7.系統軟件：單機版還是網絡版？需要考勤，電梯和更新軟件模塊嗎？

8.電控鎖類型：磁力鎖，電插鎖(陽極鎖，雙向開門)，陰極鎖，需要支架嗎？

9.供電方式：集中供電還是分散供電？ 10.線材選材：RVVP 還是RVSP? 聯網門禁系統說明：

1：

說明：進出安裝兩個按鍵讀卡器，通過韋根接口連接到單門控制器上，進出均可提供三種開門方式，刷卡、刷卡+密碼和安全密碼。但不可以設為進門不要密碼管制，而出門要密碼管制進出安裝兩個指紋讀卡器，通過韋根接口連接到單門控制器上。兩臺指紋讀卡器，可通過485接口連接到控制器的485 總線上，便可通過計算機將采集到的指紋，下傳到指紋讀卡器中，或者將指紋讀卡器中指紋數據備份到計算機中。

2：

? 指紋一體機就是集成了指紋讀頭的單門控制器

? 指紋一體機可內置射頻讀卡模塊，提供刷卡+指紋等更多種開門方式

? 如果內置了Mifare讀寫模塊，還可以配置成將指紋存儲在Mifare卡中。正常情況下，指紋存儲在指紋機中。

? 指紋存儲在Mifare卡中，一個最大的好處是，提供1:1的指紋比對方式，提供系統的安全性，降低誤識率；同時一臺指紋機管理的員工數量，不再受到指紋機中指紋存儲容量的限制，可增加到 10,000個員工。

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

系統需求分析報告

目錄

目錄.............................................................................................................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 頁