軟件需求分析習(xí)題匯編

1、習(xí)題集一、單項選擇題1、需求分析最終結(jié)果是產(chǎn)生（）。A .項目幵發(fā)計劃B .可行性分析報告 C .需求規(guī)格說明書 D .設(shè)計說明書答案： C2、需求分析中，開發(fā)人員要從用戶那里解決的最重要的問題是（）。A .讓軟件做什么B.要給軟件提供哪些信息C .要求軟件工作效率怎樣D.讓軟件具有何種結(jié)構(gòu)答案： A3、需求規(guī)格說明書的內(nèi)容不應(yīng)包括對（）的描述。A .主要功能B .算法的詳細(xì)過程 C .用戶界面和運(yùn)行環(huán)境 D .軟件性能答案： B4、 需求規(guī)格說明書的作用不應(yīng)包括（）。A .軟件設(shè)計的依據(jù)B.用戶與開發(fā)人員對軟件要做什么的共同理解C .軟件驗收的依據(jù)D.軟件可行性研究的依據(jù)答案： D5、 下面

2、關(guān)于面向?qū)ο蠓椒ㄖ邢⒌臄⑹?，不正確的是（）。A .鍵盤、鼠標(biāo)、通信端口、網(wǎng)絡(luò)等設(shè)備一有變化，就會產(chǎn)生消息B. 操作系統(tǒng)不斷向應(yīng)用程序發(fā)送消息，但應(yīng)用程序不能向操作系統(tǒng)發(fā)送消息C. 應(yīng)用程序之間可以相互發(fā)送消息D .發(fā)送與接收消息的通信機(jī)制與傳統(tǒng)的子程序調(diào)用機(jī)制不同答案： B 6、面向?qū)ο蠹夹g(shù)中， 對象是類的實例。 對象有三種成份：（ ）、屬性和方法 （ 或 操作）。A. 標(biāo)識 B. 規(guī)則 C. 封裝 D. 消息答案： A7、軟件需求分析階段的工作，可以分成以下四個方面：對問題的識別、分析與綜合、制定規(guī)格說明以及（）。A 總結(jié)實踐性報告C 需求分析評審以上答案都不正確答案 :C 8、軟件需求規(guī)

3、格說明書的內(nèi)容不應(yīng)包括對（ ）的描述。A 主要功能 B 算法的詳細(xì)過程C 用戶界面及運(yùn)行環(huán)境 D 軟件的性能答案 :B9、產(chǎn)品特性可以稱為質(zhì)量屬性，在眾多質(zhì)量屬性中，對于開發(fā)人員來說重要的屬 性有哪些（ B ）A 有效性、效率、靈活性、互操作性B 可維護(hù)性、可移植性、可重用性、可測試性C 完整性、可靠性、健壯性、可用性D 容錯性、易用性、簡潔性、正確性 10、需求包括 11 個方面的內(nèi)容，其中網(wǎng)絡(luò)和操作系統(tǒng)的要求屬于（ B ），如何隔 離用戶之間的數(shù)據(jù)屬于（C）,執(zhí)行速度、相應(yīng)時間及吞吐量屬于（D ）,規(guī)定系統(tǒng) 平均出錯時間屬于（ A ）。A 質(zhì)量保證 B 環(huán)境需求 C 安全保密需求 D 性能

4、需求11、需求分析過程應(yīng)該建立 3 種模型，它們分別是數(shù)據(jù)模型、功能模型、行為模型。以下幾種圖形中，（B ）屬于功能模型，（A ）屬于數(shù)據(jù)模型，（C）屬于行為 模型。A 實體 - 聯(lián)系圖 （ERD） B 數(shù)據(jù)流圖 （DFD） C 狀態(tài)轉(zhuǎn)換圖 （STD） D 魚 骨圖12、 常用的需求分析方法有：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（SA）,面向?qū)ο蟮姆?析方法（00A，下列（D）不是結(jié)構(gòu)化分析方法的圖形工具。A 決策樹 B 數(shù)據(jù)流圖 C 數(shù)據(jù)字典 D 快速原型13、軟件開發(fā)中，原型是軟件的一個早期可運(yùn)行的版本，它反映最終系統(tǒng)的部分重要特性。其中，（B ）和（C ）用完就可以丟棄，而（A）圍繞原型修改、增

5、加。A 進(jìn)化型 B 探索型 C 實驗型 D 以上都是14、（ D）用于描述數(shù)據(jù)的處理過程。A 數(shù)據(jù)字典 B 決策樹 C 決策表 D 數(shù)據(jù)流圖15、DFD的基本符號不包括下列哪種（A）A 數(shù)據(jù)字典 B 加工 C 外部實體 D 數(shù)據(jù)流 E 數(shù)據(jù)存儲文件16、DD的主要字典條目包括以下哪種（E）A 數(shù)據(jù)流 B 文件 C 數(shù)據(jù)項 D 加工 E 以上都是17、 常用的動態(tài)分析方法不包括以下哪種（ B）A 狀態(tài)遷移圖 B 層次方框圖 C 時序圖 D Petri 網(wǎng)18、需求分析階段的文檔包括以下哪些（ E ）A 軟件需求規(guī)格說明書 B 數(shù)據(jù)要求說明書 C 初步的用戶手冊 D 修改、 完善與確定軟件開發(fā)實施

6、計劃 E 以上都是19、需求驗證應(yīng)該從下述幾個方面進(jìn)行驗證： （ C ）A 可靠性、可用性、易用性、重用性 B 可維護(hù)性、可移植性、可重用性、可 測試性C 一致性、現(xiàn)實性、完整性、有效性 D 功能性、非功能性20、風(fēng)險管理的要素包括哪項（ D）A 風(fēng)險評價 B 風(fēng)險避免 C 風(fēng)險控制 D 以上都是21、下列描述中錯誤的是（ D）A 每一個集成的需求變更必須能跟蹤到一個經(jīng)核準(zhǔn)的變更請求。B 變更過程應(yīng)該做成文檔，盡可能簡單，當(dāng)然首要的是有效性。C 所有需求變更必須遵循過程， 按照此過程， 如果一個變更需求未被采納， 則 其后過程不再予以考慮。D 可以從數(shù)據(jù)庫中刪除或修改變更請求的原始文檔。二、填

7、空題1、需求分析階段產(chǎn)生的最重要的文檔是（ 需求分析說明書 ）。2、需求分析的主要任務(wù)是 （ 要回答“軟件必須做什么 ?” ） 。3、需求分析階段，分析人員要確定對問題的綜合需求，其中最主要的是（功能） 需求。4、需求分析階段研究的對象是軟件項目的（ 用戶要求 ）。5、軟件生命周期：問題定義、可行性研究、需求分析、總體設(shè)計、詳細(xì)設(shè)計、編 碼和單元測試、綜合測試、軟件維護(hù) 6、信息系統(tǒng)必須實現(xiàn)的功能，或者說信息系統(tǒng)必須具備的屬性和質(zhì)量稱為（系統(tǒng) 需求（需求） ）。7、（模型）是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的 書面描述。通常，由一組圖形符號和組織這些符號的規(guī)則組成。8、

