軟件需求工程期末復(fù)習(xí)資料(文檔)

☆什么是軟件需求工程？請說明軟件需求工程中各階段的主要任務(wù)。p5定義一般定義：指應(yīng)用工程化的方法、技術(shù)和規(guī)格來開發(fā)和管理軟件的需求。需求工程的目標(biāo)：獲取高質(zhì)量的軟件需求。與軟件工程中傳統(tǒng)的需求剖析看法比較，需求工程突出了工程化的原則，重申以系統(tǒng)化、條理化、可重復(fù)化的方法和技術(shù)進行與軟件需求相關(guān)的活動，從而有利于提高所有與軟件需求相關(guān)的活動及其過程的可管理性，降低需求開發(fā)和管理的難度和成本。其他定義：Alan.Davis：直到（但不包括）把軟件分解為實質(zhì)架構(gòu)組建從前的所有活動，即軟件設(shè)計從前的所有活動。該定義誠然沒有詳細說明需求工程是什么，但其給出了需求工程的范圍。LanK.Bray：對問題域及需求做檢查研究和描述，設(shè)計滿足那些需求的解系統(tǒng)的特點，并用文檔恩賜說明。這個定義明確指出了需求工程的任務(wù)就是獲取、剖析和表達軟件的需求。需求工程=需求的開發(fā)活動+需求的管理活動各階段主要任務(wù)需求獲取階段：獲取用戶的需求信息。需求剖析階段：剖析和綜合已經(jīng)收集到的需求信息。需求建模階段：依照待開發(fā)軟件系統(tǒng)的需求利用某種建模方法成立該系統(tǒng)的邏輯模型。需求定義階段：依照用戶需求編寫出需求規(guī)格說明。需求的形式化描述階段：用嚴格的數(shù)學(xué)知識和符號來構(gòu)造系統(tǒng)的需求模型。需求考據(jù)階段：檢驗軟件需求規(guī)格說明。需求管理階段：開發(fā)人員在與提出更正的央求者協(xié)商的基礎(chǔ)上，評估需求更正帶來的隱藏影響及可能的成本及開支，此后推行更正，一級有效的管理需求規(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）用戶解決問題或達到目標(biāo)所需的條件或能力；2）系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需擁有的條件或能力。平時定義：軟件需求是指軟件系統(tǒng)必定滿足的所有功能、性質(zhì)和限制。軟件需求的種類:目標(biāo)需求：反響組織機構(gòu)或客戶對系統(tǒng)和產(chǎn)品提出的高層次的目標(biāo)要求，其限制了項目的范圍和項目應(yīng)達到的目標(biāo)。業(yè)務(wù)需求：主要描述軟件系統(tǒng)必定完成的任務(wù)、實質(zhì)業(yè)務(wù)或工作流程等。軟件開發(fā)人員平時可從業(yè)務(wù)需求進一步細化出詳細的功能需求和非功能需求。功能需求：指開發(fā)人員必定實現(xiàn)的軟件功能或軟件系統(tǒng)應(yīng)擁有的外面行為。性能需求：指實現(xiàn)的軟件系統(tǒng)功能應(yīng)達到的技術(shù)指標(biāo)，如：計算效率和精度，可靠性，可保護性和可擴展性等。拘束與限制：指軟件開發(fā)人員在設(shè)計和實現(xiàn)軟件系統(tǒng)時的限制，如：開發(fā)語言，使用的數(shù)據(jù)庫等?！钤囀鲅杆僭烷_發(fā)模型和面向?qū)ο箝_發(fā)模型的基本思想，此后說明迅速原型開發(fā)模型中拋棄型模型和進化型模型的作用。p9迅速原型模型基本思想：迅速成立一個實現(xiàn)了若干功能的（不要求圓滿）可運行模型來啟示、揭露和不斷圓滿用戶需求，直到滿足用戶的所有需求為止。其基本過程以下：收集需求

