第一篇：軟件需求分析考試資料

1、需求分析的最終結果是需求規格說明書。

2、需求分析中開發人員要從用戶那里解決的最重要的問題是讓軟件做什么。

3、需求規格說明書中的內容不應該包括對算法的詳細過程的描述。

4、需求規格說明書的作用不應包括軟件可行性研究的依據。

5、關于面向對象方法中消息的敘述，不正確的是操作系統不斷向應用程序發送消息，但應

用程序不能向操作系統發送消息。

6、面向對象技術中，對象是類的實例，對象有三種成分標識、屬性、方法（或操作）

7、軟件需求分析階段的工作，可以分成以下四個方面對問題的識別、分析與綜合、制定規

格說明以及需求分析評審。

8、軟件需求規格說明書的內容不應該包括對算法的詳細過程的描述。

9、產品特性可以稱為質量屬性，在眾多質量屬性，對于開發人員來說重要的屬性有哪些？

可維護性、可移植性、可重用性、可測試性

10、求包括11個方面的內容，其中網絡和操作系統的要求屬于環境需求，如何隔離用戶之間的數據屬于安全保密需求，執行速度、相應時間及吞吐量屬于性能需求，規定系統平均出錯時間屬于質量保證。

11、需求分析過程應該建立3中模型，他們分別是數據模型、功能模型、行為模型，以下幾種圖形中，數據流圖（DFD）屬于功能模型，實體-聯系圖（ERD）屬于數據模型，狀態轉換圖（STD）屬于行為模型。

12、常用的需求分析方法有：面向數據流的結構化分析方法（SA），面向對象的分析的分析方法（OOA），下列(D)不是結構化分析方法的圖形工具。

A 決策樹B 數據流圖C數據字典D快速原型

13、軟件開發中，原型是軟件的一個早期可運行的版本，它反映最終系統的部分重要特性，其中，探索型和實驗型用完可以丟棄，而進化型圍繞原型修改、增加。

14、數據流圖用于描述數據的處理過程。

15、DFD 的基本符號不包括下列哪種？（A）。

A 數據字典B 加工C 外部實體D 數據流E 數據存儲文件

16、DD的主要字典條目包括以下哪種（E）

A 數據流B文件C 數據項D加工E以上都是

17、常用的動態分析方法不包括以下哪種（B）

A 狀態遷移圖B 層次方框圖C 時序圖D Petri網

18、需求分析階段的文檔包括以下哪些（E）

A 軟件需求規格說明書B 數據要求說明書C 初步的用戶手冊D 修改、完善與確定開發實施計劃E 以上都是

19、需求驗證應該從下述幾個方面進行驗證：（C）

A 可靠性、可用性、易用性、重用性B 可維護性、可移植性、可重用性、可測試性

C 一致性、現實性、完整性、有效性 D 功能性、非功能性

20、風險管理的要素包括哪些（D）

A 風險評價B 風險避免C 風險控制D 以上都是

21、下列描述中錯誤的是（D）

A 每一個集成的需求變更必須能跟蹤控制到一個經核準的變更請求。

B 變更過程應該做成文檔，盡可能簡單，當然首要的是有效性。

C 所有需求變更必須遵循過程，按照此過程，如果一個變更需求未被采納，則其后過程不再予以考慮。

D 可以從數據庫中刪除或修改變更請求的原始文檔。

二、填空題

1、需求分析階段產生的最重要的文檔是（需求分析說明書）。

2、需求分析的主要任務是（要回答“軟件必須做什么？”）。

3、需求分析階段，分析人員要確定對問題的綜合需求，其中最主要的是(功能需求)需求。

4、需求分析階段研究的對象是軟件項目的(用戶要求)。

5、軟件生命周期：問題分析、可行性研究、需求分析、總體設計、詳細設計、編碼和單元測試、綜合測試、軟件維護。

6、信息系統必須實現的功能，或者說信息系統必須具備的屬性和質量稱為（系統需求（需求））

7、（模型）是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述通常，由一組圖形符號和組織這些符號的規則組成。