8、軟件需求分析階段的目的是澄清用戶的要求，并把雙方共同的理解明確地表達(dá) 成一份書面文檔（軟件需求規(guī)格說明書） 。9、軟件需求分類，分為（功能性）需求和（非功能性）需求。10、需求分析的步驟包括（需求獲?。ⅲǚ治鼋?）、文檔編寫、需求驗證。11、魚骨圖是一種用于確定、探索和描述問題及其原因和結(jié)果的圖形工具，又被 稱為（因果圖） 。12、大多數(shù)的需求分析方法是由信息驅(qū)動的， 信息域具有三種屬性： （信息流）、（信 息內(nèi)容）和信息結(jié)構(gòu)。13、在軟件開發(fā)中， 使用原型時可采取兩種不同的策略， 即：（廢棄 ）策略和（追 加）策略。三、名詞解釋1、需求分析：開發(fā)人員要準(zhǔn)確理解用戶的要求，進(jìn)行細(xì)致的調(diào)查分

9、析，將用戶非 形式的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)換到相應(yīng)的形式主義功 能規(guī)約 （需求規(guī)格說明 ）的過程。2、軟件需求： IEEE 軟件工程標(biāo)準(zhǔn)詞匯表中定義需求為： 用戶解決問題或達(dá)到目標(biāo) 所需的條件或權(quán)能；系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需具有的條件或權(quán)能；一種反映上面（1）或（ 2）所描述的條件或權(quán)能的文 檔說明。3、需求工程：整個軟件需求范圍內(nèi)所進(jìn)行的活動稱為需求工程，需求工程包括需 求開發(fā)和需求管理兩部分，需求開發(fā)包括問題獲取、分析、編寫規(guī)格說明和驗證。4、業(yè)務(wù)模型：業(yè)務(wù)模型是理解一個組織業(yè)務(wù)過程的技術(shù)?？梢杂脴I(yè)務(wù)用例模型和業(yè)務(wù)對象模型來表達(dá)業(yè)務(wù)模

10、型。業(yè)務(wù)用例模型是分別從與業(yè)務(wù)過程和客戶對應(yīng)的 業(yè)務(wù)用例和業(yè)務(wù)參與者的角度來描述企業(yè)的業(yè)務(wù)過程；業(yè)務(wù)對象模型描述了如何 由一組工作人員使用一些業(yè)務(wù)實體和工作單元來實現(xiàn)每個業(yè)務(wù)用例。5、原型開發(fā)方法：一個軟件原型是所提出的新產(chǎn)品的部分實現(xiàn)，使用原型有三個 主要目的： 1）明確并完善需求， 2）探索設(shè)計選擇方案， 3）發(fā)展成為最終的產(chǎn)品 建立原型的主要原因是為了解決在產(chǎn)品開發(fā)的早期階段不確定的問題。原型可分 為拋棄型原型和進(jìn)化型原型。6、數(shù)據(jù)字典：一個定義應(yīng)用程序中使用的所有數(shù)據(jù)元素和結(jié)構(gòu)的含義、類型、數(shù) 據(jù)大小、格式、度量單位、精度以及允許取值范圍的共享倉庫。四、簡答題1、生命周期模型是什么？常

11、見的生命周期模型有哪幾種？ 答：對軟件開發(fā)流程的一種描述；為解決問題所定義的策略；對典型開發(fā)活動的 抽象。常見的生命周期模型： Waterfall,Prototyping,Phased,Spiral.2、為什么要使用生命周期模型？答：幫助開發(fā)組了解他們在開發(fā)項目中的活動、資源和限制；幫助項目了解在開發(fā)過程中的不一致，丟失，冗余等情況，把注意力集中在開發(fā)最終的產(chǎn)品上；幫3、Waterfall 的優(yōu)勢是什么？ 答：具有良好定義的里程碑；利于向不熟悉軟件開發(fā)的客戶講解流程；幫助開發(fā)人員理解需要做的事情；清楚地描述下階段開始前需要的中間產(chǎn)品；是很多其他LC模型的基礎(chǔ)。4、需求分析階段的基本任務(wù)是什么？

12、答：需求分析階段的基本任務(wù)是 :（1）. 問題識別：雙方對問題的綜合需求： a. 功能需求 b. 性能需求 c. 環(huán)境需求 d. 用戶界面需求 .（2）. 分析與綜合，導(dǎo)出軟件的邏輯模型 .（3）. 編寫文檔五、問答題1、軟件過程的概念及分類，基本過程包含些什么及每個過程的具體內(nèi)容。 答：軟件過程也稱為軟件生存周期過程或軟件過程組，是指軟件生存周期中的一 系列相關(guān)過程。過程就是活動的集合，活動是任務(wù)的集合，任務(wù)則起到把輸入加 工成輸出的作用?；顒拥膱?zhí)行可以是順序的 、迭代的（重復(fù)的） 、并行的、嵌套 的或是有條件引發(fā)的。軟件過程可以分為三類：基本過程、支持過程和組織過程。基本過程包括：1 ）獲

13、取過程：（項目委托方）確定需求；招標(biāo)；簽訂合同；對供應(yīng)方的監(jiān)督； 驗收完成。2 ）供應(yīng)過程： （項目承包方）理解需求；投標(biāo)；簽訂合同；計劃；實施；控 制；評審評價；交付。3 ）開發(fā)過程：（軟件開發(fā)人員）過程實施準(zhǔn)備；系統(tǒng)需求分析；系統(tǒng)結(jié)構(gòu)設(shè) 計；軟件需求分析；軟件體系結(jié)構(gòu)設(shè)計；軟件詳細(xì)設(shè)計；軟件編碼和測試；軟件 集成；軟件合格測試；系統(tǒng)集成；系統(tǒng)合格測試；軟件安裝；驗收支持。4 ）運(yùn)行過程： （用戶）運(yùn)行準(zhǔn)備；運(yùn)行測試；產(chǎn)品轉(zhuǎn)移；運(yùn)行；運(yùn)行支持； 運(yùn)行評價。5 ）維護(hù)過程：（維護(hù)人員）過程實施準(zhǔn)備；問題分析和修改設(shè)計；修改實施； 對維護(hù)的評審和驗收；軟件移植；軟件退役。2、簡述軟件需求工程分為

14、哪幾類？其中需求獲取和需求規(guī)約目的和任務(wù)。 答：軟件需求工程細(xì)分為：需求獲取、需求分析與協(xié)商、系統(tǒng)建模、需求規(guī)約、 需求驗證和需求管理六個階段。需求獲?。合到y(tǒng)分析人員通過與用戶的交流、對現(xiàn)有系統(tǒng)的觀察及對任務(wù)進(jìn) 行分析，確定系統(tǒng)或產(chǎn)品范圍的限制性描述、與系統(tǒng)或產(chǎn)品有關(guān)的人員及特征列 表、系統(tǒng)的技術(shù)環(huán)境的描述、系統(tǒng)功能的列表及應(yīng)用于每個需求的領(lǐng)域限制、一 組描述不同運(yùn)行條件下系統(tǒng)或產(chǎn)品使用狀況的應(yīng)用場景以及為更好地定義需求而 開發(fā)的任意原型。需求獲取的工作產(chǎn)品為進(jìn)行需求分析提供了基礎(chǔ) , 為后期開發(fā)設(shè)計人員提供需求 分析報告。需求規(guī)約：軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、

