軟件需求習題集3

1、-作者xxxx-日期xxxx軟件需求習題集3【精品文檔】習題二：2-2、說明客戶與開發(fā)人員之間是什么關(guān)系？客戶與用戶是一樣的嗎？答：通常意義下，客戶是指直接或間接從產(chǎn)品中獲得利益的個人或組織。軟件客戶包括提出 要求、支付款項、選擇、具體說明或使用軟件產(chǎn)品的項目風險承擔者 (stakeholder)或是獲得產(chǎn) 品所產(chǎn)生的結(jié)果的人。他們能說清楚要使用該產(chǎn)品完成什么任務(wù)和一些非功能性 的特性，而這些特性會對使用戶很好接收具有該特點的產(chǎn)品是重要的。2-3、什么是業(yè)務(wù)需求、什么是用戶需求？答：業(yè)務(wù)需求應(yīng)說明客戶、公司和想從該系統(tǒng)獲利的風險承擔者或從系統(tǒng)中取得結(jié)果的 用戶所要求的目標。業(yè)務(wù)需求為后繼工作建

2、立了一個指導(dǎo)性的框架。其它任何說明都應(yīng)遵從 業(yè)務(wù)需求的規(guī)定，然而業(yè)務(wù)需求并不能為開發(fā)人員提供許多開發(fā)所需的細節(jié)說明。 用戶需求 必須從使用產(chǎn)品的用戶處收集。因此這些用戶（通常稱作最 終用戶），構(gòu)成了另一種軟件客戶。他們能說清楚要使用該產(chǎn)品完成什么任務(wù)和一些非功能性 的特性，而這些特性會對使用戶很好接收具有該特點的產(chǎn)品是重要的。說明業(yè)務(wù)需求的客戶有時將試圖替代用戶說話，但通常他們根本無法準確說明用戶需求。2-4、客戶與開發(fā)人員之間是什么關(guān)系？答優(yōu)秀的軟件產(chǎn)品是建立在優(yōu)秀的需求基礎(chǔ)之上的。而高質(zhì)量的需求來源于客戶與開發(fā)人 員之間有效的交流與合作。：只有當雙方參與者都明白要成功自己需要什么，同時也應(yīng)

3、知道要成功合作方需要什么時， 才能建立起一種合作關(guān)系。2-5、簡述軟件客戶需求權(quán)利書。答：客戶有如下權(quán)利： 1. 要求分析人員使用符合客戶語言習慣的表達。 2. 要求分析人員了解客戶系統(tǒng)的業(yè)務(wù)及目標。 3. 要求分析人員組織需求獲取期間所介紹的信息，并編寫軟件需求規(guī)格說明。 4. 要求開發(fā)人員對需求過程中所產(chǎn)生的工作結(jié)果進行解釋說明。 5. 要求開發(fā)人員在整個交流過程中保持和維護一種合作的職業(yè)態(tài)度。 6. 要求開發(fā)人員對產(chǎn)品的實現(xiàn)及需求都要提供建議，拿出主意。 7. 描述產(chǎn)品使其具有易用、好用的特性。 8. 可以調(diào)整需求，允許重用已有的軟件組件。 9. 當需要對需求進行變更時，對成本、影響、得

4、失（ trade-off）有個真實可信的評估。 10. 獲得滿足客戶功能和質(zhì)量要求的系統(tǒng)，并且這些要求是開發(fā)人員同意的。2-6、敘述一下客戶需求的權(quán)利與義務(wù)？答：客戶有下列義務(wù)： 1. 給分析人員講解業(yè)務(wù)及說明業(yè)務(wù)方面的術(shù)語等專業(yè)問題。 2. 抽出時間清楚地說明需求并不斷完善。3. 當說明系統(tǒng)需求時，力求準確詳細。 4. 需要時要及時對需求做出決策。 5. 要尊重開發(fā)人員的成本估算和對需求的可行性分析。 6. 對單項需求、系統(tǒng)特性或使用實例劃分優(yōu)先級。 7. 評審需求文檔和原型。 8. 一旦知道要對項目需求進行變更，要馬上與開發(fā)人員聯(lián)系。 9. 在要求需求變更時，應(yīng)遵照開發(fā)組織確定的工作過程來

5、處理。 10. 尊重需求工程中開發(fā)人員采用的流程（過程）。2-7、軟件客戶的權(quán)利與義務(wù)法案？答：參見書上，2.2.1和2.2.2中的條例即可。2-8、“簽約”意味著什么？答： “簽約”意味著什么應(yīng)該吧它作為項目的里程碑。對于簽字之前應(yīng)進行哪些活動，以及簽字對將來變更的影響，各方應(yīng)形成明確一致的理解。在需求上簽約是終止需求開發(fā)過程的正確方法。然而，參與者必須明白他們的簽約 意味著什么。2-9、為什么說“不要把“簽約”當成武器”？答：許多組織在需求文 檔中使用“簽約”這個概念來作為客戶同意需求的標志行為。故要讓所有需求參與者都真正 明白“簽約”的意思。這樣的態(tài)度都是不對的，不可能在項目早期就了解所