8、軟件需求分析階段的目的是澄清用戶的要求，并把雙方共同的理解明確地表達成一份書面文檔——（軟件需求規格說明書。

9、軟件需求分類，分為（功能性）需求和（非功能性）需求。

10、需求分析的步驟包括（需求獲取）、（分析建模）、文檔編寫。。

三、名詞解釋

第一、二空缺。

3、需求工程：整個軟件需求范圍內所進行的活動稱為需求過程，需求工程包括需求開發和需求管理兩部分，需求開發包括問題獲取、分析、編寫規格說明和驗證。

4、業務模型：業務模型是理解是理解一個組織業務過程的技術，可以用業務用例模型和業務對象模型來表達業務模型，業務用例模型分別是分別從與業務過程和客戶對應的業務用例和業務參與者的角度來描述企業的業務過程；業務對象模型描述了如何由一組工作人員使用一些業務實體和工作單元來實現每個業務用例。

5、原型開發方法：一個軟件原型是所提出的新產品的部分市縣，使用原型有三個主要目的：

1）明確并完善需求，2）探索設計選擇方案，3）發展成為最終的產品，建立原型的主要原因是為了解決在產品開發的早期階段不確定的問題，原型可分為拋棄型原型和進化型原型。

6、數據字典：一個定義應用程序中使用的所有數據元素和結構的含義、類型、數據大小、格式、度量單位、精度以及允許取值范圍的共享倉庫。

四、簡答題

1、生命周期模型是什么？常見的生命周期模型有哪幾種？

答：對軟件開發流程的一種描述：為解決問題所定義的策略；對典型開發活動的抽象。常見的生命周期模型：Waterfall，Prototyping，Phased，Spiral（瀑布模型、快速原型模型、增量模型,螺旋模型）

2、為什么要使用生命周期模型？

答：幫助開發組了解他們在開發項目的活動、資源和限制；幫助項目了解在開發過程中的不一致，丟失，冗余等情況，把注意力集中在開發最終產品上；幫助項目組剪裁開發過程——沒有基礎就無從剪裁。

3、waterfall的優勢是什么？

答：具有良好定義的里程碑，利于向不熟悉軟件開發的客戶講解流程；幫助開發人員理解需要做的事情；清楚地描述下階段開始前需要的中間產品；是很多其他LC模型的基礎。

4、需求分析階段的基本人物是什么？

答：需求分析階段的基本任務是：

（1）問題識別：雙方對問題的綜合需求；a.功能需求 b.性能需求c.環境需求d.用戶界面

需求。

（2）分析與綜合，到處軟件的邏輯模型。

（3）編寫文檔。

五、問答題

1、軟件過程的概念及分類，基本過程包含些什么及每個過程的具體內容。

答：軟件過程也稱為軟件生存周期過程或軟件過程組，是指軟件生存周期中的一系列相關過程，過程就是過程的集合，活動是任務的集合，人物則起到把輸入加工成輸出的作用。活動的執行可以是順序的、迭代的（重復的）、并行的、嵌套的或是有條件引發的。

軟件過程可以分為三類：基本過程、支持過程和組織過程。

基本過程包括：

1）獲取過程：（項目委托方）確定需求；招標；簽訂合同；對供應方的監督；驗收完成。

2）供應過程：（項目承包方）理解需求；投標；簽訂合同；計劃；實施；控制；評審評

價；交付。

3）開發過程：（軟件開發人員）過程實施準備；系統需求分析；系統結構設計；軟件需

求分析；軟件體系結構設計；軟件詳細設計；軟件編碼測試；軟件集成；軟件合格測試；系統集成；系統合格測試；軟件安裝；驗收支持。

4）運行過程：（用戶）運行準備；運行測試；產品轉移；運行；運行支持；運行評價。

5）維護過程：（維護人員）過程實施準備；問題分析和修改設計；修改實施；對維護的評審和驗收；軟件移植；軟件退役。

2、簡述軟件需求工程分為哪幾類？其中需求獲取和需求規約的目的和任務。