15、詳細(xì)的功能和行為描述、性能需求和設(shè)計約束的說明、合適的驗收標(biāo)準(zhǔn)，給出對 目標(biāo)軟件的各種需求。需求規(guī)約作為用戶和開發(fā)者之間的一個協(xié)議，在之后的軟件工程各個階段發(fā)揮重 要作用。答：軟件體系結(jié)構(gòu)：軟件體系結(jié)構(gòu)是具有一定形式的結(jié)構(gòu)化元素，即構(gòu)件的集合， 包括處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件。處理構(gòu)件負(fù)責(zé)對數(shù)據(jù)進(jìn)行加工，數(shù)據(jù)構(gòu)件 是被加工的信息，連接構(gòu)件把體系結(jié)構(gòu)的不同部分組組合連接起來。B/S 結(jié)構(gòu)：瀏覽器（客戶機(jī)）一一 WE冋艮務(wù)器一一數(shù)據(jù)庫服務(wù)器B/S 體系結(jié)構(gòu)的實現(xiàn)方式： B/S 模式下的客戶機(jī)只需安裝瀏覽器軟件，無須開 發(fā)前端應(yīng)用程序；中間層的 Web應(yīng)用服務(wù)器，主要的數(shù)據(jù)計算和應(yīng)用都在此完成，

16、因此對中間層服務(wù)器的要求較高；后臺數(shù)據(jù)庫服務(wù)器主要完成數(shù)據(jù)的管理。4、用戶界面設(shè)計三個的任務(wù)和目的。答：用戶界面設(shè)計在工作流程上分為結(jié)構(gòu)設(shè)計、交互設(shè)計、視覺設(shè)計三個部分。1 ）結(jié)構(gòu)設(shè)計：結(jié)構(gòu)設(shè)計也成概念設(shè)計 ?，是界面設(shè)計的骨架。通過對用戶研究和 任 務(wù) 分 析 ， 制 定 出 產(chǎn) 品 的 整 體 架 構(gòu) 。 基 于 紙 質(zhì) 的 的 低 保 真 原 型 （ Paper?Prototype ）可提供用戶測試并進(jìn)行完善。在結(jié)構(gòu)設(shè)計中，目錄體系的邏 輯分類和語詞定義是用戶易于理解和操作的重要前提。2 ）交互設(shè)計：交互設(shè)計的目的是使產(chǎn)品讓用戶能簡單使用。?任何產(chǎn)品功能的實現(xiàn)都是通過人和機(jī)器的交互來完成

17、的。因此，人的因素應(yīng)作為設(shè)計的核心被體 現(xiàn)出來。3 ）視覺設(shè)計：在結(jié)構(gòu)設(shè)計的基礎(chǔ)上，參照目標(biāo)群體的心理模型和任務(wù)達(dá)成進(jìn) 行視覺設(shè)計。包括色彩、字體、頁面等。視覺設(shè)計要達(dá)到用戶愉悅使用的目的。5、需求規(guī)格說明文檔的作者及表現(xiàn)手段。答：作者：項目管理者：組織安排、提供條件需求工程師：負(fù)責(zé)人、主導(dǎo)人 文檔寫作人員：有時會采用，節(jié)省需求工程師的時間 涉眾（用戶）：驗證人表現(xiàn)手段：非形式化：自然語言、限制性文本 半形式化：結(jié)構(gòu)化文本（偽碼 / 結(jié)構(gòu)化英語）、模型語言（圖、表） 形式化：形式化語言（數(shù)學(xué)語言： BNF）6、數(shù)據(jù)庫設(shè)計的內(nèi)容及常用方法。 答：數(shù)據(jù)庫設(shè)計包括數(shù)據(jù)庫的結(jié)構(gòu)設(shè)計和數(shù)據(jù)庫的行為設(shè)計。

18、1 ）數(shù)據(jù)庫的結(jié)構(gòu)設(shè)計 數(shù)據(jù)庫的結(jié)構(gòu)設(shè)計指是根據(jù)給定的應(yīng)用環(huán)境，進(jìn)行數(shù)據(jù)庫的模式或子模式的 設(shè)計。 它包括數(shù)據(jù)庫的概念設(shè)計、邏輯設(shè)計和物理設(shè)計。數(shù)據(jù)庫模式是各應(yīng) 用程序共享的結(jié)構(gòu)，是靜態(tài)的、穩(wěn)定的，一經(jīng)形成后通常情況下是不容易改變的， 所以結(jié)構(gòu)設(shè)計又稱為靜態(tài)模型設(shè)計。2 ）數(shù)據(jù)庫的行為設(shè)計 數(shù)據(jù)庫的行為設(shè)計是指確定數(shù)據(jù)庫用戶的行為和動作。而在數(shù)據(jù)庫系統(tǒng)中， 用戶的行為和動作指用戶對數(shù)據(jù)庫的操作，這些要通過應(yīng)用程序來實現(xiàn)，所以數(shù) 據(jù)庫的行為設(shè)計就是應(yīng)用程序的設(shè)計。 用戶的行為總是使數(shù)據(jù)庫的內(nèi)容發(fā)生變化， 所以行為設(shè)計是動態(tài)的，行為設(shè)計又稱為動態(tài)模型設(shè)計。數(shù)據(jù)庫常用設(shè)計方法：直觀設(shè)計法、規(guī)范設(shè)計法

19、、計算機(jī)輔助設(shè)計法、自動 化設(shè)計法。7、如何正確看待客戶？答：即使最終用戶不是上帝，也算是“上帝”的“親戚” ，同樣怠慢不得。如果項目規(guī)模比較大，那么開發(fā)方與最終用戶的來往就比較多。如從最終用 戶那里獲取詳細(xì)的需求，請最終用戶試驗軟件，對最終用戶進(jìn)行培訓(xùn)等等。8、概括說明如何進(jìn)行需求分析？答: （1）需求分析是指在需求開發(fā)過程中，對所獲取的需求信息進(jìn)行分析，及時 排除錯誤和彌補(bǔ)不足，確保需求文檔正確地反映用戶的真實意圖。（2）分析方法大體有兩類： “問答分析法”和“建模分析法” 。第一：問答分析方法很簡單：刨根究底地問，如果問題都被解答了，那么需求 也就分析清楚了。一個人可以“自問自答”地分析

20、需求，幾個人分析需求則稱為 “研討”。 問答分析最重要的問題是： “是什么”和“為什么” 。其它常見的問題 有： 需求存在二義性嗎？ 需求文檔的上下文有矛盾嗎？ 需求完備嗎？ 需求是 必要的嗎？ 需求可實現(xiàn)嗎？需求可驗證嗎？ 需求的優(yōu)先級確定了嗎？第二：建模分析法：在需求開發(fā)過程中，對于某些類型的信息，用圖形表示 要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。 需求建模就是指用圖形符號來表示、刻畫需求。需求建模不可能取代文字描述。 在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將 模型存放在需求文檔的附錄中，便于正文引用。建模分析方法主要有兩大類：

21、 “結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā?。9、概括說明什么是好的需求規(guī)格說明書？答：第一 ; 正確 需求規(guī)格說明書應(yīng)當(dāng)正確地反映用戶的真實意圖， “正確” 是產(chǎn) 三： 無二義性 “無二義性” 是指每個需求只有唯一的含義。第四：一致 “一 致”( Consistent )是指產(chǎn)品需求規(guī)格說明書中各個需求之間不會發(fā)生矛盾。 第五 ：必要 產(chǎn)品需求規(guī)格說明書 中的各項需求對用戶而言應(yīng)當(dāng)都是必要的。 第六：完備“完備”(Complete)是指產(chǎn)品需求規(guī)格說明書中沒有遺漏一些 必要的需求。第七 ：可實現(xiàn) 產(chǎn)品需求規(guī)格說明書中的各項需求對開發(fā)方而 言應(yīng)當(dāng)都是可實現(xiàn)的( Attainable )。第八： 可