6、有需求，而且毫無疑問需求將會出 現(xiàn)變更。2-10、什么是需求協(xié)議的基線？答：可參看2-11的答案。2-11、怎樣設(shè)置基線？答：設(shè)置基線是很有意義的，它能給所有主要的涉眾帶來信心： 客戶管理層相信項目的范圍不會過度膨脹直至失控,因為客戶掌握了范圍變更的決定權(quán). 用戶代表有信心開發(fā)團對會跟他們一同努力開發(fā)出符合需求的系統(tǒng),即便他們不能在系統(tǒng)開始構(gòu)建之前想到所有的需求. 開發(fā)管理人員有信心，因為開發(fā)團隊有了業(yè)務(wù)伙伴。業(yè)務(wù)伙伴能夠保證項目的中心工作集中在業(yè)務(wù)目標上。他們將與開發(fā)人員一起在進度、成本、功能和質(zhì)量之間做出平衡。 需求分析員也充滿信心，因為他們可以有效地管理項目的變更，將變更引起的麻煩減至最

7、小。 用明確的協(xié)議來結(jié)束前期是需求開發(fā)活動，能夠幫助客戶和開發(fā)人員形成合作伙伴關(guān)系，攜手走上項目成功之路。2-12、什么是需求變更？答：在需求管理中有解釋（后面章節(jié)）2-13、什么時候客戶和開發(fā)人員之間容易產(chǎn)生摩擦？答：更為重要的是簽名是建立在一個需求協(xié)議的基線上，因此在需求規(guī)格說明上的簽約應(yīng)該 這樣理解：“我同意這份文檔表述了目前我們對項目軟件需求的了解。進一步的變更可在此基 線上通過項目定義的變更過程來進行。我知道變更可能會使我們要重新協(xié)商成本、資源和項 目工期任務(wù)等”。2-14、設(shè)置基線的意義？答： 關(guān)于基線達成一定共識會易于忍受將來的摩擦，這些摩擦來源于項目的改進和需求的誤 差或市場和

8、業(yè)務(wù)的新要求等。給初步的需求開發(fā)工作畫上雙方都明確的句號會有助你形成一 個持續(xù)良好的客戶與開發(fā)人員的關(guān)系，為項目的成功奠定了基礎(chǔ)。2-15、為什么說“簽約”要把它作為項目的里程碑?！贝穑骸昂灱s”意味著什么應(yīng)該吧它作為項目的里程碑。對于簽字之前應(yīng)進行哪些活動，以及簽字對將來變更的影響，各方應(yīng)形成明確一致的理解。 習題一：1-0、系統(tǒng)項目涉眾？答： 客戶：投資項目或購買產(chǎn)品的部門或人員。 開發(fā)人員：設(shè)計、實現(xiàn)和維護該產(chǎn)品。 用戶： 使用該產(chǎn)品的部門或人員。 測試人員：確定產(chǎn)品的行為是否與預(yù)計的相一致。 需求分析員：負責編寫需求并傳達給開發(fā)團隊 。 文檔編制人員：負責編寫用戶手冊、培訓資料和系統(tǒng)幫助

9、。 項目經(jīng)理：制定項目計劃并帶領(lǐng)開發(fā)人員獲得成功。 法律人員：確保產(chǎn)品符合所有相關(guān)法規(guī)。 生產(chǎn)人員：制造包含該軟件的產(chǎn)品。 市場營銷、技術(shù)支持及其他與產(chǎn)品和客戶打交道的人員。 1-1、什么是軟件需求？答： IEEE軟件工程標準詞匯表（ 1997年）中定義需求為： （1）用戶解決問題或達到目標所需的條件或權(quán)能（ Capability）。 （2）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的 條件或權(quán)能。 （3）一種反映上面（ 1）或（ 2）所描述的條件或權(quán)能的文檔說明。1-2、什么是需求中的二義性，有什么危害？答：并沒有一個清晰、毫無二義性的“需求”術(shù)語存 在，真正的“需求”實

