軟件需求工程期末總結(jié)復(fù)習(xí)學(xué)習(xí)資料.doc

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

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

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

4、所有功能、性質(zhì)和限制。軟件需求的類型：目標(biāo)需求：反映組織機(jī)構(gòu)或客戶對系統(tǒng)和產(chǎn)品提出的高層次的目標(biāo)要求，其限定了項目的范圍和項目應(yīng)達(dá)到的目標(biāo)。業(yè)務(wù)需求：主要描述軟件系統(tǒng)必須完成的任務(wù)、實際業(yè)務(wù)或工作流程等。軟件開發(fā)人員通常可從業(yè)務(wù)需求進(jìn)一步細(xì)化出具體的功能需求和非功能需求。功能需求：指開發(fā)人員必須實現(xiàn)的軟件功能或軟件系統(tǒng)應(yīng)具有的外部行為。性能需求：指實現(xiàn)的軟件系統(tǒng)功能應(yīng)達(dá)到的技術(shù)指標(biāo)，如：計算效率和精度，可靠性，可維護(hù)性和可擴(kuò)展性等。約束與限制：指軟件開發(fā)人員在設(shè)計和實現(xiàn)軟件系統(tǒng)時的限制，如：開發(fā)語言，使用的數(shù)據(jù)庫等。試述快速原型開發(fā)模型和面向?qū)ο箝_發(fā)模型的基本思想，然后說明快速原型開發(fā)模型中拋

5、棄型模型和進(jìn)化型模型的作用。p9快速原型模型基本思想： 快速建立一個實現(xiàn)了若干功能的 （不要求完全）可運行模型來啟發(fā)、揭示和不斷完善用戶需求，直到滿足用戶的全部需求為止。其基本過程如下：面向?qū)ο箝_發(fā)模型基本思想：應(yīng)用對象、類、繼承、封裝、消息、對象或類之間的關(guān)系等面向?qū)ο蟮母拍顚栴}進(jìn)行分析 和求解的軟件開發(fā)技術(shù)，或者說，是以對象（類）為數(shù)據(jù)中心、對象之間的動態(tài)行為模式作 為運行機(jī)制的一種問題求解方法。其基本過程如下：拋棄型模型：指在原型達(dá)到預(yù)期目的后將其拋棄，而且在構(gòu)建該原型時，可以忽略具體的軟件構(gòu)造技術(shù)，亦即應(yīng)以最小的代價構(gòu)造拋棄型原型。進(jìn)化型模型：在需求被清楚定義的情況下，以漸增式方式構(gòu)

6、建原型，并使原型最終能成為軟件產(chǎn)品的一部分。請指出下列陳述屬于哪種類型的軟件需求或不屬于軟件需求。p26（1）只有電梯停在某一樓層時，電梯才能改變方向。非功能（2）系統(tǒng)必須用三個主要模塊來實現(xiàn)，即檢測、記錄和統(tǒng)計分析模塊，每個模塊各自實現(xiàn)個主要功能。功能性需求（3 ）當(dāng)用戶輸入他們的口令后，系統(tǒng)便自動從口令文件中檢索他們的加密口令，并進(jìn)行核對。功能性需求（4 ）通過對用戶進(jìn)行不到一個小時的培訓(xùn)后，用戶能輸入和打印某些數(shù)據(jù)，且輸入/出的出錯率低于1/20。 非功能（5）所有報銷單據(jù)必須經(jīng)過財務(wù)部門某負(fù)責(zé)人審核后才能交由系統(tǒng)處理。非功能（6 ）系統(tǒng)必須用面向?qū)ο蟮姆椒ê图夹g(shù)實現(xiàn)。非功能下列需求是否

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

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

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

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

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

12、匯，例如“應(yīng)當(dāng)”?？蛻艨赡苄枰@個功能或者不需要這個功能。一些需求規(guī)格說明利用關(guān)鍵字之間微妙的差別如“應(yīng)當(dāng)”，“必須”和“可能”來指明重要性。我更喜歡使用“必須”或“將要”來明確說明需求的目的并且明確指定其優(yōu)先級。改進(jìn)后的該需求描述如下：“系統(tǒng)必須根據(jù)在線的主貨物編號列表確認(rèn)所輸入的貨物編號。如果在主列表中查不到該貨物的編號，系統(tǒng)必須顯示一個出錯消息并且拒絕訂貨?！钡诙N相關(guān)需求可能記錄了一種異常情況：當(dāng)進(jìn)行貨物編號確認(rèn)時，主貨物編號列表不可訪問。（7 ） “產(chǎn)品不應(yīng)該提供將帶來災(zāi)難性后果的查詢和替換選擇?！薄盀?zāi)難性后果” 的含義是解釋的中心詞。在編輯文檔時，毫無目的地作出全局性變化而用戶又不

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

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

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

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