迅速設(shè)計

成立原型

討論并細化需求

設(shè)計與實現(xiàn)

測試

保護面向?qū)ο箝_發(fā)模型基本思想：應(yīng)用對象、類、繼承、封裝、信息、對象或類之間的關(guān)系等面向?qū)ο蟮目捶▽栴}進行剖析和求解的軟件開發(fā)技術(shù)，也許說，是以對象（類）為數(shù)據(jù)中心、對象之間的動向行為模式作為運行系統(tǒng)的一種問題求解方法。其基本過程以下：面向?qū)ο笃饰雒嫦驅(qū)ο笤O(shè)計面向?qū)ο髮崿F(xiàn)和測試系統(tǒng)保護拋棄型模型：指在原型達到預(yù)期目的后將其拋棄，而且在成立該原型時，能夠忽略詳細的軟件構(gòu)造技術(shù)，亦即應(yīng)以最小的代價構(gòu)造拋棄型原型。進化型模型：在需求被清楚定義的情況下，以漸增式方式成立原型，并使原型最后能成為軟件產(chǎn)品的一部分。☆請指出以下陳述屬于哪一各種類的軟件需求或不屬于軟件需求。p26（1）只有電梯停在某一樓層時，電梯才能改變方向。非功能（2）系統(tǒng)必定用三個主要模塊來實現(xiàn)，即檢測、記錄和統(tǒng)計剖析模塊，每個模塊各自實現(xiàn)一個主要功能。功能性需求（3）當(dāng)用戶輸入他們的口令后，系統(tǒng)便自動從口令文件中檢索他們的加密口令，并進行核對。功能性需求（4）經(jīng)過對用戶進行不到一個小時的培訓(xùn)后，用戶能輸入和打印某些數(shù)據(jù)，且輸入/出的出錯率低于1/20。非功能（5）所有報銷單據(jù)必定經(jīng)過財務(wù)部門某負責(zé)人審察后才能交由系統(tǒng)辦理。非功能（6）系統(tǒng)必定用面向?qū)ο蟮姆椒ê图夹g(shù)實現(xiàn)。非功能☆以下需求可否含糊，若是含糊的話，請在說明原因后恩賜更正：p84（1）系統(tǒng)必定在固定的時間間隔內(nèi)供應(yīng)狀態(tài)信息，而且每次時間間隔不得小于60秒。含糊。需求不圓滿，以致需求不能夠考據(jù)。改進以下：后臺任務(wù)管理器(BTM)應(yīng)該在用戶界面的指定地域顯示狀態(tài)信息。a.在后臺任務(wù)進度啟動此后，信息必定每隔60(10)秒更新一次，而且保持連續(xù)的可見性。b.若是正在正常辦理后臺任務(wù)進度，那么后臺任務(wù)管理器(BTM)必定顯示后臺任務(wù)進度已完成的百分比。c.當(dāng)完成后臺任務(wù)時，后臺任務(wù)管理器(BTM)必定顯示一個“已完成”的信息。d.若是后臺任務(wù)中止執(zhí)行，那么后臺任務(wù)管理器(BTM)必定顯示一個出錯信息。（2）“產(chǎn)品必定在顯示和隱蔽非打印字符之間進行剎時切換”。在剎時這一時間看法上，計算機不能夠夠完成任何工作，因此，這個需求是不能夠行的。該需求也是不圓滿的，由于它沒有討情狀態(tài)切換的原因。在特定的條件下，軟件產(chǎn)品可否能夠進行自動切換也許可否由用戶采用某些措施來激發(fā)這樣轉(zhuǎn)變？還有，在文檔中顯示轉(zhuǎn)變的范圍是什么？是所選的文本、整個文檔或其他內(nèi)容？這個需求也存在一個不確定性問題?！胺谴蛴　弊址煞裰鸽[蔽文本、屬性標(biāo)記也許其他的控制字符？由于存在這些問題，該需求是不可考據(jù)的。用以下的語句描述這個需求可能會更好一些：“用戶在編寫文檔時，經(jīng)過激活特定的觸發(fā)系統(tǒng)，能夠在顯示和隱蔽所有HTML標(biāo)記之間進行切換”?，F(xiàn)在，指代關(guān)系就清楚了，非打印字符指的是HTML標(biāo)記。修悔悟的需求指了然是用戶觸發(fā)了顯示狀態(tài)的變換，可是它并沒有對設(shè)計造成限制，由于它并沒有精確定義所使用的系統(tǒng)。當(dāng)設(shè)計人員選擇好一種觸發(fā)系統(tǒng)（比方熱鍵、菜單命令或語音輸入）時，你就可以編寫詳細的測試用例來考據(jù)這種變換操作可否正確。3）編譯系統(tǒng)應(yīng)該能生出出錯報告，這樣即可使初學(xué)者能迅速的排錯。應(yīng)說明編譯系統(tǒng)在什么情況下出什么出錯報告，改為：編譯系統(tǒng)應(yīng)該能表記出錯誤，并在錯誤所在的地址顯示出出錯報告，這樣即可使初學(xué)者迅速的排錯。4）軟件系統(tǒng)應(yīng)擁有優(yōu)異的反響時間和數(shù)據(jù)精度，且能由菜單方式驅(qū)動?！皟?yōu)異的”應(yīng)使用量化的語言表達，改為：軟件系統(tǒng)的反響時間應(yīng)小于1秒，數(shù)據(jù)精度為10^-6。（5）“剖析程序應(yīng)該能生成HTML標(biāo)記出錯的報告，這樣就可以使HTML的初學(xué)者使用它來迅速排錯?！薄把杆佟边@個詞擁有模糊性。缺乏對出錯報告內(nèi)容的定義表示該需求是不圓滿的。我不知道你是如何考據(jù)這個需求的。找一些HTML的初學(xué)者，看他們利用這個報告可否能夠迅速排錯？還有一點不清楚的是：HTML初學(xué)者使用的是剖析程序還是出錯報告。而且何時生成這樣的報告？讓我們使用另一種方式表述這個需求：在HTML剖析程序圓滿剖析完一個文件后，該剖析程序必定生成一個出錯報告，這個報告中包括了在剖析文件過程中所發(fā)現(xiàn)錯誤的HTML所在的行號以及文本內(nèi)容，還包括了對每個錯誤的描述。若是在剖析過程中未發(fā)現(xiàn)任何錯誤，就不用生成出錯報告。現(xiàn)在我們知道了任何生成出錯報告及其所包括的內(nèi)容，可是我們已經(jīng)把該需求提交給設(shè)計人員，讓他們來決定報告的形式。我們還指了然一種例外情況：若是沒有任何錯誤，就不生成出錯報告。（6）“若是可能的話，應(yīng)該依照主貨物編號列表在線確認所輸入的貨物編號?！蔽以谙耄骸叭羰强赡艿脑挕边@句話意味著什么？該需求可否在技術(shù)上可行？可否能夠在線接見主貨物編號列表？若是你不能夠夠確信可否能夠遞交一個央求，那么就使用“待確定”(TBD)來表示未解決的問題。這個需求是不圓滿的，由于它并沒有指明若是確認經(jīng)過或失敗，將會發(fā)生什么情況。應(yīng)該盡量防備使用不精確的詞匯，比方“應(yīng)該”?？蛻艨赡苄枰@個功能也許不需要這個功能。一些需求規(guī)格說明利用要點字之間巧妙的差別如“應(yīng)該”，“必定”和“可能”來指明重要性。我更喜歡使用“必定”或“將要”來明確說明需求的目的而且明確指定其優(yōu)先級。改進后的該需求描述以下：“系統(tǒng)必定依照在線的主貨物編號列表確認所輸入的貨物編號。若是在主列表中查不到該貨物的編號，系統(tǒng)必定顯示一個出錯信息而且拒絕訂貨。”第二種相關(guān)需求可能記錄了一種異常情況：當(dāng)進行貨物編號確認時，主貨物編號列表不能夠接見。（7）“產(chǎn)品不應(yīng)該供應(yīng)將帶來災(zāi)禍性結(jié)果的盤問和代替選擇。”“災(zāi)禍性結(jié)果”的含義是講解的中心詞。在編寫文檔時，毫無目的地作出全局性變化而用戶又不能夠夠檢測出錯誤或沒有任何方法來糾正它，此時即可能帶來災(zāi)禍性結(jié)果。你也要合理地使用反面需求，由于這些需求描述了系統(tǒng)所不能夠夠做的事情。隱藏的關(guān)注焦點在于當(dāng)發(fā)買賣外損壞時，能保護文件的內(nèi)容。也許，真切的需求是針對多級撤掉(undo)能力、全局變化或其他能夠致數(shù)據(jù)拋棄行為確定的。☆為方便顧客，某航空公司擬開發(fā)一個機票預(yù)約系統(tǒng)。機票售票點把預(yù)約機票的顧客信息（姓名，性別，身份證號，出發(fā)時間和目的地，航班號等）輸入該系統(tǒng)，系統(tǒng)為顧客盤問航班，打印出取票通知單和賬單。顧客在飛機跳躍前一天憑取票通知單和賬單繳款取票，系統(tǒng)核對無誤后馬上打印出機票給顧客。請用數(shù)據(jù)流圖畫出該系統(tǒng)的需求模型（不需要給出數(shù)據(jù)字典）p42系統(tǒng)數(shù)據(jù)流圖訂票信息旅客機票

