1、P5什么是軟件需求工程？請說明軟件需求工程中各階段的主要任務。1定義一般定義：指應用工程化的方法、技術和規格來開發和管理軟件的需求。需求工程的目標：獲取高質量的軟件需求。與軟件工程中傳統的需求分析概念相比，需求工程突出了工程化的原則，強調以系統化、條理化、可重復化的方法和技術進行與軟件需求相關的活動，從而有利于提高所有與軟件需求相關的活動及其過程的可管理性，降低需求開發和管理的難度和成本。其它定義：Alan.Davis ：直到（但不包括）把軟件分解為實際架構組建之前的所有活動，即軟件設計之前的一切活動。該定義雖然沒有詳細說明需求工程是什么，但其給出了需求工程的范圍。Lan K. Bray ：對

2、問題域及需求做調查研究和描述，設計滿足那些需求的解系統的特性，并用文檔給予說明。這個定義明確指出了需求工程的任務就是獲取、分析和表達軟件的需求。需求工程=需求的開發活動 +需求的管理活動2各階段主要任務需求獲取階段：獲取用戶的需求信息。需求分析階段：分析和綜合已經收集到的需求信息。需求建模階段：根據待開發軟件系統的需求利用某種建模方法建立該系統的邏輯模型。需求定義階段：根據用戶需求編寫出需求規格說明。需求的形式化描述階段：用嚴格的數學知識和符號來構造系統的需求模型。需求驗證階段：檢驗軟件需求規格說明。需求管理階段：開發人員在與提出更改的請求者協商的基礎上，評估需求變更帶來的潛在影響及可能的成本

3、及費用，然后實施更改，一級有效的管理需求規格說明文檔和跟蹤更改需求的狀態。什么是軟件需求？軟件需求有哪些類型，并分別給出它們的定義。p2軟件需求的定義：A. Davis ：軟件需求是從軟件外部能發現的，軟件所具有的，滿足于用戶的特點、功能及屬性等的集合。I. Sommerville ：需求是問題信息和系統行為、特性、設計和實現約束的描述的集合。M. Jackson等：需求是客戶希望在問題域內產生的效果。IEEE軟件工程標準：（1 ）用戶解決問題或達到目標所需的條件或能力；（2 ）系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或能力。通俗定義：軟件需求是指軟件系統必須滿足的

4、所有功能、性質和限制。軟件需求的類型：目標需求：反映組織機構或客戶對系統和產品提出的高層次的目標要求，其限定了項目的范圍和項目應達到的目標。業務需求：主要描述軟件系統必須完成的任務、實際業務或工作流程等。軟件開發人員通常可從業務需求進一步細化出具體的功能需求和非功能需求。功能需求：指開發人員必須實現的軟件功能或軟件系統應具有的外部行為。性能需求：指實現的軟件系統功能應達到的技術指標，如：計算效率和精度，可靠性，可維護性和可擴展性等。約束與限制：指軟件開發人員在設計和實現軟件系統時的限制，如：開發語言，使用的數據庫等。試述快速原型開發模型和面向對象開發模型的基本思想，然后說明快速原型開發模型中拋

5、棄型模型和進化型模型的作用。p9快速原型模型基本思想： 快速建立一個實現了若干功能的 （不要求完全）可運行模型來啟發、揭示和不斷完善用戶需求，直到滿足用戶的全部需求為止。其基本過程如下：面向對象開發模型基本思想：應用對象、類、繼承、封裝、消息、對象或類之間的關系等面向對象的概念對問題進行分析 和求解的軟件開發技術，或者說，是以對象（類）為數據中心、對象之間的動態行為模式作 為運行機制的一種問題求解方法。其基本過程如下：拋棄型模型：指在原型達到預期目的后將其拋棄，而且在構建該原型時，可以忽略具體的軟件構造技術，亦即應以最小的代價構造拋棄型原型。進化型模型：在需求被清楚定義的情況下，以漸增式方式構

6、建原型，并使原型最終能成為軟件產品的一部分。請指出下列陳述屬于哪種類型的軟件需求或不屬于軟件需求。p26（1）只有電梯停在某一樓層時，電梯才能改變方向。非功能（2）系統必須用三個主要模塊來實現，即檢測、記錄和統計分析模塊，每個模塊各自實現個主要功能。功能性需求（3 ）當用戶輸入他們的口令后，系統便自動從口令文件中檢索他們的加密口令，并進行核對。功能性需求（4 ）通過對用戶進行不到一個小時的培訓后，用戶能輸入和打印某些數據，且輸入/出的出錯率低于1/20。 非功能（5）所有報銷單據必須經過財務部門某負責人審核后才能交由系統處理。非功能（6 ）系統必須用面向對象的方法和技術實現。非功能下列需求是否