22、驗證 產(chǎn)品需求規(guī)格說明書中 的各項需求對用戶方而言應(yīng)當(dāng)都是可驗證的( Verifiable )。如果需求是不可驗證 的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。 第九： 確定優(yōu)先級 需求 的優(yōu)先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三 級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。 第十 ：闡述“做什么” 而不是“怎么做” 產(chǎn)品需求規(guī)格說明書的重點(diǎn)是闡述“做什么” ，而不是闡 述“怎么做”?！霸趺醋觥笔窍到y(tǒng)設(shè)計和實現(xiàn)階段的事情。品需求規(guī)格說明書最重要的屬性。第二：清楚 清楚的需求讓人易讀易懂。 第10、如何定義產(chǎn)品說明書？ 答：第一步：細(xì)化并分析用戶需求需求分析員

23、首先對用戶需求說明書進(jìn)行細(xì)化，對比較復(fù)雜的用戶需求進(jìn) 行建模分析，以幫助軟件開發(fā)人員更好地理解需求。例如采用 Rational 的 Rose 工具進(jìn)行需求的建模分析，建模分析產(chǎn)生的文檔可以作為產(chǎn)品需求規(guī)格說明書 的附件。補(bǔ)充說明：建模分析的技術(shù)難度比較高，需求分析員應(yīng)當(dāng)根據(jù)自身水平 進(jìn)行取舍。第二步：撰寫產(chǎn)品需求規(guī)格說明書需求分析員按照指定的文檔模板撰寫產(chǎn)品需求規(guī)格說明書 。如果待開發(fā)的 產(chǎn)品分為軟件和硬件兩部分的話，則應(yīng)當(dāng)撰寫軟件需求規(guī)格說明書和硬件 需求規(guī)格說明書 。 第三步：進(jìn)行需求確認(rèn)項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審產(chǎn)品需求 規(guī)格說明書，盡最大努力使產(chǎn)品需求規(guī)格

24、說明書能夠正確無誤地反映用戶的 真實意愿。 需求評審之后，開發(fā)方和客戶方的責(zé)任人對產(chǎn)品需求規(guī)格說明書作書面承諾。11、需求說明書由哪些部分組成？各部分之間的關(guān)系是什么？ 答：軟件需求說明書一般包括如下內(nèi)容：1 ）引言部分 編寫目的；項目背景 （ 應(yīng)包括： a. 項目的委托單位、開發(fā)單 位和主管部門；b.該軟件系統(tǒng)與其他系統(tǒng)的關(guān)系。 ）；定義；（列出文檔中所用 到的專門術(shù)語的定義和縮寫詞的原文。 ） 參考資料。2 ）任務(wù)概述目標(biāo)；運(yùn)行環(huán)境；條件與限制。3 ）數(shù)據(jù)描述靜態(tài)數(shù)據(jù)；動態(tài)數(shù)據(jù) （ 包括輸入數(shù)據(jù)和輸出數(shù)據(jù) ） ；數(shù)據(jù)庫描述 （ 給出使用數(shù)據(jù)庫的名稱和類型 ） ；數(shù)據(jù)詞典；數(shù)據(jù)采集。4 ）功

25、能要求 功能劃分；功能描述。5 ）性能需求 數(shù)據(jù)精確度；時間特性 （ 如響應(yīng)時間、更新處理時間、數(shù)據(jù)轉(zhuǎn) 換與傳輸時間、運(yùn)行時間等 ） ；適應(yīng)性 （ 在操作方式、運(yùn)行環(huán)境、與其他軟件的接 口以及開發(fā)計劃等發(fā)生變化時，應(yīng)具有的適應(yīng)能力。 ）6 ）運(yùn)行需求 用戶界面 （如屏幕格式、報表格式、菜單格式、輸入輸出時間 等） ；硬件接口；軟件接口；故障處理。7 ）其他要求 如可使用性、安全保密、可維護(hù)性、可移植性等。8 ）附錄。12、簡述優(yōu)秀軟件需求所應(yīng)具有的特性 答：優(yōu)秀需求所具有的特性：完整性，正確性，可行性，必要性，劃分優(yōu)先級， 無二義性，可驗證性。13、什么是軟件需求開發(fā)，軟件需求開發(fā)要做哪些工作

26、？ 答：軟件需求開發(fā)分為：問題獲取、分析、編寫規(guī)格說明和驗證四個階段。包括 軟件類產(chǎn)品中需求收集、評價、編寫文檔等所有活動。包括以下幾個方面： 確定產(chǎn)品所期望的用戶類。獲取每個用戶類的需求。了解實際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。將系統(tǒng)級的需求分為幾個子系統(tǒng)，并將需求中的一部分分配給軟件組件。了解相關(guān)質(zhì)量屬性的重要性。商討實施優(yōu)先級的劃分。將所收集的用戶需求編寫成規(guī)格說明和模型。評審需求規(guī)格說明，確保對用戶需求達(dá)到共同的理解與認(rèn)識，并在整個開 發(fā)小組接受說明之前將問題都弄清楚。14、什么是軟

27、件需求管理，軟件需求管理的主要活動有哪些？ 答：需求管理包括在工程進(jìn)展過程中維持需求約定集成性和精確性的所有活動， 包括：變更控制，版本控制，需求跟蹤和需求狀態(tài)跟蹤。15、試論述用例（ USE CAS）E 在軟件需求分析中的地位與作用？ 答：用例描述了系統(tǒng)和一個外部 ACTOR勺交互順序，用例表達(dá)了系統(tǒng)的功能需求 在表達(dá)系統(tǒng)需求時，用用例圖、用例的腳本說明和詞匯表等要素來表達(dá)系統(tǒng)功能 需求，補(bǔ)充規(guī)約來表達(dá)系統(tǒng)的非功能需求。16、在開發(fā)一個軟件系統(tǒng)時，要獲取哪些方面的需求？如何綜合利用各種表達(dá)工 具有效、全面的表達(dá)軟件的需求？ 答：軟件需求包括功能需求、非功能需求，功能需求由用戶需求和系統(tǒng)需求轉(zhuǎn)

28、化 而成，非功能需求包括質(zhì)量屬性、約束條件和其他非功能需求。用用例模型（用例圖、用例規(guī)約）表達(dá)系統(tǒng)功能需求；補(bǔ)充規(guī)約表達(dá)系統(tǒng)非功能需求；ER圖與數(shù)據(jù)字典可以表達(dá)系統(tǒng)數(shù)據(jù)需求；數(shù)據(jù)流圖（DFD可以表達(dá)系統(tǒng)的功能需求；PETR I網(wǎng)、狀態(tài)圖可以表達(dá)系統(tǒng)的實時性需求。六、分析題1、在下面的描述中，辨識參與者（ACTOR和用例（USECASE，并畫出一個用例 圖。在醫(yī)生的辦公室里，接待員、護(hù)士和醫(yī)生使用病人記錄和計劃安排系統(tǒng)。當(dāng) 病人第一次來這里看病時，接待員使用該系統(tǒng)來輸入病人信息，并且他們安排所 有的預(yù)約。護(hù)士使用系統(tǒng)來跟蹤病人每次看病的結(jié)果并輸入護(hù)理病人的信息，如 醫(yī)療和診斷。護(hù)士也可訪問這些信