機票預(yù)約系統(tǒng)

取票通知和賬單取通知和賬單旅客付費信息頂層數(shù)據(jù)流程圖頂層數(shù)據(jù)流圖可是大概的給出整個系統(tǒng)的數(shù)據(jù)流情況。為了更好的把“航空機票預(yù)約系統(tǒng)”中各個模塊的詳細數(shù)據(jù)流辦理細節(jié)表示出來，能夠在頂層圖的基礎(chǔ)上自頂向下連續(xù)分解，獲取1層和2層數(shù)據(jù)流圖。旅客信息訂票通知、賬單信息旅客旅客取票通知、賬單信息1層流程圖旅客信息1.1訂票信息1.2通知、賬單信息打印、通安排航班知賬單訂票信息旅客D1訂票信息旅客機票2.3收費信息2.2打印機票收費

通知、賬單信息訂票信息核對正2.1確核對機票信息2層流程圖1.11旅客基本信息及1.13訂票信息旅客信息旅客基本信訂票要求信息航班安D2通知和賬單記錄息及訂票要求信息錄入排旅客基本信息航班信息1.141.12旅客管航班管理理D3旅客基本信息表D4航班信息票訂票細化流程圖旅客去票通知和賬單信息2.32.2正確2.1打印機核對機收費票票信息訂票信息D1訂票記錄另附數(shù)據(jù)字典：旅客信息:姓名：xxx性別：男描述：旅客訂票時所填的資料(省份證號、所需機票的基本信息、趁便時間）定義：訂票申請表單(旅客姓名、旅客性別、跳躍日期、游覽目的地、座位種類）地址：地址：在客戶端由旅客填寫航班信息：航班名稱：航班種類：描述：所有從當(dāng)?shù)靥S的航班信息（航班號、跳躍時間、到達的目的地、空出的座位數(shù)、票價）定義：航班信息（航班號、跳躍日期、游覽目的地、空出的座位數(shù)、票價）地址：從服務(wù)器端盤問后，發(fā)送到客戶端賬單信息：賬單名稱：賬單號：描述：已定票的旅客信息資料（帳單號、旅客姓名、