答：軟件需求工程細分為：需求獲取、需求分析與協商、系統建模、需求規約、需求驗證和需求管理六個階段。

需求獲取：系統分析人員通過與用戶的交流，對現有系統的觀察及任務進行分析，確定系統或產品范圍的限制性描述、與系統或產品有關的人員及特征列表、系統的技術環境的描述、系統功能的列表及應用于每個需求的領域限制、一組描述不同運行條件下系統或產品使用狀況的應用場景以及為更好地定義需求而開發的任意原型。

需求規約：軟件需求規約是分析任務的最終產物，通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準，給出對目標的各種要求。需求規約作為用戶和開發組之間的一個協議，在之后的軟件工程各個階段發揮重要作用。

3、簡述軟件體系結構的概念及基于B/S體系結構的實現方式。

答：軟件體系結構：軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件，處理構件負責對數據進行加工，數據構件是被加工的信息，連接構件把體系結構的不同部分組合連接起來。

B/S結構：瀏覽器（客戶機）—WEB服務器—數據庫服務器

B/S體系結構的實現方式：B/S模式下的客戶機只需安裝瀏覽器軟件，無須開發前端應用程序；中間層的WEB應用服務器，主要的數據計算和應用都在此完成，因此對中間層服務器的要求較高；后臺數據庫服務器主要完成數據的管理。

4、用戶界面設計三個的任務和目的答：用戶界面設計在工作流程上分為結構設計、交互設計、視覺設計三個部分。

1)結構設計：結構設計也稱概念設計，是界面設計的骨架，通過用戶研究和任務分析，制定出產品的整體架構，基于紙質的低保真原型可提供用戶測試并進行完善，在結

構設計中，目錄體系的邏輯分類和語詞定義是用戶易于理解和操作的重要前提。

2)交互設計：交互設計的目的是使產品讓用戶能簡單使用，任何產品功能的實現都是

通過人和機器的交互來完成的。因此，人的因素應作為設計的核心被體現出來。

3)視覺設計：在結構設計的基礎上，參照目標群體的心理模型和任務達成進行視覺設

計，包括色彩、字體、頁面等，視覺設計要達到用戶愉悅使用的目的。

5、需求規格說明文檔的作者及表現手段

答：作者：

項目管理者：組織安排、提供條件。

需求工程師：負責人、主導人。

文檔寫作人員：有時會采用，節省需求工程師的時間

涉眾（用戶）：驗證人

表現手段：

非形式化：自然語言、限制性文本

半形式化：結構化文本（偽碼/結構化英語）、模型語言（圖、表）

形式化：形式化語言（數學語言：BNF）

6、數據庫設計的內容及常用方法

答：數據庫設計包括數據庫的結構設計和數據庫的行為設計。

1）數據庫的結構設計

數據庫的結構設計指是根據給定的應用環境，進行數據庫的模式或子模式的設計。它包括數據庫的概念設計、邏輯設計和物理設計，數據庫模式是各應用程序共享的結構，是靜態的、穩定的，一經形成后通常情況下是不容易改變的，所以結構設計又稱為靜態模型設計。

2）數據庫的行為設計

數據庫的行為設計是指確定數據庫用戶的行為和動作，而在數據庫系統中，用戶的行為和動作指用戶對數據庫的操縱，這些要通過應用程序來實現，所以數據庫的行為設計就是應用程序的設計。用戶的行為總是使數據庫的內容發生變化，所以行為設計是動態的，行為設計又稱為動態模型設計。

數據庫常用設計方法：直觀設計法、規范設計法、計算機輔助設計法、自動化設計法。

7、如何正確看待客戶？

答：即使最終用戶不是上帝，也算是上帝的親戚，同樣怠慢不得

如果項目規模比較大，那么開發方與最終用戶的來往就比較多。如從最終用戶那里獲取詳細的需求，請最終用戶試驗軟件，對最終用戶進行培訓等等。

8、概括說明如何進行需求分析？

答：（1）需求分析是指需求開發過程中，對所獲取的需求信息進行分析，及時排除錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖。