29、息以打印病人診斷結(jié)果或病人看病歷史。醫(yī)生 主要用這個系統(tǒng)來查看病人的病史，偶爾也輸入病人醫(yī)療信息，但通常他讓護(hù)士 輸入這些信息。解：2、以下是一個簡化的網(wǎng)上購物系統(tǒng)的描述：該系統(tǒng)有 3 類用戶：游客、用戶、管理員。 管理員管理商品類別、商品、 用戶、訂單等基本信息。用戶可以對商品進(jìn)行瀏覽、查詢，可以把中意的商品放 進(jìn)購物車，并可以對購物車進(jìn)行管理，最后可以進(jìn)行結(jié)算下訂單，可以登錄個人 用戶中心，管理個人相關(guān)信息。游客可以對商品進(jìn)行瀏覽、查詢，把中意的商品 放進(jìn)購物車，可以對購物車進(jìn)行管理，但是下訂單前需要進(jìn)行登錄。請同學(xué)們按自己的情況在 （一）和（ 二） 之間選擇作答。（一）用用例圖描述本系統(tǒng)

30、的功能需求； 繪出該系統(tǒng)的主要實體類關(guān)聯(lián)圖 （類 要給出主要屬性） 。（二）（1）用頂層數(shù)據(jù)流圖和中層數(shù)據(jù)流圖 （ 頂層的下一層 ）描述本系統(tǒng)的功 能需求；（2）繪出該系統(tǒng)的實體 -關(guān)系圖 （要給出主要屬性 ）。3、圍繞本學(xué)期你在工作室開發(fā)的項目， 從需求工程角度展開論述 （不少于 800 字）。4、根據(jù)下列描述，說明新的直接銷售和財務(wù)處理系統(tǒng)的業(yè)務(wù)需求有哪些？Especially for You Jewelers 是大學(xué)城的一個小珠寶零售商。在過去的兩年 里， Especially for You在它的商業(yè)方面經(jīng)歷了極大的發(fā)展，可是，它的財務(wù)業(yè)績卻與它的發(fā)展不同步?，F(xiàn)在的事務(wù)處理系統(tǒng)部分手動

31、、部分自動，不能有效的 追蹤客戶賬單和收據(jù)， Especially for You 難以確定為什么它的成本這么高。此 外， Especially for You頻繁地實行特價以吸引顧客。它不知道這些特價是否有利可圖，是否帶來其他的銷售。 Especially for You 也想增加回頭客，所以它需 要一個客戶數(shù)據(jù)庫。 Especially for You 想按照一個新的直接銷售和財務(wù)處理系 統(tǒng)以幫助解決這些問題。5、設(shè)想你自己就是 ATM機(jī)的唯一用戶:a）寫出你對ATM機(jī)系統(tǒng)的用戶需求b）嘗試將用戶需求轉(zhuǎn)換為系統(tǒng)（級）需求c）除了功能性需求之外，還有哪些需求需要定義？請你一一寫出這些需求。6

32、、職工福利和工資顧問遇到了一些問題。 她的工作是為雇員提供他們的福利建議。 公司剛剛磋商了一個新的醫(yī)療保險方案，這個方案要求雇員從 7 個保健組織和首 選的供應(yīng)商方案中進(jìn)行選擇。保健組織和供應(yīng)商按照雇員的分類、貢獻(xiàn)、免賠額、 受益人、服務(wù)內(nèi)容和允許的服務(wù)提供商而各不相同，目的是盡可能為雇員提供最 靈活的福利，用以使公司的花費(fèi)極小化并控制付給保險商的費(fèi)用（這將對公司被 收取的后續(xù)保險費(fèi)產(chǎn)生一定的影響） 。這個顧問被請來為雇員選擇最合適的保險方案。她目前以手工方式答復(fù)這些 請求。但目前的選擇比新計劃中的選擇要直接得多。她需要解釋新的選擇：它們 包括什么，不包括什么，它們的費(fèi)用和可能費(fèi)用是多少，具有

33、什么優(yōu)缺點(diǎn)。但是， 雇員對新計劃不信任，這種情況迫使她需要向雇員提供更多具體的建議和答復(fù)。她可能不得不為許多雇員逐步建立假定情境可能的最壞假定情境。這種 假定將要根據(jù)每個雇員的收入、婚姻和家庭狀況、目前的健康風(fēng)險等進(jìn)行個人定 制。在逐步建立一些樣本假定時，她發(fā)現(xiàn)： （ 1）從信息系統(tǒng)部門獲得工資和個人 數(shù)據(jù)需要一天時間。 （ 2）雇員數(shù)據(jù)存儲在許多文件夾中，而且并不總是被正確地 更新。當(dāng)沖突數(shù)據(jù)變得很明顯時，除非解決了矛盾，否則就不可能繼續(xù)她的工作。 （3）計算復(fù)雜。為一個雇員創(chuàng)建投資和退休假定常常需要花費(fèi)一整天或更長時間。 （4）有些人擔(dān)心保險計劃會被提供給未授權(quán)的個人，例如以前的配偶或者非

34、直系 親屬。（5）計算中可變條件的復(fù)雜性導(dǎo)致經(jīng)常出錯，很多錯誤可能一直未被發(fā)現(xiàn)。假設(shè)現(xiàn)在需要你來開發(fā)一個軟件，解決職工福利和工資顧問的問題。那么你 認(rèn)為她現(xiàn)在遇到的問題有哪些？你希望新的軟件應(yīng)該達(dá)成哪些業(yè)務(wù)目標(biāo)？你怎樣設(shè)計軟件的高層解決方案和系統(tǒng)特性？解決方案有哪些重要的約束？7、Rolland 實業(yè)公司擁有著自己的軟件開發(fā)部門 IS 部門，負(fù)責(zé)為公司完成各 種信息系統(tǒng)的開發(fā)。現(xiàn)在， IS 部門給 Rolland 公司的部門結(jié)構(gòu)重組帶來了難題。非 IS 部門的管理人員正施加壓力，要求實施一種新的組織結(jié)構(gòu)，其中大部分 需求工程師將直接向他們的業(yè)務(wù)用戶組（例如會計、財務(wù)、生產(chǎn)）匯報工作，而 不是向

35、 IS 部門匯報工作。非 IS 部門的管理人員認(rèn)為：在目前的結(jié)構(gòu)下，由于需 求工程師向信息服務(wù)部門匯報工作，所以為了方法計算處理，他們往往希望“改 變每一件事情” 。為了保證系統(tǒng)能夠滿足 IS 的標(biāo)準(zhǔn)，非 IS 部門的管理人員同意在 IS 部門保留一個需求工程師小組，他們對所有的系統(tǒng)項目具有最終的決定權(quán)。IS 部門的經(jīng)理們正抵制這種變化。他們認(rèn)為：需求工程師如果離開 IS 部門， 將會在技術(shù)上“走入歧途” ；將需求工程師彼此分開會減少他們的思想交流，最終 難以創(chuàng)新；數(shù)據(jù)文件和程序會產(chǎn)生不必要的重復(fù)；由于程序員仍屬于 IS 部門，需 求工程師和程序員的沖突將會增加。在這個問題上，需求工程師分成了

