軟件需求習(xí)題集(共23頁)

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

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

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

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

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

6、 現(xiàn)變更。2-10、什么是需求協(xié)議的基線？答：可參看2-11的答案。2-11、怎樣設(shè)置基線？答：設(shè)置基線是很有意義的，它能給所有主要的涉眾帶來信心： 客戶管理層相信項(xiàng)目的范圍不會(huì)過度膨脹直至失控,因?yàn)榭蛻粽莆樟朔秶兏臎Q定權(quán). 用戶代表有信心開發(fā)團(tuán)對會(huì)跟他們一同努力開發(fā)出符合需求的系統(tǒng),即便他們不能在系統(tǒng)開始構(gòu)建之前想到所有的需求. 開發(fā)管理人員有信心，因?yàn)殚_發(fā)團(tuán)隊(duì)有了業(yè)務(wù)伙伴。業(yè)務(wù)伙伴能夠保證項(xiàng)目的中心工作集中在業(yè)務(wù)目標(biāo)上。他們將與開發(fā)人員一起在進(jìn)度、成本、功能和質(zhì)量之間做出平衡。 需求分析員也充滿信心，因?yàn)樗麄兛梢杂行У毓芾眄?xiàng)目的變更，將變更引起的麻煩減至最小。 用明確的協(xié)議來結(jié)束前期是

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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