7、含糊，如果含糊的話，請在說明理由后給予修改：p84（1）系統必須在固定的時間間隔內提供狀態信息，并且每次時間間隔不得小于60秒。含糊。需求不完整，導致需求不可驗證。改進如下：后臺任務管理器（BTM）應該在用戶界面的指定區域顯示狀態消息。a.在后臺任務進程啟動之后，消息必須每隔60（±10）秒更新一次，并且保持連續的可見性。b.如果正在正常處理后臺任務進程，那么后臺任務管理器（BTM）必須顯示后臺任務進程已完成的百分比。c.當完成后臺任務時，后臺任務管理器（BTM）必須顯示一個“已完成”的消息。d.如果后臺任務中止執行，那么后臺任務管理器（BTM）必須顯示一個出錯信息。（2 ） “產品

8、必須在顯示和隱藏非打印字符之間進行瞬間切換”o在瞬間這一時間概念上，計算機不能完成任何工作，因此，這個需求是不可行的。該需求也是不完整的，因為它沒有說清狀態切換的原因。 在特定的條件下，軟件產品是否可以進 行自動切換或者可否由用戶采取某些措施來激發這樣轉變？還有，在文檔中顯示轉變的范圍是什么？是所選的文本、整個文檔或其它內容？這個需求也存在一個不確定性問題。“非打該需求是不印”字符是否指隱藏文本、 屬性標記或者其它的控制字符？由于存在這些問題, 可驗證的。用如下的語句描述這個需求可能會更好一些：“用戶在編輯文檔時，通過激活特定的觸發機制，可以在顯示和隱藏所有HTML標記之間進行切換”。現在，指

9、代關系就清楚了，非打印字符指的是HTML標記。修改過的需求指明了是用戶觸發了顯示狀態的轉換，但是它并沒有對設計造成限制，因為它并沒有精確定義所使用的機制。當設計人員選擇好一種觸發機制（例如熱鍵、菜單命令或語音輸入） 時，你就可以編寫詳細的測試用例來驗證這種轉換操作是否正確。（3 ）編譯系統應該能生出出錯報告，這樣就可使初學者能迅速的排 錯。應說明編譯系統在什么情況下出什么出錯報告，改為：編譯系統應該能標識出錯誤，并在錯誤所在的位置顯示出出錯報告，這樣就可使初學者迅速的排錯O（4 ）軟件系統應具有良好的反應時間和數據精度，且能由菜單方式驅 動。“良好的”應使用量化的語言敘述，改為：軟件系統的反應

10、時間應小于1秒，數據精度為10八6 o（5 ） “分析程序應該能生成HTML標記出錯的報告，這樣就可以使HTML的初學者使用它來迅速排錯。”“迅速”這個詞具有模糊性。 缺乏對出錯報告內容的定義表明該需求是不完整的。我不知道你是如何驗證這個需求的。找一些HTML的初學者，看他們利用這個報告是否可以迅速排錯？還有一點不清楚的是：HTML初學者使用的是分析程序還是出錯報告。并且何時生成這樣的報告？讓我們使用另一種方式表述這個需求：a.在H T M L分析程序完全分析完一個文件后，該分析程序必須生成一個出錯報告，這個報告中包含了在分析文件過程中所發現錯誤的HTML所在的行號以及文本內容，還包含了對每個

11、錯誤的描述。b.如果在分析過程中未發現任何錯誤，就不必生成出錯報告。現在我們知道了任何生成出錯報告及其所包含的內容，但是我們已經把該需求提交給設計人員，讓他們來決定報告的形式。我們還指明了一種例外情況：如果沒有任何錯誤，就不生成出錯報告。（6 ） “如果可能的話，應當根據主貨物編號列表在線確認所輸入的貨物編號。”我在想：“如果可能的話”這句話意味著什么？該需求是否在技術上可行？是否可以在線訪問主貨物編號列表？如果你不能確信是否可以遞交一個請求，那么就使用“待確定” （TBD）來表示未解決的問題。這個需求是不完整的，因為它并沒有指明如果確認通過或失敗，將會發生什么情況。應該盡量避免使用不精確的詞