10、際上在人們的腦海中。任何文檔形式的需求（例如：需求規(guī)格說明）僅是一個模型，一種敘述我們需要確保所有項目風險承擔者在描述需求 的那些名詞的理解上務(wù)必達成共識。危害的解釋，請參看1-11的解釋。1-3、什么是系統(tǒng)的行為、特性和屬性？答：所謂特性 (feature)是指邏輯上相關(guān)的功能需求的集合，給用戶 提供處理能力并滿足業(yè)務(wù)需求。1-4、軟件需求包括哪些主要層次？答：軟件需求包括三個不同的層次業(yè)務(wù)需求、用戶需求和功能需求也包括非功能需求。 1-5、什么是業(yè)務(wù)需求、用戶需求和功能需求？答：業(yè)務(wù)需求（ business requirement）反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，它 們在

11、項目視圖與范圍文檔中予以說明。用戶需求 (userrequirement) 文檔描述了用戶使用產(chǎn)品 必須要完成的任務(wù)，這在使用實例（ use case ）文檔或方案腳本（ scenario）說明中予以說明。功能需求 (functional requirement) 定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們 的任務(wù)，從而滿足了業(yè)務(wù)需求。1-6、什么是需求特性、什么是軟件系統(tǒng)的外部行為。答：所謂特性 (feature)是指邏輯上相關(guān)的功能需求的集合，給用戶 提供處理能力并滿足業(yè)務(wù)需求。1-7、什么是軟件需求規(guī)格說明？答：軟件需求規(guī)格說明在開發(fā)、測試、質(zhì)量保證、項目管理以及相關(guān)項目功能中

12、都起了重要的作用。作為功能需求的補充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標準、規(guī)范和合約；外部界面的具體細 節(jié)；性能要求；設(shè)計或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。1-8、什么是產(chǎn)品必須遵從的標準、規(guī)范和合約。答：參看上題的解釋。1-9、需求與軟件項目開發(fā)中的哪些環(huán)節(jié)有關(guān)系？哪些開發(fā)環(huán)節(jié)關(guān)系不大？答：項目也有其它方面的需求， 如開發(fā)環(huán)境需求或發(fā)布產(chǎn)品及移植到支撐環(huán)境的需求。盡管這些需求對項目成功也至關(guān)重要， 但它們并非本書所要討論的。1-10、什么是不適當?shù)男枨筮^程所引起的風險？答：不適當?shù)男枨筮^程所引起的一些風險 用戶不多導(dǎo)致產(chǎn)品無法被

13、接受。 用戶需求的增加帶來過度的耗費和降低產(chǎn)品的質(zhì)量。 模棱兩可的需求說明可能導(dǎo)致時間的浪費和返工。 用戶增加一些不必要的特性和開發(fā)人員畫蛇添足 (gold-plating)。 過分簡略的需求說明以致遺漏某些關(guān)鍵需求。 忽略某類用戶的需求將導(dǎo)致眾多客戶的不滿。 不完善的需求說明使得項目計劃和跟蹤無法準確進行。1-11、什么是模棱兩可的需求和不必要的特性？答：模棱兩可是需求規(guī)格說明中最為可怕的問題 (Lawrence 1996) 。它的一層含義是指諸多讀 者對需求說明產(chǎn)生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需 求說明. 模棱兩可的需求會使不同的風險承擔者產(chǎn)生不同的期望，

14、它會使開發(fā)人員為錯誤問題而 浪費時間，并且使測試者與開發(fā)者所期望的不一致。 模棱兩可的需求帶來不可避免的后果便是返工重做一些你認為已做好的事情。 處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。1-12、項目開發(fā)中的返工會給項目開發(fā)帶來哪些影響？答：參看上題的解釋。1-13、什么是高質(zhì)量的需求？答：實行有效的需求工程管理的組織能獲得多方面的好處。最大的好處是在開發(fā)后期和整個 維護階段的重做的工作大大減少了。正確的需求過程強調(diào)產(chǎn)品開發(fā)中的通力合作，包括在整個項目過程中多方風險承擔者的 積極努力。1-14、什么是優(yōu)秀需求具有的特性？答： 需求說明的特征 1. 完整性 每一項需求都必

15、須將所要實現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設(shè)計和實現(xiàn)這些功能所需的所有必要信息。 2. 正確性 每一項需求都必須準確地陳述其要開發(fā)的功能。做出正確判斷的參考是需求的來源，3. 可行性 每一項需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實施的。 4.必要性 每一項需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標準記錄下來。 5. 劃分優(yōu)先級 給每項需求、特性或使用實例分配一個實施優(yōu)先級以指明它在特定產(chǎn)品中所占的分量。 6.無二義性 對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋， 7. 可驗證性 檢查一下每項需求是否能通過設(shè)計測試用例或其它的驗證方法。1-15、什么需求規(guī)格說明的特點？答