（2）分析方法大體有兩類：“回答分析法”和“建模分析法”。

第一：問答分析方法很簡單：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了，一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討”，問答分析最重要的問題是：“是什么”和“為什么”，其它常見的問題有：需求存在二義性嗎？需求文檔的上下文有矛盾嗎？需求完備嗎?需求是必要的嗎？需求可實現嗎？需求可驗證嗎？需求的優先級確定了嗎？

第二：建模分析法：在需求開發過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效，所以將圖形與文本結合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求，需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用、建議將模型存放在需求文檔的附錄中，便于正文引用。建模分析方法主要有兩大類：“結構化分析法“和”面向對象分析方法“。

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

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）中說明的功能需求充分描述了軟件系統所應具有的外部行為。軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用。對一個大型系統來說，軟件功能需求也許只是系統需求的一個子集，因為另外一些可能屬于子系統（或軟件部件）。作為功能需求的補充，軟件需求規格說明還應包括非功能需求，它描述了系統展現給用戶的行為和執行的操作等。它包括產品必須遵從的標準、規范和合約；外部界面的具體細節；性能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟件產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反

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

第四篇：軟件項目需求分析總結

軟件項目需求分析總結

我們做的需求只解決了我們能做出這樣的項目，但是沒有解決這樣的項目是不是真就是客戶想要的。造成這種狀況的原因主要是下面幾個情況：

客戶本身說不清楚

文物網是這樣，中彰國際更是這樣，但是這不能怪客戶，畢竟客戶在軟件方面的知識要少的多，也沒有相關的經驗，可能心里只有一個想要的軟件的輪廓，于是可能會要求我們去替他們來完整這個輪廓的細節，而我們的能力、我們能否真正站在客戶角度去搜集和整理這些需求，就決定了這個需求的完整性和有效性。

需求自身經常變動

隨著客戶對這個項目越來越深刻的理解，那么可能他的需求也會隨之改變，這些變化的可能性越大項目風險就會越大，我們在需求分析的時候就要充分考慮到哪些需求是相對固定的需求，哪些可能會是產生變動的需求，考慮到他的可變性，這樣設計功能和數據庫的時候不致因為后面的變動而影響整個工程。分析人員或客戶理解有誤

畢竟，不是每個分析人員都是專業而合格的，為避免這種情況的發生，需求分析必須要有審核制度，公司自己內部要審核一遍，客戶再審一遍，提出意見，修改后雙方共同評審簽字，確認。

由此出現的問題：

a)需求分析過于籠統，只關注到面上，沒有關注到點上，開發出來的東西在具體的細節上和客戶的理解有誤差，并且無法嚴格界定是否屬于需求變更。中彰的方案就是這樣的。

b)需求報告只求我們這方評審通過，不去關心客戶的評審，認為只要客戶簽字認可就行。雖然簽字認可能夠給日后出現問題時劃清我們的責任，但是不能保證使項目實施成功。

c)需求分析中含有技術實施上有難度的功能，一味的求全和盲目按照客戶的設想，受客戶影響過大，畢竟，很多時候，客戶的想法在實際實施過程中是不現實的，或者可以有更為簡便的方法來替代的。如中彰國際的在線交易功能，后臺大批量郵件群發功能。

d)對雙方已經確定的需求，實現以后并不適合客戶使用，需要按照變更手續執行的時候，客戶可能會糾纏，提出“你們是專業人士，你們應該事先能提醒我們可能會出現這種問題”并以此來把責任推給我們，而我們又不好完全按照變更手續執行，因為可能激化雙方的矛盾，比如508的批量處理功能，因為屬于人事

管理比較專業的細節問題，需求分析師開始沒有對客戶業務熟悉到如此細致的地步，而客戶也沒有過多關注這些細節，導致軟件的某些功能不合用，較為繁瑣，而重新按著客戶的意見修改的話工作量比較大，導致成本增加、工期延長。e)項目的成熟度受客戶預算的限制。大部分客戶在項目投入上都是有預算的，在成本有上限的前提下，項目的功能設計(軟件的成熟度)方面必然受一定影響，畢竟功能越多越完善，相應的開發成本就越高。這種功能上的不完善需要事先告知客戶并得到理解。