12、匯，例如“應當”。客戶可能需要這個功能或者不需要這個功能。一些需求規格說明利用關鍵字之間微妙的差別如“應當”，“必須”和“可能”來指明重要性。我更喜歡使用“必須”或“將要”來明確說明需求的目的并且明確指定其優先級。改進后的該需求描述如下：“系統必須根據在線的主貨物編號列表確認所輸入的貨物編號。如果在主列表中查不到該貨物的編號，系統必須顯示一個出錯消息并且拒絕訂貨。”第二種相關需求可能記錄了一種異常情況：當進行貨物編號確認時，主貨物編號列表不可訪問。（7 ） “產品不應該提供將帶來災難性后果的查詢和替換選擇。”“災難性后果” 的含義是解釋的中心詞。在編輯文檔時，毫無目的地作出全局性變化而用戶又不

13、能檢測出錯誤或沒有任何辦法來糾正它，此時就可能帶來災難性后果。你也要合理地使用反面需求，因為這些需求描述了系統所不能做的事情。潛在的關注焦點在于當發生意外損壞時，能保護文件的內容。也許，真正的需求是針對多級撤銷（undo）能力、全局變化或其它可導致數據丟失行為確定的。為方便顧客，某航空公司擬開發一個機票預訂系統。機票售票點把預訂機票的顧客信息（姓名，性別，身份證號，出發時間和目的地，航班號等）輸入該系統，系統為顧客查詢航班，打印出取票通知單和賬單。顧客在飛機起飛前一天憑取票通知單和賬單繳款取票，系統 核對無誤后立即打印出機票給顧客。p42系統數據流圖請用數據流圖畫出該系統的需求模型（不需要給出

14、數據詞典）word專業資料頂層數據流程圖頂層數據流圖只是粗略的給出整個系統的數據流情況。為了更好的把“航空機票預定系統”中各個模塊的具體數據流處理細節表示出來，可以在頂層圖的基礎上自頂向下繼續分解，得到1層和2層數據流圖。旅客信息旅客機票/2.3J11訂票節息,打En i甬 通知、賬單信息 訂票信息 ,D1訂票信息旅客通知、蟀單信息JL票信息核對正/ QT、收費信息（2.2 確以C而、TV2層流程圖1.11旅客基本信息及1-13 旅客信息旅客基本信遼摹要求班；介-工斤飛、及訂票要航班女）1 1四蚪孤航班信息/ri4/1.12I旅客管11航班管）訂票信息"" D史通知和賬單記

15、京D3旅客基本信息表D4航班信息票訂票細化流程圖旅客去票通知和賬單信息訂票信息另附數據字典:旅客信息：姓名：XXX性別：男描述：旅客訂票時所填的資料（省份證號、所需機票的基本信息、乘機時間）定義：訂票申請表單（旅客姓名、旅客性別、起飛日期、飛行目的地、座位類型 ）位置：位置：在客戶端由旅客填寫航班信息:航班名稱：航班類型：描述：所有從本地起飛的航班信息（航班號、起飛時間、到達的目的地、空出的 座位數、票價）定義：航班信息（航班號、起飛日期、飛行目的地、空出的座位數、票價）位置：從服務器端查詢后，發送到客戶端賬單信息:賬單名稱：賬單號：描述：已定票的旅客信息資料（帳單號、旅客姓名、旅客性別、旅客

16、身份證號） 定義：賬單基本信息（訂票旅客的姓名、性別、省份證號、航班號） 位置：在服務器端產生，發送回客戶端機票信息:機票編號：航班號：描述：所有機票信息（已出售的機票、剩余機票、航班號、起飛時間）定義：機票基本信息（旅客姓名、旅客性別、身份證號碼、航班號、起飛時間、飛 行目的地、座位號）位置:發送到客戶端另附系統流程圖（功能需求）用戶接受安排客戶端二航班數據庫一服務器終 端客戶端二訂票數據庫 一另附面向對象的需求分析方法:斗膽*L班組至Rwr向ion tKHiktCiisioriier):query! CID);qucntCID. FIDprimdl”；prinlN<itice<rr>);機票Ticket編弓ID身份證號CID加班號FID1口發日期depDate'11 發J，間 de|>iMWre11 的地 deslmatitm(ft 名 nameisOutf)；isPayt);頤客 C<15 turner 好名name 性加牌工 身份證號CID 肌坍號FID 出發日期&pDaS 出發時0J depiture ”的他