36、兩個陣營，他們明白用戶更直接地控制其 系統(tǒng)的命運(yùn)的好處。然而，他們擔(dān)心當(dāng)遇到預(yù)算超支和技術(shù)延遲時，用戶和用戶 管理層將很難諒解。需求工程師還擔(dān)心，如果他們被重新分配到 IS 部門之外，遠(yuǎn) 離那些更側(cè)重于技術(shù)的同事，會導(dǎo)致他們技術(shù)的退化。關(guān)于此事的決策可能將由 IS 部門的上層決定。你認(rèn)為此事應(yīng)該如何處理？8、下面是系統(tǒng)分析團(tuán)隊的一名成員提出的第一份面談報告：“在我看來，面談進(jìn)行的很好。我和他就這個問題聊了一個半小時。他告訴我有關(guān)公司的所有歷史， 很有意思。他也提到，自他來到該公司的 16 年間，公司沒有任何變化。我們不久 將再次舉行會面，以及結(jié)束這次面談，因為我們還沒有深入研究我準(zhǔn)備的問題。1

37、）試評論這個面談報告。假設(shè)你要團(tuán)隊成員使用圖1提供的報表，那么他漏了什么主要信息？2）什么信息對面談報告來說是無關(guān)緊要的？3） 如果真的發(fā)生了報告中提及的情況，則必須向隊友提出哪3個建議, 助他更好地舉行下一次面談。面談對象：SalDomask日期：3月3日會見者：主題：計算機(jī)使用面談的目標(biāo)：找出關(guān)于計算機(jī)使用的態(tài)度；獲得用戶的使用估計；看最新建議的系統(tǒng)的觀點(diǎn)是否滿足目標(biāo)嗎？下次面談的目標(biāo)：找出Sal怎樣看待系統(tǒng)支持部門。找出下一個面談對象的觀點(diǎn)。面談的要點(diǎn)：Sal說道：“計算機(jī)是我的朋友?！薄耙恢薄倍荚谟糜嬎銠C(jī)。迫不及待地要熟悉新系統(tǒng)。會見者的觀點(diǎn)：對了解更對有關(guān)系統(tǒng)如何促進(jìn)工作感興趣。如果

38、不使用計算機(jī)進(jìn)行工作，會感到 枯燥。將成為新系統(tǒng)的熱情支持者/促進(jìn)者。以幫9、PhilIttup是 系統(tǒng) 分析 員團(tuán) 隊中 的一 員， 他受 委任 去與 組織 成員 面為系統(tǒng)研究收集材料。企業(yè)稱為 Fall Back 工業(yè)，它有 5 個管理層。此外，生產(chǎn)、 會計、營銷、系統(tǒng)、物流和高層管理是將受到所建議的系統(tǒng)影響的職能區(qū)域。每 個階層大約有 40 人。生產(chǎn)層共有 80 人，會計層有 35 人，營銷層有 42 人，系統(tǒng) 層有 10人，物流層有 28 人。高層管理有 5人。說明 Phil 應(yīng)該怎樣開展他的面談工作？包括：面談對象選擇的先后順序，每 次的面談結(jié)構(gòu)。說明原因。10、“我有一個絕妙的主意

39、！ ”Bea Kwicke 宣布，他是系統(tǒng)團(tuán)隊的一位新來的需求 工程師，“讓我們跳過所有的 SDLC垃圾，直接為一切設(shè)計原型。我們的項目會進(jìn) 展的更快，還可以節(jié)省時間和金錢，并且所有的用戶會感到我們似乎很在意他們， 而不是連續(xù)幾個月不與他們交談。 ”1 ）列出你（作為與 Bea同一個團(tuán)隊的成員）用來勸阻她不要試圖放棄SDLC而直接為所有項目設(shè)計原型的原因。2 ） Bea 對你所說的話很失望。為了鼓勵她，用一段話向她說明，你認(rèn)為適用 于原型化方法的情形。11、Ceci Awill說：“我想我能記得他所做過的大部分事情?！?Ceci準(zhǔn)備與OK C orral公司戰(zhàn)略規(guī)劃副總裁 Biff Webll

40、don進(jìn)行面談。OK C orral是一家擁有130 間牛排連鎖店的公司。 “我的意思是說，我有好的記性。我認(rèn)為聽他說什么比看他 做什么更重要。 ”作為需求工程團(tuán)隊的一員 ,Ceci Awll 向你訴說了他要寫下在面談中對 Biff 的辦公司和 Biff 的活動進(jìn)行觀察的愿望。1 ）用一段話來說服 Ceci ，在面談時僅僅傾聽是不夠的， 觀察和記錄所觀察的 內(nèi)容同樣是很重要的2 )Ceci 似乎接受了你認(rèn)為觀察時很重要的觀點(diǎn)， 但是不知道該觀察什么。 列 出需要觀察的項目和行為， 在每一項行為的旁邊用一句話指名 Ceci 通過觀察應(yīng)該 得到的信息。知識要點(diǎn)1、為什么軟件需求這么難？客戶說不清楚

41、需求需求自身經(jīng)常變動分析人員或客戶理解有誤2、軟件需求的定義軟件需求=業(yè)務(wù)知識+問題列表+其他因素。業(yè)務(wù)知識包括業(yè)務(wù)事件、業(yè)務(wù)實體和業(yè)務(wù)規(guī)則；問題列表是用戶在工作中遇到的 困難與障礙，這也是軟件開發(fā)中需要解決的問題；其他因素包括了一些設(shè)計約束 和非功能方面需求。3、需求的層次業(yè)務(wù)需求、用戶需求、軟件需求需求層次的產(chǎn)物 ：業(yè)務(wù)需求是需求定義的產(chǎn)物，用戶需求是需求捕獲的產(chǎn)物， 軟件需求是需求分析與建模的產(chǎn)物。4、軟件需求的三種類型功能需求：開發(fā)人員要實現(xiàn)什么非功能需求：對產(chǎn)品功能描述的補(bǔ)充設(shè)計約束：限制了開發(fā)人員設(shè)計和構(gòu)建系統(tǒng)時的選擇范圍5、軟件開發(fā)的各個階段，為什么只有需求階段稱為工程？需求工程

42、是隨著計算機(jī)的發(fā)展而發(fā)展的，在計算機(jī)發(fā)展的初期，軟件規(guī)模不大，軟件開發(fā)所關(guān)注的是代碼編寫，需求分析很少受到重視。后來軟件開發(fā)引入了生命周期的概念，需求分析成為其第一階段。隨著軟件系統(tǒng)規(guī)模的擴(kuò)大，需求分析與定義在整個軟件開發(fā)與維護(hù)過程中越來越重要，直接關(guān)系到軟件的成功與否。人們逐漸認(rèn)識到需求分析活動不再僅限于軟件開發(fā)的最初 階段，它貫穿于系統(tǒng)開發(fā)的整個生命周期。需求分析是介于系統(tǒng)分析和軟件設(shè)計階段之間的橋梁。一方面，需求分析以系統(tǒng)規(guī)格說明和項目規(guī)劃作為分析活動的基本出發(fā)點(diǎn)，并從軟件角度對它們進(jìn)行檢查與調(diào)整；另一方面，需求規(guī)格說明又是軟件設(shè)計、實現(xiàn)、測試直至維護(hù)的主要基礎(chǔ)。良好的分析活動有助于避免