16、：1. 完整性 不能遺漏任何必要的需求信息。遺漏需求將很難查出。 2. 一致性 一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務(wù)）需求不相矛盾。 3. 可修改性 在必要時或為維護每一需求變更歷史記錄時，應(yīng)該修訂 SRS。 4. 可跟蹤性 應(yīng)能在每項軟件需求與它的根源和設(shè)計元素、源代碼、測試用例之間建立起鏈接鏈，1-16、需求開發(fā)活動包括那幾方面？答:需求開發(fā)可進一步分為：問題獲取（e l i c i t a t i o n ）、分析 ( a n a l y s i s ) 、編寫規(guī)格說明 （specification）和驗證（ verification）四個階段（ Thayer and Dorfma

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

18、答：參看有關(guān)章節(jié)的解釋，1-18、需求開發(fā)與需求管理他們之間的關(guān)系及區(qū)別？答：1-19、需求管理活動包括那幾方面？答：通常的需求管理活動包括： 定義需求基線（迅速制定需求文檔的主體） 評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。 以一種可控制的方式將需求變更融入到項目中。 使當前的項目計劃與需求一致。 估計變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾（約定）。 讓每項需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤。 在整個項目過程中跟蹤需求狀態(tài)及其變更情況。1-20、為什么說軟件項目中百分之四十至六十的問題都是在需求分析階段埋下的“禍根”。答：不適當?shù)男枨筮^程所引起

19、的一些風險 用戶不多導(dǎo)致產(chǎn)品無法被接受。 用戶需求的增加帶來過度的耗費和降低產(chǎn)品的質(zhì)量。 模棱兩可的需求說明可能導(dǎo)致時間的浪費和返工。 用戶增加一些不必要的特性和開發(fā)人員畫蛇添足 (gold-plating)。 過分簡略的需求說明以致遺漏某些關(guān)鍵需求。 忽略某類用戶的需求將導(dǎo)致眾多客戶的不滿。 不完善的需求說明使得項目計劃和跟蹤無法準確進行。1-21、為是要把軟件需求，作為一門重要的課程來學習？說明原因。答：根據(jù)自己學習中的體會、感受，做出解答。習題1414-1、設(shè)定需求優(yōu)先級有什么作用？答：建立每個功能的相對重要性有助于你規(guī)劃軟件的構(gòu)造，以最少的費用提 供產(chǎn)品的最大功能。如果你正在做時間盒圖

20、或者進行漸增式開發(fā)，那么設(shè)定優(yōu)先級就特別重 要，因為在這些開發(fā)中，交付進度安排很緊迫并且不可改變?nèi)掌?，你需要排除或推遲一些不重要的功能。 一個項目經(jīng)理必須權(quán)衡合理的項目范圍和進度安排、預(yù)算、人力資源以及質(zhì)量目標的約 束。一個實現(xiàn)這種權(quán)衡的方法是：當接受一個新的高優(yōu)先級的需求或者其它項目環(huán)境變化時， 刪除低優(yōu)先級的需求，或者把它們推遲到下一版本中去實現(xiàn)。如果客戶沒有以重要性和緊迫 性來區(qū)分它們的需求，那么項目經(jīng)理就必須自己作出決策。由于客戶可能不贊成項目經(jīng)理所 設(shè)定的優(yōu)先級，所以客戶必須指明哪些需求必須包括在首發(fā)版中，而哪些需求可以延期實現(xiàn)。 當你有很多選擇可以完成一個成功的產(chǎn)品時，應(yīng)盡早在項目

21、中設(shè)定其優(yōu)先級。14-2、需求優(yōu)先級中有哪些規(guī)則？答：在設(shè)定優(yōu)先級的過程中典型的參與者有： 項目經(jīng)理、他指導(dǎo)全過程，解決沖突，并且在必要的時候調(diào)整其它參與者的方案。 重要的客戶代表，例如產(chǎn)品的代表者，他可以提供受益和損失程度。 開發(fā)者代表，例如開發(fā)組的技術(shù)指導(dǎo)者，他提供了費用和風險程度。 你必須遵循如下步驟來使用這個優(yōu)先級設(shè)定工具：1) 在一個平面中列出你要設(shè)定優(yōu)先級的所有 需求、特性或使用實例；2) 估計每一個特性提供給客戶或業(yè)務(wù)的相關(guān)利益，并用 19劃分等級， 1代表可忽略的利 益， 9代表最大的價值。3) 估計出如果沒有把應(yīng)該實現(xiàn)的特性包括到產(chǎn)品中，將會給客戶或業(yè)務(wù)上帶來的損失。4) 總