f)此項工作的反復造成思想上的倦怠，使需求分析最后虎頭蛇尾。需求分析是一項繁瑣枯燥的工作，需要和客戶之間不斷的商討、確認和反復，另外由于大部分的客戶雖然安排專人負責這項工作，但是該人并不只做這項工作，特別當他被很多其他的事情纏身的時候，而無心細看提交過去的需求報告的時候，他很可能會給你一個錯覺，讓你認為他已經真正的理解并認可了你的設計。結論

a)需求分析是整個項目管理中需要重點控制的幾個關鍵節點之一，首先思想上一定要重視。

b)需求分析報告的編寫者要參與到需求的搜集工作中，準確領會客戶的意圖，并轉化成軟件能夠實現的功能。對于說不清楚需求的客戶，要善于問關鍵問題，引導客戶提出自己的需求。可以采取的措施是事先編制一個問卷調查之類的文檔，詳細列舉需要客戶回答的問題，以便防止遺漏。

c)需求報告的編寫者要能夠對客戶需求進行深入分析，區別出哪些需求存在日后變更的可能，哪些需求屬于相對固定的，哪些需求能夠實現，哪些需求需要變通才能實現，以便于指導后面的功能設計。

d)需求分析報告對功能細節的描述不能有歧義，描述一定要全面、準確，防止開發方和客戶只見對同一個問題有兩個截然不同的理解。可以通過評審，用大家的力量來避免這種情況發生

e)需求報告的每個關乎功能的描述都要讓客戶明白和理解，客戶在理解之上的確認才能夠保證日后一旦出現問題不致出現雙方互相推托責任糾纏不清的情況。

f)需求報告一定要經過一個有技術人員和業務人員參加的評審，要充分發揮團隊的力量，重視每個人的才智，一個模塊一個功能的逐一的過，讓大家來共同找出需求報告里不合理的、有歧義的、不完善的、遺漏的等等問題g)幫助客戶去理解提交給他的需求分析報告而不是只等簽字，對于有能夠用好幾種方式實現的功能，盡量做到能讓客戶去比較和選擇。不要讓客戶對報告中的部分產生歧義。只有客戶對報告的完全的理解，才能在日后客戶提出的修改被認為是需求變更的時候能夠得到客戶的理解

h)最后，需求分析報告一定要雙方共同簽字確認

第五篇：軟件項目需求分析總結

軟件項目需求分析總結