43、或盡早剔除早期錯誤，從而提 高軟件生產(chǎn)率，降低開發(fā)成本，改進(jìn)軟件質(zhì)量。所以才只有需求成了工程！6、需求工程劃分為哪兩個部分需求開發(fā)、需求管理7、需求開發(fā)包括哪些內(nèi)容需求獲取、 需求分析、 需求規(guī)約（編寫需求規(guī)格說明書） 和需求驗證 （確認(rèn)）8、需求管理包括哪些內(nèi)容基線管理、變更管理和需求跟蹤9、如何評價需求的好與壞（優(yōu)秀需求的特點(diǎn)）完整性、正確性、可行性、有優(yōu)先次序、無歧義、可驗證性、確定性10 、客戶的含義廣義來講，客戶泛指直接或間接得益于產(chǎn)品的個人或組織。軟件的客戶包括那些提出軟件需求，購買、定義、使用軟件產(chǎn)品或選擇接受軟件功能的項目涉眾11 、 “簽字”的含義簽字是項目的一個里程碑，是建

44、立需求協(xié)議的基線。12 、需求定義階段的任務(wù)確定項目的宏觀需求。換句話說，就是定義項目的業(yè)務(wù)需求，也就是明確項目的目標(biāo)和范圍。13 、需求定義的理念目標(biāo)、問題、可選方案、建議方案14 、問題分析 5 步法在問題定義上達(dá)成共識、理解根本原因（也就是分析問題背后的問題） 、確定相關(guān)人員和用戶、定義解決方案的界限、確定加在解決方案上的約束15 、需求定義的產(chǎn)物根據(jù)項目類型的不同，需求定義的產(chǎn)物大致可以分為POS（ Project OverviewSpecify, 項目綜述）和 Vision（ 愿景 ） 兩大類。16 、需求定義的要素目標(biāo)、范圍、相關(guān)人員與用戶、相關(guān)事實與假設(shè)17 、一個好的目標(biāo)應(yīng)滿足

45、的原則（ SMART ）必須是具體（ Specific ）的：目標(biāo)必須能夠指導(dǎo)具體的工作 必須是可以度量（ Measurable ）的：這樣才能進(jìn)行成本 / 效益分析 必須是可以達(dá)到（ Attainable ）的：否則是沒有意義的目標(biāo) 必須和其他目標(biāo)具有相關(guān)性（ Relevant ）必須具有明確的截止期限（ Time-based ）18 、需求開發(fā)過程 需求開發(fā)過程是一個迭代的過程，不要期望可以線性地、順序地完成獲取、 分析、編寫規(guī)格說明和驗證這些需求開發(fā)活動。19 、劃分主題域 （構(gòu)件圖，也即 UML 中的組件圖 ）業(yè)務(wù)事件類型：外部事件（來自系統(tǒng)外部的事件，也就是系統(tǒng)參與者發(fā)起的）內(nèi)部事件

46、（系統(tǒng)內(nèi)部觸發(fā)的）20 、確定主題域（上下文關(guān)系圖）上下文關(guān)系圖 ：針對每個主題域來繪制上下文關(guān)系圖， 確定出每個主題域的范 圍。上下文關(guān)系圖繪制要點(diǎn) ： 首先用一個矩形表示系統(tǒng)，寫上系統(tǒng)的名稱，將整個系統(tǒng)看作一個黑盒子。然后找到該系統(tǒng)的所有客戶 （處于主題域的外部） ，考慮他們會發(fā)起什么事件， 這些事件會引發(fā)內(nèi)部工作人員的什么動作，將這些序列逐一表示出來。 最后再看看系統(tǒng)的每個內(nèi)部工作人員還有沒有一些主動發(fā)起的事件。當(dāng)上下文關(guān)系圖繪制出來之后， 整個主題域的范圍也就框定出來了， 但是它還 不足以為后續(xù)的需求捕獲、 分析與建?；顒犹峁┝己玫幕A(chǔ)。 我們需要將主題 域的內(nèi)容以業(yè)務(wù)事件列表和報表列

47、表表示出來。21 、需求分析人員的工作需求分析人員是對項目相關(guān)人員的需求進(jìn)行收集、 分析、記錄和驗證職責(zé)的承 擔(dān)者，是用戶群體和軟件開發(fā)團(tuán)隊間進(jìn)行需求溝通的主要渠道。定義業(yè)務(wù)需求、 確定項目涉眾和用戶類別、 獲取需求、 分析需求、 為需求建模、 編寫需求規(guī)格說明、主持對需求的驗證、引導(dǎo)對需求的優(yōu)先級劃分、管理需求等。22 、需求分析人員必備的技巧和知識需求分析員必須掌握的技能： 包括傾聽、交談和提問的技巧，分析、協(xié)調(diào)、觀 察、寫作、組織、建模、人際交往和創(chuàng)造能力。而這些能力可以概括為業(yè)務(wù)知識、技術(shù)知識和溝通能力三個方面。需求分析人員必備的知識：具備從實踐經(jīng)驗中積累的廣博知識需要將需求開發(fā)與管理

48、活動貫穿于整個產(chǎn)品生命期中 掌握應(yīng)用領(lǐng)域的知識23 、如何成為一名需求分析人員優(yōu)秀的需求分析員是培養(yǎng)出來的，而不是訓(xùn)練出來的。這項工作包括很多面向人而不是技術(shù)的“軟性技能”。 對于需求分析員的工作并沒有標(biāo)準(zhǔn)的描述，因而也沒有標(biāo)準(zhǔn)的培訓(xùn)課程24 、需求捕獲的主要方法用戶訪談、用戶調(diào)查、文檔分析、現(xiàn)場訪問客戶25 、獲取客戶需求的主要步驟確定產(chǎn)品的不同用戶類型。確定用戶需求的來源。 挑選出每一類用戶和其他涉眾的代表并與他們一起工作。 商定誰是項目需求的決策者。26、需求捕獲應(yīng)該是主動的和聚集的V27 、需求的來源與潛在用戶進(jìn)行交談和討論 描述現(xiàn)有產(chǎn)品或競爭產(chǎn)品的文檔 系統(tǒng)需求規(guī)格說明現(xiàn)有系統(tǒng)的問題

49、報告和改進(jìn)要求市場調(diào)查和用戶問卷調(diào)查觀察用戶如何工作用戶工作的情景分析事件和響應(yīng)28 、用戶代表用戶代表應(yīng)當(dāng)自始至終參與項目的整個開發(fā)過程，而不是僅參與最初的需求階段。29 、需求捕獲要具有計劃性和科學(xué)性計劃應(yīng)針對下面這些內(nèi)容來制定：需求獲取的目的需求獲取的策略和過程需求獲取工作取得的成果進(jìn)度和資源評估需求獲取的風(fēng)險科學(xué)性則體現(xiàn)在捕獲方法的選取上30 、需求獲取中各種心理如何應(yīng)對言過其實心理差異展現(xiàn)法 ：也就是將不同用戶代表的訪談結(jié)果進(jìn)行整理，在系統(tǒng)開發(fā) 之前把這些差異展示給中高層管理人員，就如何解決達(dá)成共識 瓶頸分析法 ：對流程執(zhí)行過程中的瓶頸進(jìn)行分析，例如時間瓶頸、人員 瓶頸（比如所有的申