22、價值欄是相對利潤和相對損失的總和。5) 估計實現(xiàn)每個特性的相對費用，使用 1（低） 9（高）劃分等級。6) 類似地，開發(fā)者應(yīng)該要估計出與每個特性相關(guān)的技術(shù)或風險相對程度，并利用 19劃分 等級。7) 一旦把所有的估算寫入平面圖，你就可以利用如下公式計算出每一特性的優(yōu)先級： 價值% 優(yōu)先級 = （費用 %×費用權(quán)值） +（風險 %×風險權(quán)值）8) 按計算出的優(yōu)先級的降序排列表中的特性。14-3、優(yōu)先級中的等級有什么作用？答： 一個項目經(jīng)理必須權(quán)衡合理的項目范圍和進度安排、預(yù)算、人力資源以及質(zhì)量目標的約 束。一個實現(xiàn)這種權(quán)衡的方法是：當接受一個新的高優(yōu)先級的需求或者其它項目環(huán)境

23、變化時， 刪除低優(yōu)先級的需求，或者把它們推遲到下一版本中去實現(xiàn)。如果客戶沒有以重要性和緊迫 性來區(qū)分它們的需求，那么項目經(jīng)理就必須自己作出決策。由于客戶可能不贊成項目經(jīng)理所 設(shè)定的優(yōu)先級，所以客戶必須指明哪些需求必須包括在首發(fā)版中，而哪些需求可以延期實現(xiàn)。 當你有很多選擇可以完成一個成功的產(chǎn)品時，應(yīng)盡早在項目中設(shè)定其優(yōu)先級。14-4、為什么要根據(jù)價值、成本和風險來設(shè)定優(yōu)先級？答：客戶和開發(fā)者都必須為設(shè)定需求的優(yōu)先級提供信息。客戶總是讓可以給他們帶來最大利 益的需求享有最高優(yōu)先級。然而，一旦開發(fā)者指出費用、難度、技術(shù)風險，或其它與特定需 求相關(guān)的權(quán)衡時，客戶可能會覺得他們最初所想的需求似乎變得不

24、必要了。開發(fā)者也可能認 為在早期階段必須先實現(xiàn)那些優(yōu)先級較低的功能，因為它們會影響系統(tǒng)的體系結(jié)構(gòu)。設(shè)定優(yōu) 先級意味著權(quán)衡每個需求的業(yè)務(wù)利益和它的費用，以及它所牽涉到的結(jié)構(gòu)基礎(chǔ)和產(chǎn)品的未來 評價。14-5、你學會了用電子數(shù)據(jù)表（矩陣）模型設(shè)定需求優(yōu)先級了嗎？答：參見書上的內(nèi)容。練習15:15-1、為什么說需求確認是需求開發(fā)過程的第四個階段，那么前3個分別是什么？答：需求驗證是需求開發(fā)的第四部分（其余三個為獲取、分析和編寫規(guī)格說明） 。驗證決定了開發(fā)成的產(chǎn)品 是否能滿足開始時所確定的需求（即正確完成任務(wù)）。15-2、需求確認活動應(yīng)包括那幾點？答：我采用 IEEE的術(shù)語“驗證”。所包括的活動是為了確

25、定以下幾方面的內(nèi)容： 軟件需求規(guī)格說明正確描述了預(yù)期的系統(tǒng)行為和特征。 從系統(tǒng)需求或其它來源中得到軟件需求。 需求是完整的和高質(zhì)量的。 所有對需求的看法是一致的。 需求為繼續(xù)進行產(chǎn)品設(shè)計、構(gòu)造和測試提供了足夠的基礎(chǔ)。15-3、需求確認活動的特征？答：需求驗證確保了需求符合需求陳述（ requirement statement）的良好特征（完整的、正確的、靈活的、必要的、具有優(yōu)先級的、無二義行及可驗證的）并且符合需求規(guī)格說明的良好 特性（完整的、一致的、易修改的、可跟蹤的）。當然，你只能驗證那些已編寫成文檔的需求， 而那些存在于用戶或開發(fā)者思維中的沒有表露的、含蓄的需求則不予驗證。使用不同的技術(shù)

26、有助于你驗證需求的正確性及其質(zhì)量。更好的需求將會帶來更好的產(chǎn)品質(zhì)量和客戶更 大的滿意程度，這可以降低產(chǎn)品生存期中的維護、增強和客戶支持的費用。在需求質(zhì)量上的 投資可以使你節(jié)省更多的錢。15-4、什么是需求評審？答：需求文檔的評審是一項精益求精的技術(shù)，它可以發(fā)現(xiàn)那些二義性的或不確定的需求、 那些由于定義不清而不能作為設(shè)計基礎(chǔ)的需求，還有那些實際上是設(shè)計規(guī)格說明的所謂的 “需求”。 需求評審也為風險承擔者們提供了在特定問題上達成共識的方法。不同種類的技術(shù)評審具有不同的稱謂。15-5、非正式評審方法有哪些？答：非正式評審方法包括： 。同級桌面檢查 這種方法是請某一位同事檢查工作產(chǎn)品。 。輪查 這種方