需求分析是項目開發的基礎，基礎打的牢不牢直接關系到后面所有的工作，是項目實施成敗的關鍵 總體上說，我們的需求分析是做了，但是做得很不夠，我們做的需求只解決了我們能做出這樣的項目，但是沒有解決這樣的項目是不是真就是客戶想要的。造成這種狀況的原因主要是下面幾個情況： 客戶本身說不清楚 文物網是這樣，中彰國際更是這樣，但是這不能怪客戶，畢竟客戶在軟件方面的知識要少的多，也沒有相關的經驗，可能心里只有一個想要的軟件的輪廓，于是可能會要求我們去替他們來完整這個輪廓的細節，而我們的能力、我們能否真正站在客戶角度去搜集和整理這些需求，就決定了這個需求的完整性和有效性。需求自身經常變動 隨著客戶對這個項目越來越深刻的理解，那么可能他的需求也會隨之改變，這些變化的可能性越大項目風險就會越大，我們在需求分析的時候就要充分考慮到哪些需求是相對固定的需求，哪些可能會是產生變動的需求，考慮到他的可變性，這樣設計功能和數據庫的時候不致因為后面的變動而影響整個工程。分析人員或客戶理解有誤 畢竟，不是每個分析人員都是專業而合格的，為避免這種情況的發生，需求分析必須要有審核制度，公司自己內部要審核一遍，客戶再審一遍，提出意見，修改后雙方共同評審簽字，確認。由此出現的問題： a)需求分析過于籠統，只關注到面上，沒有關注到點上，開發出來的東西在具體的細節上和客戶的理解有誤差，并且無法嚴格界定是否屬于需求變更。中彰的方案就是這樣的。b)需求報告只求我們這方評審通過，不去關心客戶的評審，認為只要客戶簽字認可就行。雖然簽字認可能夠給日后出現問題時劃清我們的責任，但是不能保證使項目實施成功。c)需求分析中含有技術實施上有難度的功能，一味的求全和盲目按照客戶的設想，受客戶影響過大，畢竟，很多時候，客戶的想法在實際實施過程中是不現實的，或者可以有更為簡便的方法來替代的。如中彰國際的在線交易功能，后臺大批量郵件群發功能。d)對雙方已經確定的需求，實現以后并不適合客戶使用，需要按照變更手續執行的時候，客戶可能會糾纏，提出“你們是專業人士，你們應該事先能提醒我們可能會出現這種問題”并以此來把責任推給我們，而我們又不好完全按照變更手續執行，因為可能激化雙方的矛盾，比如508的批量處理功能，因為屬于人事管理比較專業的細節問題，需求分析師開始沒有對客戶業務熟悉到如此細致的地步，而客戶也沒有過多關注這些細節，導致軟件的某些功能不合用，較為繁瑣，而重新按著客戶的意見修改的話工作量比較大，導致成本增加、工期延長。e)項目的成熟度受客戶預算的限制。大部分客戶在項目投入上都是有預算的，在成本有上限的前提下，項目的功能設計（軟件的成熟度）方面必然受一定影響，畢竟功能越多越完善，相應的開發成本就越高。這種功能上的不完善需要事先告知客戶并得到理解。f)此項工作的反復造成思想上的倦怠，使需求分析最后虎頭蛇尾。需求分析是一項繁瑣枯燥的工作，需要和客戶之間不斷的商討、確認和反復，另外由于大部分的客戶雖然安排專人負責這項工作，但是該人并不只做這項工作，特別當他被很多其他的事情纏身的時候，而無心細看提交過去的需求報告的時候，他很可能會給你一個錯覺，讓你認為他已經真正的理解并認可了你的設計。結論 a)需求分析是整個項目管理中需要重點控制的幾個關鍵節點之一，首先思想上一定要重視。b)需求分析報告的編寫者要參與到需求的搜集工作中，準確領會客戶的意圖，并轉化成軟件能夠實現的功能。對于說不清楚需求的客戶，要善于問關鍵問題，引導客戶提出自己的需求。可以采取的措施是事先編制一個問卷調查之類的文檔，詳細列舉需要客戶回答的問題，以便防止遺漏。c)需求報告的編寫者要能夠對客戶需求進行深入分析，區別出哪些需求存在日后變更的可能，哪些需求屬于相對固定的，哪些需求能夠實現，哪些需求需要變通才能實現，以便于指導后面的功能設計。d)需求分析報告對功能細節的描述不能有歧義，描述一定要全面、準確，防止開發方和客戶只見對同一個問題有兩個截然不同的理解。可以通過評審，用大家的力量來避免這種情況發生 e)需求報告的每個關乎功能的描述都要讓客戶明白和理解，客戶在理解之上的確認才能夠保證日后一旦出現問題不致出現雙方互相推托責任糾纏不清的情況。f)需求報告一定要經過一個有技術人員和業務人員參加的評審，要充分發揮團隊的力量，重視每個人的才智，一個模塊一個功能的逐一的過，讓大家來共同找出需求報告里不合理的、有歧義的、不完善的、遺漏的等等問題 g)幫助客戶去理解提交給他的需求分析報告而不是只等簽字，對于有能夠用好幾種方式實現的功能，盡量做到能讓客戶去比較和選擇。不要讓客戶對報告中的部分產生歧義。只有客戶對報告的完全的理解，才能在日后客戶提出的修改被認為是需求變更的時候能夠得到客戶的理解 h)最后，需求分析報告一定要雙方共同簽字確認。