50、請都要由處長審批）等方面，以避免流程瓶頸導(dǎo)致 系統(tǒng)無法順利運(yùn)轉(zhuǎn)起來越俎代庖心理要解決這個問題，關(guān)鍵在于需求捕獲人員能夠識別出正確的被訪談?wù)撸?也就是回答你要問的問題最佳的人選是誰。這里有兩層意思： 問題的層次是否正確：高層管理人員解決宏觀問題，中層管理人員解決 脈絡(luò)問題，操作者解決細(xì)節(jié)問題。根據(jù)業(yè)務(wù)背景判斷：也就是有效地識別該問題所針對的業(yè)務(wù)環(huán)節(jié)是由誰 負(fù)責(zé)處理的？執(zhí)行者往往是回答的最佳人選。非正事心理客觀原因：辦公室本身就是一個容易被干擾的環(huán)境。應(yīng)對之道：訪談應(yīng) 該盡可可能的避開辦公室。主觀原因：非計劃的事情通常會被看做是低優(yōu)先級的事情。應(yīng)對之道： 做好一周的訪談計劃，列出訪談人，訪談要點(diǎn)，

51、讓對方統(tǒng)一安排?？咕苄睦砦覀冃枰取盎瘮碁橛选?。這是主導(dǎo)的策略，實際的方法有很多 推卸責(zé)任心理突破推卸責(zé)任心理的簡單手段是讓被訪談?wù)呓榻B工作場景。31 、需求獲取中的注意事項如果沒有一個有條理的組織方案（例如用例） ，要將來自眾多用戶的需求意見 合并起來相當(dāng)困難。只向很少的用戶代表收集意見，或者只聽取聲音最大、最固執(zhí)已見的客戶的意見，也是需求獲取過程中存在的問題。這將導(dǎo)致遺漏對某些用戶類很重要的需求，或者引入一些大多數(shù)用戶并不需要的需求。解決這一問題的最佳平衡方式是讓用戶代言人參與需求獲取，這些代言人必 須具備為所屬的用戶類代言的權(quán)力，同時每個代言人都有數(shù)名來自同一用戶 類的用戶代表作為后援。

52、需求獲取過程中，你也許會發(fā)現(xiàn)項目范圍定義不正確，或者太大，或者太小。32 、需求分析主要用來做什么需求分析實際上是業(yè)務(wù)分析 ，也就是選擇一種業(yè)務(wù)導(dǎo)向的線索將零散的需求串 起來，形成一個體系完整、內(nèi)容清晰的框架，以指導(dǎo)后續(xù)的設(shè)計、開發(fā)工作。 更具體地描述需求分析工作的任務(wù) ：分解、提煉、 消除矛盾。 連成一句話就是： 需求分析就是先分解、再提煉，在這個過程中消除矛盾。33 、建模的要點(diǎn)與原則建模的要點(diǎn)設(shè)計要考慮到計劃之外的變化設(shè)計要文檔化用可視化的模型表達(dá)架構(gòu)切忌“為了建模而建模”建模的原則選擇創(chuàng)建什么模型對如何動手解決問題和如何形成解決方案有著深遠(yuǎn)的影響 每一種模型可以在不同的精度級別上表示最

53、好的模型是與現(xiàn)實相聯(lián)系的 單個模型是不充分的，對每個重要的系統(tǒng)最好用一組幾乎獨(dú)立的模型去處理34 、建模工具的選擇建模的要點(diǎn)是根據(jù)要完成的任務(wù)選擇合適的建模工具。35 、UML 的優(yōu)點(diǎn)首先UML是一種統(tǒng)一的、標(biāo)準(zhǔn)化的建模語言，它能為許許多多參與軟件設(shè)計 和開發(fā)的人提供一種公共“語言”，使他們能夠基于共同的“模型”來理解 業(yè)務(wù)、需求，理解軟件和架構(gòu)如何構(gòu)造其次UML是一種應(yīng)用面很廣泛的建模語言，它不僅可以用于軟件系統(tǒng)建模，還可以用于業(yè)務(wù)流程、業(yè)務(wù)知識、數(shù)據(jù)庫、嵌入式等多個領(lǐng)域；而且對于不 同的領(lǐng)域，其所采用的本質(zhì)元素是相同的。這樣：不同的人就可以基于相同 的語言溝通；不同的領(lǐng)域模型就可以通過相同

54、的機(jī)制進(jìn)行互換與遷移。這就 是統(tǒng)一的趨勢36 、流程分析（跨職責(zé)流程圖、活動圖）跨職責(zé)流程圖適合于將流程分析的產(chǎn)物在企業(yè)管理中復(fù)用時， 或者參與的人員有更強(qiáng)的業(yè)務(wù)背景。要素：流程名稱、職責(zé)帶區(qū)、流程階段、流程元素、并行、流程引用活動圖活動圖是一種表述過程機(jī)理、業(yè)務(wù)過程以及工作流的技術(shù)。它主要的應(yīng)用包括兩個方面：一是在業(yè)務(wù)建模階段，對工作流進(jìn)行建模；二是在系統(tǒng)分析和 設(shè)計階段，對操作進(jìn)行建模 它的作用和傳統(tǒng)的“流程圖”是有著很深的淵源，也十分的相似。不過它與 流程圖最主要的區(qū)別在于，活動圖能夠支持并行的行為。37 、領(lǐng)域類圖標(biāo)識類： 發(fā)現(xiàn)類的方法很多，此處介紹最廣泛使用的“名詞動詞法” 主要規(guī)則

55、： 名詞與名詞短語中提取對象與屬性；動詞與動詞短語中提取操作 與關(guān)聯(lián)；所有格短語通常表明名詞應(yīng)該是屬性而不是對象38 、用例模型參與者： 參與者是在系統(tǒng)之外， 透過系統(tǒng)邊界與系統(tǒng)進(jìn)行有意義交互的任何事 物。參與者不僅可以由人承擔(dān)，還可以是其他系統(tǒng)、硬件設(shè)備，甚至是時鐘。 用例： 用例實例是在系統(tǒng)中執(zhí)行的一系列動作， 這些動作將生成特定執(zhí)行者可 見的價值結(jié)果。用例的特征 ：用例是相對獨(dú)立的：用例的執(zhí)行結(jié)果對參與者來說是可觀測的和有意義的： 這件事必須由一個參與者發(fā)起。 不存在沒有參與者的用例， 用例不應(yīng)該自動啟 動，也不應(yīng)該主動啟動另一個用例：用例必然是以動賓短語形式出現(xiàn)的：一個用例就是一個需求單元、分析單元、設(shè)計單元、開發(fā)單元、測試單元，甚至部署單元兩個用例之間可能存在的關(guān)系：包含、擴(kuò)展、泛化，而通常不應(yīng)該有通信關(guān)系 包含關(guān)系：在UML中，用構(gòu)造型表示（箭頭方向是從基用例到被 包含用例），它是指基用例在它內(nèi)部說明的某一個位置上顯式地合并了另一個 用例的行為擴(kuò)展關(guān)系：在UML中，擴(kuò)展關(guān)系用構(gòu)造型vvextend表示（箭頭從擴(kuò)展用例到 基用例），它表示基用例在由擴(kuò)展用例間接說明的一個位置上，隱式地合并了 另一個用例的行為泛化關(guān)系：用例間的泛化則表示子用例繼承了父用例的行為和含義；子用例還可以增加或覆蓋父