27、法是同時請若干同事分別檢查可交付產(chǎn)品。 。走查 這種方法是可交付產(chǎn)品的作者向評審人員描述該產(chǎn)品并請求做出評論。15-6、非正式評審與正式評審有什么不同？答： 非正式評審可以根據(jù)個人愛好的方式進行評審，而正式評審則遵循預(yù)先定義好的一系列 步驟過程。正式評審內(nèi)容需要記錄在案，它包括確定材料、評審員、評審小組對產(chǎn)品是否完 整或是否需要進一步工作的判定，以及對所發(fā)現(xiàn)的錯誤和所提出的問題的總結(jié)。正式評審小 組的成員對評審的質(zhì)量負責，而開發(fā)者則最終對他們所開發(fā)的產(chǎn)品的質(zhì)量負責，正式技術(shù)評審的最好類型叫作審查。15-7、審查過程大致包含那幾些內(nèi)容？答：參見15-8的解釋，15-8、對需求文檔審查的標準有哪些

28、？答：下面列出一些對需求文檔開始審查的建議性標準： 。文檔遵循標準模板。 。文檔已經(jīng)進行拼寫檢查。 。作者已經(jīng)檢查了文檔在版面布局上所存在的錯誤。 。已經(jīng)獲得了審查員檢查文檔所需要的先前文檔或參考文檔。 。在文檔中標上了行序號，這樣可以便于在審查會上對待定位置的內(nèi)存進行查閱。 。所有未解決的問題都要標記為TBD(待確定）。 。仲裁者對具有代表性的需求范例檢查10分鐘后，找不出3個以上的重大缺陷。需求文檔審查的標準： 文檔符合標準模板。 文檔已經(jīng)做過拼寫檢查和語法檢查。 作者已經(jīng)檢查了文檔在版面安排上所存在的錯誤。 已經(jīng)獲得了審查員所需要的先前或參考文檔，例如系統(tǒng)需求規(guī)格說明。 在文檔中打印了行

29、序號以方便在審查中對特定位置的查閱。 所有未解決的問題都被標記為 TBD（待確定）。 包括了文檔中使用到的術(shù)語詞匯表。 相似地，在調(diào)解者宣布審查結(jié)束之前，你應(yīng)該定義所滿足的退出審查的標準。這里有一些關(guān)于需求文檔的退出標準： 已經(jīng)明確闡述了審查員提出的所有問題。 已經(jīng)正確修改了文檔。 修訂過的文檔已經(jīng)進行了拼寫檢查和語法檢查。 所有 TBD的問題已經(jīng)全部解決，或者已經(jīng)記錄下每個待確定問題的解決過程，目標日期 和提出問題的人。 文檔已經(jīng)登記入項目的配置管理系統(tǒng)。 檢查是否已將審查過的資料送到有關(guān)收集處。15-9、需求評審面臨的困難有哪些？答： 1) 大型的需求文檔 審查一份幾百頁的軟件需求規(guī)格說明

30、是令人畏懼的。 2) 龐大的審查小組 許多項目參與者和客戶都與需求有關(guān)系，3) 審查員在地域上的分散 越來越多的公司正通過地域上分散的開發(fā)組進行合作開發(fā)產(chǎn)品。15-10、什么叫測試用例和測試路徑？答：1) 業(yè)務(wù)需求 該系統(tǒng)的一個主要業(yè)務(wù)動機可以用如下的需求來描述；2) 使用實例 與這個業(yè)務(wù)需求相一致的一個使用實例； 3) 功能性需求 以下是關(guān)于讓用戶選擇可用的化學制品的一些功能，而不是向外部供應(yīng)商 發(fā)送訂單；4) 對話圖（ dialog map） 使用實例中關(guān)于這一功能 的部分對話圖。5) 測試用例（ test case） 由于這個使用實例有許多可能的執(zhí)行路徑，所以你可以想出許 多測試用例來闡

31、明普通過程、可選過程和例外。15-11、為什么說需求與測試是一種協(xié)作關(guān)系？答：驗收測試重點應(yīng)該測試用例的主干過程，而不應(yīng)該是那些不常使用的分支過程，或系統(tǒng)是否對每一種異常條件都作了恰當?shù)奶幚怼?用戶驗收測試并不能取代基于需求的全面的系統(tǒng)測試，因為系統(tǒng)測試既覆蓋了正常路徑，也覆蓋了異常路徑，而且是通過各種數(shù)據(jù)組合來進行測試的。15-12、什么是測試需求？答：驗收測試也該測試非功能性需求，這些非功能性測試可以確保產(chǎn)品是否在所有平臺都達到了其性能目標、系統(tǒng)是否遵從了易使用性標準，以及提交的全部用戶需求是否都已實現(xiàn)等。15-13、用例與測試用例有什么區(qū)別？答：在開發(fā)過程中，用戶越早編寫驗收測試，就能夠

32、越快地發(fā)現(xiàn)需求中的缺陷和要實現(xiàn)的軟件中的缺陷。測試用例是為了測試系統(tǒng)編寫的用例，而用例一般指在需求分析過程中編寫的用例。15-14、怎樣制定驗收標準？答：讓客戶開發(fā)驗收標準為確認最重要的需求提供了另一種機會。這是一種角度的轉(zhuǎn)移，即從需求獲取階段提出“你想讓系統(tǒng)做什么？”轉(zhuǎn)移到了“如何判斷系統(tǒng)是否滿足你的需求？”如果客戶并不能表達出如何評估系統(tǒng)是否滿足某一特定的需求，那么就說明這條需求陳述得還不夠清晰。 僅編寫需求還不夠，還需要確保所編寫的需求是恰當合理的需求，而且這些需求可以為后續(xù)的設(shè)計、構(gòu)造、測試和項目管理奠定良好的基礎(chǔ)。驗收測試計劃、非正式評估、軟件需求規(guī)格說明審查和需求測試等技術(shù)，都有助

33、于我們更快速更廉價地構(gòu)建出高質(zhì)量的系統(tǒng)。15-15、驗收測試的重點是什么？答：驗收測試的重點應(yīng)該是測試預(yù)期的使用場景。在決定如何評估軟件的可接受性時，關(guān)鍵的用戶應(yīng)該考慮那些最常用的和最重要的用例。驗收測試重點應(yīng)該測試用例的主干過程，而不應(yīng)該是那些不常使用的分支過程，或系統(tǒng)是否對每一種異常條件都作了恰當?shù)奶幚怼Ａ曨}18：18-1、需求管理強調(diào)： 控制對需求基線的變動。 保持項目計劃與需求一致。 控制單個需求和需求文檔的版本情況。 管理需求和聯(lián)系鏈之間的聯(lián)系或管理單個需求和其它項目可交付品之間的依賴關(guān)系。 跟蹤基線中需求的狀態(tài)。18-2、項目的響應(yīng)方式有多種： 推遲實現(xiàn)優(yōu)先級低的需求。 增派人手。

34、 短時間的突擊加班，最好是有償加班。 為了滿足新功能，推遲產(chǎn)品的交付日期。保持產(chǎn)品交付日期不變，但在質(zhì)量上打些折扣。這也是需求變更之后項目通常采取的反應(yīng)方式，雖然這樣做并不可取。18-3、18-4、需求基線定義：18-5、CMM答：過程能力成熟度模型（ Capability Maturity Model ，CMM）18-6、需求管理的目標 ：答： 1) 把軟件需求建立一個基線供軟件工程和管理使用。 2) 軟件計劃，產(chǎn)品和活動同軟件需求保持一致。 需求管理的關(guān)鍵過程領(lǐng)域不涉及收集和分析項目需求。18-7、軟件開發(fā)計 劃是基于已確認的需求。答： 開發(fā)團隊在向客戶、市場部或經(jīng)理們作出承諾（ comm

35、itment）之前，應(yīng)該確認需求和確 認約束條件、風險、偶然因素、假定條件。也許不得不面對由于技術(shù)因素或進度原因而不現(xiàn) 實的需求作出 承諾。但是，決不要承諾任何無法實現(xiàn)的事。18-8、版本控制 關(guān)鍵處理領(lǐng)域同樣建議通過版本控制和變更控制來管理需求文檔。版本控制確保隨時能 知道在開發(fā)和計劃中正在使用的需求的版本情況。變更控制提供了支配下的規(guī)范的方式來統(tǒng) 一需求變更，并且基于業(yè)務(wù)和技術(shù)的因素來同意或反對建議的變更。當在開發(fā)中修改、增加、 減少需求時，軟件開發(fā)計劃應(yīng)該隨時更新以與新的需求保持一致。不反映現(xiàn)實的計劃于事無 補。18-9、通過如下方法 能使項目反映最新的或變更過的需求。 暫時擱置次要需求

36、。 得到一定數(shù)量的后備人員。 短期內(nèi)帶薪加班處理。 將新的功能排入進度安排。 為了保證按時交工使質(zhì)量受些必要的影響（通常，這是缺省反應(yīng)）。 由于項目在特性、進度、人員、預(yù)算、質(zhì)量各個方面的要求不同，所以不存在一個放之四海皆準的模式。18-10、需求管理步驟（過程）答： 用于控制各種需求文檔和單個需求版本的工具、技術(shù)和習慣做法。 建議、處理、協(xié)商、通告新的需求和變更給有關(guān)的功能域的方法。 如何制定需求基線。 將使用的需求狀態(tài)，并且是誰允許作出的變更。 需求狀態(tài)跟蹤和報告過程。 分析已建議變動的影響應(yīng)遵循的步驟。 在何種情況下需求變更將會怎樣影響項目計劃和約定。18-11、需求規(guī)格說明的版本控制答

37、： 版本控制是管理需求的一個必要方面。需求文檔的每一個版本必須被統(tǒng)一確定。組內(nèi)每 個成員必須能夠得到需求的當前版本，必須清楚地將變更寫成文檔，并及時通知到項目開發(fā) 所涉及的人員。為了盡量減少困惑、沖突、誤傳，應(yīng)僅允許指定的人來更新需求。18-12、需求屬性答： 除了文本，每個功能需求應(yīng)該有一些相關(guān)的信息或稱之為屬性與之相聯(lián)系。這些屬性在 它的預(yù)期功能性之外為每個需求建立了一個上下文和背景資料。屬性值可以寫在一張紙上， 存儲在一個數(shù)據(jù)庫或需求管理工具中。商業(yè)工具除由系統(tǒng)產(chǎn)生一些屬性外，還可以由你自己 定義各種數(shù)據(jù)類型的其它屬性。這些工具允許過濾、排序、查詢數(shù)據(jù)庫來察看按選擇的需求 屬性的需求集。

38、在你的每個需求文檔中考慮明 確如下的屬性： 創(chuàng)建需求的時間 需求的版本號 創(chuàng)建需求的作者 負責認可該需求的人員 需求狀態(tài) 需求的原因或根據(jù)（或信息的出處） 需求涉及的子系統(tǒng) 需求涉及的產(chǎn)品版本號 使用的驗證方法或接受的測試標準 產(chǎn)品的優(yōu)先級或重要程度（例如高、中、低或把你能定義的屬性來表示成本書第 13章所 描述的優(yōu)先級的四個方面：收益、損失、成本、風險） 需求的穩(wěn)定性（在將來需求可能變更的指示器，不穩(wěn)定的需求意味你應(yīng)給予較多的關(guān)注，因為你將面臨不定的、混沌的、或不能重復(fù)的業(yè)務(wù)過程。）18-13、跟蹤需求狀態(tài) 答：在整個開發(fā)過程中，跟蹤每個需求的狀態(tài)是需求管理的一個重要方面（ Caputo 1

39、998）。在 每一可能的狀態(tài)類別中，如果你周期性地報告各狀態(tài)類別在整個需求中所占的百分比將會改進項目的監(jiān)控工作。假如你有清晰的要求，指定了允許修改狀態(tài)信息的人員和每個狀態(tài)變更 應(yīng)滿足的條件，跟蹤需求狀態(tài)才能正常工作。工具能幫你跟蹤每次狀態(tài)改變的日期。18-14、需求管理的下列活動的效果： 提出需求變更和已建議的新需求。 評估已建議的變更，包括影響分析。 變更控制委員會活動。 更新需求文檔或數(shù)據(jù)庫。 在涉及人員或團隊中交流需求的變更。 跟蹤和報告需求狀態(tài)。 定義和更新需求跟蹤能力信息。習題19：19-1、變更控制應(yīng)注意的事項？答： 應(yīng)仔細評估已建議的變更。 挑選合適的人選對變更做出決定。 變更應(yīng)

40、及時通知所有涉及的人員。 項目要按一定的程序來采納需求變更。只有項目風險承擔者在開發(fā)過程中能控制變更，他們才知道將交付什么，哪一項將會導(dǎo)致與目標的差距。當你不得不做出變更時，應(yīng)該按從高級到低級的順序?qū)Ρ挥绊懙男枨笪臋n進行處理。19-2、控制項目范圍的擴展答：擴展需求是指在軟件需求基線已經(jīng)確定后又要增添新的功能 或進行較大改動。問題不僅僅是需求變更本身，而是遲到的需求變更會對已進行的工作有較 大的影響。要是每個建議的需求都被采納，對于項目出資者（ sponsor）、參與者與客戶來說項 目將永遠也不會完成事實上，這是不可能的。所以必須進行項目范圍的控制。 管理范圍擴展的第一步就是把新系統(tǒng)的視圖、范圍、限制文檔化并作為業(yè)務(wù)需求的一部 分， 控制需求擴展的另一個有效的技術(shù)是 原型法， 控制范圍的擴展的方法是要敢于說“不”。19-3、變更控制過程答： 一個好的變更控制過程給項目風險承擔者提供了正式的建議需求變更機制。通過變更控制過程來跟蹤已建議變更的狀態(tài)，確保不會 丟失或疏