1、文檔編碼 : CY8A3C7Y9C1 HN8E5X1C9C8 ZH6J2V5X4F1軟件需求（第 2 版）教案 陶錚 2022 年 3 月 目錄 1 軟件需求基礎(chǔ)學(xué)問 . 2軟件需求的定義 . 2對(duì)需求的不同說明 . 3需求的層次 . 3不屬于需求的內(nèi)容 . 6需求的開發(fā)與治理 . 6需求開發(fā) . 6需求治理 . 7全部項(xiàng)目都有需求 . 8優(yōu)秀的團(tuán)隊(duì)遇到糟糕的需求 . 8用戶參加不足 . 9用戶需求擴(kuò)展 . 9有歧義的需求 . 10 鍍金問題 . 10 過于抽象的需求 . 10 忽視了某類用戶 . 10 不精確的方案 . 10 優(yōu)質(zhì)需求過程的好處 . 11 優(yōu)秀需求的特點(diǎn) . 11 需求陳述的

2、特點(diǎn) . 11 需求規(guī)格說明的特點(diǎn) . 13 第 1 頁,共 13 頁1 軟件需求基礎(chǔ)學(xué)問 章首案例的概括總結(jié)見課件； 本章要點(diǎn)： （1）需求的重要性 軟件問題主要在于需求： 很多軟件問題都源于收集, 記錄, 協(xié)商和修改產(chǎn)品需求過 程中的方式不當(dāng)； 包括信息收集方式不正規(guī), 沒有明確提出想要的功能, 連假設(shè)也 是未經(jīng)溝通的錯(cuò)誤假設(shè), 需求的定義不夠充分, 以及未經(jīng)認(rèn)真考慮進(jìn)行需求變更等 ； 需求問題造成很大的麻煩： 失所致； 軟件項(xiàng)目中 40% 60% 的缺陷都是由需求分析階段的過 需求問題, 一是輕視, 而是不得方法： 很多組織仍舊沒有實(shí)行有效手段來實(shí)施這兩 個(gè)必要的項(xiàng)目活動(dòng)；由此導(dǎo)致的結(jié)果

3、是用戶和開發(fā)者之間產(chǎn)生需求的鴻溝； （2）軟件項(xiàng)目學(xué)問項(xiàng)目涉眾 客戶：為達(dá)到其公司的業(yè)務(wù)目標(biāo)而投資項(xiàng)目或購買產(chǎn)品； 用戶：直接或間接與產(chǎn)品打交道,是客戶的一部分； 需求 分析員：負(fù)責(zé)編寫需求并傳達(dá)給開發(fā)團(tuán)隊(duì)； 開發(fā)人員：設(shè) 計(jì),實(shí)現(xiàn)和愛惜產(chǎn)品； 測(cè)試人員：確定產(chǎn)品的行為是否與 估量的相一樣； 文檔編制人員：負(fù)責(zé)編寫用戶手冊(cè),培訓(xùn) 資料和系統(tǒng)幫忙； 項(xiàng)目經(jīng)理：制定項(xiàng)目方案并帶領(lǐng)開發(fā)人 員獲得勝利； 法律人員：確保產(chǎn)品符合全部相關(guān)法規(guī)； 生 產(chǎn)人員：制造包含該軟件的產(chǎn)品； 市場營銷,技術(shù)支持及其它與產(chǎn)品和客戶打交道的人員； 懂得涉眾,關(guān)鍵在于“只有涉眾承諾遵循有效的需求過程,才能為軟件開發(fā)和項(xiàng)目治

4、理 活動(dòng)奠定基礎(chǔ)； 本章講授內(nèi)容： 軟件需求工程的一些重要術(shù)語； 需求開發(fā)與需求治理； 留意潛 在的與需求相關(guān)的問題； 完善的需求應(yīng)當(dāng)具備哪些特點(diǎn)； 軟件需求的定義 術(shù)語紛亂： 用戶需求,軟件需求,功能需求,系統(tǒng)需求,技術(shù)需求,業(yè)務(wù)需求或產(chǎn)品需求； 第 2 頁,共 13 頁一般的誤會(huì) : 開發(fā)人員看到客戶對(duì)需求說法,認(rèn)為只是高級(jí)別的產(chǎn)品概念； 用戶看到的開發(fā)人員的需求描述,認(rèn)為是用戶界面設(shè)計(jì)； 需求定義,即用文字進(jìn)行規(guī)范地,正確地,完整地描述； 對(duì)需求的不同說明 需求的幾種定義,都很有參考價(jià)值； 需求必需被記錄成文檔； 1. 詢問專家 Brian Lawrcnce 提出, 需求是 “任何促成設(shè)

5、計(jì)決策的因素 ”；很多信息都 屬于這一范疇； 2. IEEE 的軟件工程標(biāo)準(zhǔn)術(shù)語表（ 199就將需求定義為： 用戶為解決某個(gè)問題或達(dá)到某個(gè)目標(biāo)而需具備的條件或才能； 系統(tǒng)或系統(tǒng)組件為符合合同, 件或必需具備的才能； 標(biāo)準(zhǔn), 規(guī)范或其它正式文檔而必需中意的條 上述第一項(xiàng)或其次項(xiàng)中定義的條件和才能的文檔表達(dá)； 3. 作者對(duì)需求的懂得： 需求是產(chǎn)品為向涉眾供應(yīng)價(jià)值而必需具備的特性； 4. 需求類型的多樣性（ Sommerville 和 Sawyer 1997 ）： 需求是 對(duì)應(yīng)當(dāng)實(shí)現(xiàn)什么 功能的說明 可以是對(duì)系統(tǒng)運(yùn)行方式或系統(tǒng)特點(diǎn)與屬性的描述； 仍可能是對(duì)系統(tǒng) 開發(fā)過程的約束； 需求的層次 本節(jié)的內(nèi)

6、容特殊重要；需求工程領(lǐng)域一些常用術(shù)語的定義； 軟件需求包括 3 個(gè)不同的層次： 1. 業(yè)務(wù)需求 2. 用戶需求 3. 功能需求 ；除此之外,每個(gè)系統(tǒng)仍有各種非功能需求； 重要： 圖 1-1 中的模型給出了各種需求關(guān)系的示意圖； 圖中的橢圓代表各類需求信息, 矩形就是儲(chǔ)備這些信息的載體 （文檔, 圖形或數(shù)據(jù)庫） ； 第 3 頁,共 13 頁圖 1-1 各種需求的關(guān)系圖 注：第 7 章中介紹了各種需求的示例； 三大需求 1. 業(yè)務(wù)需求（ Business requirement ）表示組織或客戶高層次的目標(biāo)； 業(yè)務(wù)需求通常來自項(xiàng)目的 或產(chǎn)品策劃部門； 投資人 ,購買產(chǎn)品的 客戶 ,實(shí)際 用戶的治理

7、者 ,市場營銷部門 業(yè)務(wù)需求描述了 組織為什么要開發(fā)一個(gè)系統(tǒng),即組織期望達(dá)到的目標(biāo) ； 本書規(guī)定 用前景和范疇（ vision and scope ）文檔來記錄業(yè)務(wù)需求 ；見 第 5 章的主題 （作 為試驗(yàn) 3 內(nèi)容）； 任務(wù)是：定義項(xiàng)目范疇 （隨后會(huì)發(fā)生如何把握范疇擴(kuò)大的問題）； 2.用戶需求（ user requirement 須能完成的任務(wù)； ）描述的是用戶的目標(biāo),或用戶要求系統(tǒng)必 用戶需求描述的是軟件使用者 （用戶）使用系統(tǒng)能夠完成什么業(yè)務(wù)任務(wù)或信息處理工作； 具體內(nèi)容是 用例,場景描述和大事 -響應(yīng)表等；見第 8 章（作為試驗(yàn) 4）； 3. 功能需求（ functional requ

8、irement ）規(guī)定開發(fā)人員必需在產(chǎn)品中實(shí)現(xiàn) 的軟件功能,用戶利用這些功能來完成那些中意業(yè)務(wù)需求的具體的任務(wù)； 功能需求有時(shí)也被稱作行為需求（ behavioral requirement ）,描述的是軟件的行為性活 動(dòng)； 功能需求描述的是開發(fā)人員需要實(shí)現(xiàn)什么 ；第 10 章將舉例說明這點(diǎn)； 如： “系統(tǒng)應(yīng)當(dāng)發(fā)送電子郵件來通知用戶己接受其預(yù)定 ”； 第 4 頁,共 13 頁術(shù)語 系統(tǒng)需求（ system requirement ） 用于描述包含多個(gè)子系統(tǒng)的產(chǎn)品（即系統(tǒng)）的頂級(jí)需求；系統(tǒng)可以只包含軟件子系統(tǒng), 也可以既包含軟件又包含硬件子系統(tǒng)； 由人來承擔(dān)； 業(yè)務(wù)規(guī)章 人也可以是系統(tǒng)的一部分,

9、 因此某些系統(tǒng)功能可能要 包括企業(yè)方針, 政府條例,工業(yè)標(biāo)準(zhǔn),會(huì)計(jì)準(zhǔn)就和運(yùn)算方法等；第 9 章中指出業(yè)務(wù)規(guī)章 本身并非軟件需求, 由于它們不屬于任何特定軟件系統(tǒng)的范疇； 然而, 業(yè)務(wù)規(guī)章常常會(huì)限制 誰能夠執(zhí)行某些特定用例, 或者規(guī)定系統(tǒng)為符合相關(guān)規(guī)章必需實(shí)現(xiàn)某些特定功能； 有時(shí), 功 能中特定的質(zhì)量屬性 （通過功能實(shí)現(xiàn)） 也源于業(yè)務(wù)規(guī)章； 所以, 對(duì)某些功能需求進(jìn)行追溯時(shí), 會(huì)發(fā)覺其來源正是一條特定的業(yè)務(wù)規(guī)章； 功能需求記錄在軟件需求規(guī)格說明 （ SRS）中；SRS 完整地描述了軟件系統(tǒng)的預(yù)期特性； SRS 仍可以是包含需求信息的數(shù)據(jù)庫或電子表格； 或者是儲(chǔ)備在商業(yè)需求治理工具 中的信息 （參

10、見第 21 章）,甚至可能是一疊索引卡片； SRS 對(duì)于軟件設(shè)計(jì), 開發(fā),測(cè)試,質(zhì)量保證,項(xiàng)目治理和其它相關(guān)的項(xiàng)目功能都十分重要； SRS 中仍包含 非功能需求,包括性能指標(biāo)和對(duì)質(zhì)量屬性的描述； 質(zhì)量屬性（ quality attribute ）對(duì)產(chǎn)品的功能描述作了補(bǔ)充,它從不同方面描述了產(chǎn) 品的各種特性；包括可用性,可移植性,完整性,效率和健壯性,仍包括系統(tǒng)外部界面,以 及對(duì)設(shè)計(jì)與實(shí)現(xiàn)的約束； 約束（ constraint ）限制了開發(fā)人員設(shè)計(jì)和構(gòu)建系統(tǒng)時(shí)的挑選范疇； 字處理程序的例子； 業(yè)務(wù)需求： “產(chǎn)品答應(yīng)用戶輕松地更正文檔中的拼寫錯(cuò)誤； 了拼寫檢查器這一功能特性； 用戶需求 ：包括 “

11、找出拼寫錯(cuò)誤 ”和 “把單詞添加到詞典中 ”因此該產(chǎn)品的包裝盒上列出 ”這樣一些任務(wù), 或者叫作用例； 功能需求： 如找到并突出顯示拼錯(cuò)的單詞, 用對(duì)話框顯示修改建議, 用正確的單詞替換 整篇文檔中同一單詞的全部拼寫錯(cuò)誤； 結(jié)合非功能需求,介紹： 可用性（ usability ）的質(zhì)量屬性,它規(guī)定了業(yè)務(wù)需求中 義； 增加的內(nèi)容： （1） 可用性指標(biāo) （2） 網(wǎng)站質(zhì)量評(píng)判要素 “有效 ”（ efficiently ）一詞的含 下面的內(nèi)容,分散到業(yè)務(wù)需求,用戶需求,功能需求中賜予提示： 治理人員或市場營銷人員負(fù)責(zé)定義軟件的業(yè)務(wù)需求, 以提高公司的運(yùn)營效率 （對(duì)信息系 統(tǒng)而言）或產(chǎn)品的市場競爭力（對(duì)

12、商業(yè)軟件而言）；全部的用戶需求都必需符合業(yè)務(wù)需求； 需求分析員從用戶需求中推導(dǎo)出產(chǎn)品應(yīng)具備哪些對(duì)用戶有幫忙的功能； 開發(fā)人員就依據(jù)功能 第 5 頁,共 13 頁需求和非功能需求設(shè)計(jì)解決方案, 在約束條件的限制范疇內(nèi)實(shí)現(xiàn)必需的功能, 并達(dá)到規(guī)定的 質(zhì)量和性能指標(biāo)； 圖 1-1 中的模型,需要強(qiáng)調(diào)： （ 1） 是一個(gè)自頂向下的單向需求流,沒能反映出業(yè)務(wù)需求,用戶需求與功能需求 之間可能存在的循環(huán)和迭代關(guān)系； （ 2） 范疇問題：當(dāng)一項(xiàng)新的特性,用例或功能需求被提出時(shí),需求分析員必需思 考這樣一個(gè)問題： “它在范疇內(nèi)嗎？ ”； （ 3） 不能確定的,必需由業(yè)務(wù)需求的負(fù)責(zé)人或投資治理人來預(yù)備：是否擴(kuò)大

13、項(xiàng)目 范疇以容納新的需求；這是一個(gè)可能影響項(xiàng)目進(jìn)度和預(yù)算的商業(yè)決策； 不屬于需求的內(nèi)容 主要指明：需求分析內(nèi)容不包含設(shè)計(jì)與實(shí)現(xiàn)技術(shù)的細(xì)節(jié)； 需求規(guī)格說明中不包括（除已知約束外的）設(shè)計(jì)和實(shí)現(xiàn)的細(xì)節(jié),項(xiàng)目的方案信息 ,以及 測(cè)試信息 （ Lcffngwcll 和 Widrig 2022 ）； 把這些內(nèi)容與需求分開,就可以把需求活動(dòng)的注 意力集中到明白開發(fā)小組需要開發(fā)的產(chǎn)品特性上 ；項(xiàng)目中通常仍包括其它類型的需求, 如開 發(fā)環(huán)境需求, 進(jìn)度或預(yù)算限制, 幫忙新用戶跟上進(jìn)度的培訓(xùn)需求, 或者發(fā)布產(chǎn)品使其轉(zhuǎn)入支 持環(huán)境的需求；這些都屬于項(xiàng)目需求而不是產(chǎn)品需求,因此不屬于本書爭論的范疇； 需求的開發(fā)與治理

14、 此部分內(nèi)容屬于軟件工程分支領(lǐng)域,是今后的課題； 需求領(lǐng)域的術(shù)語問題如此突出, 甚至對(duì)這門學(xué)科的稱呼都很紛亂； 有的作者稱其為需求 工程（ SommCrville 和 Kotonya 1998 ）；也有人稱之為需求治理 （ Leffngwell 和 Widrig2022）； 我找到一個(gè)好方法解決這個(gè)問題, 就是把軟件需求工程劃分為需求開發(fā) （本書第部分爭論 的內(nèi)容）和需求治理（在第部分爭論）,如圖 1-2 所示； 圖 1-2 軟件需求工程的組成 需求開發(fā) 此處內(nèi)容,作為本課程試驗(yàn) 3,4, 5 的過程要求 第 6 頁,共 13 頁要求在試驗(yàn)中體會(huì)下述活動(dòng)： 1. 確定你將要面對(duì)的各類用戶； （

15、非功 2. 明白用戶的業(yè)務(wù)學(xué)問和用戶的任務(wù)與目標(biāo)； 3. 分析自己獲得的信息, 把用戶任務(wù)目標(biāo)分解為用戶需求與與功能需求 能需求）； 4. 分析有關(guān)的質(zhì)量屬性及其重要性； 5. 編寫需求規(guī)格說明,協(xié)作模型的建立； 6. 批閱需求文檔,以確保在熟識(shí)上與用戶聲明的需求相一樣； 需求開發(fā)可進(jìn)一步細(xì)分為獵取（ 和確認(rèn)（ validation ）（ Abran Elicitation ）,分析（ analysis ）,規(guī)格說明（ specification ） 和 Moore 2022 ）；這些子學(xué)科涵蓋了為軟件和軟件相關(guān)產(chǎn)品 收集,評(píng)估和記錄需求相關(guān)的全部活動(dòng),包括： 確定產(chǎn)品將要面對(duì)的各類用戶； 從

16、各類用戶的代表處收集 需求； 明白用戶的任務(wù)和目標(biāo),以及這些任務(wù)要實(shí)現(xiàn)的業(yè) 務(wù)目標(biāo)； 分析從用戶處得到的信息,將用戶的任務(wù)目標(biāo)與功能需求,非功能需求,業(yè)務(wù)規(guī)章,解 決方案建議及其它無關(guān)信息區(qū)分開來； 將頂層的需求支配到系統(tǒng)構(gòu)架內(nèi)定義好的軟件組件中； 明白各質(zhì)量屬性的相對(duì)重要性； 協(xié)商需求的實(shí)現(xiàn)優(yōu)先 級(jí)； 將收集的用戶需求表述為書面的需求規(guī)格說明和 模型； 批閱需求文檔, 以確保在熟識(shí)上與用戶聲明的需求相一樣； 解決全部分岐； 強(qiáng)調(diào)： 迭代（ iteration ） 是需求開發(fā)勝利的關(guān)鍵； 需求治理 需求治理的任務(wù)是 “與客戶就軟件項(xiàng)目的需求達(dá)成并保持一樣 應(yīng)在開發(fā)小組接受需求之前 ”（ Pau

17、1k et a1 1995）；這 種一樣應(yīng)表達(dá)在書面的需求規(guī)格說明和模型中； 取得用戶認(rèn)可只中意了批準(zhǔn)需求所需的一半 條件,仍必需讓開發(fā)人員接受需求規(guī)格說明并同意在產(chǎn)品中加以實(shí)現(xiàn)； 需求治理包括以下活 動(dòng)： 定義需求基線（某一時(shí)刻,對(duì)特定版本中己達(dá)成一樣的需求內(nèi)容的描述） 審查需求變更懇求,評(píng)估其可能產(chǎn)生的影響以預(yù)備是否批準(zhǔn) 以可控的方式將準(zhǔn)的需求變更融入項(xiàng)目中 保持項(xiàng)目方案與需求的同步 估量需求變更的影響,在此基礎(chǔ)上協(xié)商新的需求商定 跟蹤每項(xiàng)需求,找到與其對(duì)應(yīng)的設(shè)計(jì),源代碼和測(cè)試用例（ test casc） 在項(xiàng)目開發(fā)過程中,始終跟蹤需求的狀態(tài)和變更 圖 1-3 從另一個(gè)角度反映了需求開發(fā)與

18、需求治理間的區(qū)分；本書介紹了很多用于獵取需求, 第 7 頁,共 13 頁分析需求,說明截驗(yàn)證和治理需求的特殊技巧； 圖！ 3 需求開發(fā)與需求治理的分界 全部項(xiàng)目都有需求 此處內(nèi)容的本質(zhì)是,需求的重要意義； 我們只要知道： 軟件系統(tǒng)開發(fā)過程中最難的部分是什么？ 需求開發(fā)； 全部概念性工作中最難的是什么？ 建立具體的技術(shù)需求； 在無法確定全部的需求的情形下怎么辦？ 接受迭代和增量方法, 每次實(shí) 現(xiàn)一部分需求,得到用戶反饋后再進(jìn)入下一循環(huán)； 沒有理所當(dāng)然的需求 優(yōu)秀的團(tuán)隊(duì)遇到糟糕的需求 本節(jié)內(nèi)容主要在于： 需求開發(fā)不是個(gè)別人的事情,是一個(gè)軟件團(tuán)隊(duì)全體的任務(wù)； 需求問題導(dǎo)致返工,是很好的說明；圖 1-

19、4； 作為將來的職業(yè),需要知道這些學(xué)問,但本課不講,自學(xué)； 需求問題導(dǎo)致的主要后果是返工 重復(fù)做您認(rèn)為早已做好的事情； 返工的成本占了總 開發(fā)成本的 30% 50%（ Boehm 和 Papaccio 1988）,而對(duì)于返工的情形, 70% 80%是因 第 8 頁,共 13 頁需求錯(cuò)誤引起的（ Leffngwel1 1997）；從圖 1-4 可以看出,在項(xiàng)目末期才發(fā)覺缺陷,對(duì)其 進(jìn)行改正的成本要比在缺陷剛產(chǎn)生不久時(shí)修改的成本高得多； 防止需求錯(cuò)誤的發(fā)生并及早發(fā) 現(xiàn)它們, 對(duì)于削減返工功效特殊顯著； 試想假如能把返工削減一半, 您的生活將會(huì)多么不同： 您可以更快地開發(fā)出產(chǎn)品, 即便不用通宵達(dá)旦地

20、工作, 您也能在同樣的時(shí)間里開發(fā)出比原先 更多更好的產(chǎn)品； 需求實(shí)踐中的種種不足會(huì)給項(xiàng)目的勝利帶來很多風(fēng)險(xiǎn)； “勝利 ”是指以商定的成本和進(jìn)度 交付中意用戶對(duì)功能和質(zhì)量的期望的產(chǎn)品；第 23 章中表達(dá)了如何把握這些風(fēng)險(xiǎn)使項(xiàng)目不致 因其而脫軌；以下幾節(jié)將介紹一些最常見的與需求相關(guān)的風(fēng)險(xiǎn)； 圖 1-4 不同階段改正缺陷的開銷比較 用戶參加不足 開發(fā)人員往往往往不重視用戶的參加, 緣由是他們認(rèn)為與用戶打交道不像寫代碼那么有 趣,或者自以為已經(jīng)知道了用戶想要什么 ； 有些時(shí)候, 與產(chǎn)品實(shí)際的使用者直接聯(lián)系很困難, 而用戶代理方又不能完全懂得用戶的 真正需求； 用戶參加不足將導(dǎo)致不能在項(xiàng)目早期準(zhǔn)時(shí)發(fā)覺需

21、求中的缺陷, 從而延誤項(xiàng)目的完 成；在整個(gè)項(xiàng)目開發(fā)過程中,開發(fā)團(tuán)隊(duì)必需始終與實(shí)際用戶直接合作； 第 6 章說明白這種合作的不行替代性； 用戶需求擴(kuò)展 不依照對(duì)于需求的規(guī)模和復(fù)雜度的實(shí)際評(píng)估來制訂方案, 而不斷修改需求又使情形變得 更糟；緣由主要是需求的不斷進(jìn)展與增加,項(xiàng)目往往會(huì)落后于方案的進(jìn)度并超出預(yù)算； 要把握項(xiàng)目范疇的轉(zhuǎn)變,第一應(yīng)明確項(xiàng)目的業(yè)務(wù)目標(biāo),全局規(guī)劃,范疇,限制,勝利標(biāo) 準(zhǔn)以及產(chǎn)品的估量用途；然后參考這一框架對(duì)全部新特性和需求變更進(jìn)行評(píng)估； 仍有軟件開發(fā)中的質(zhì)量問題： 隨著變更在產(chǎn)品內(nèi)部的擴(kuò)散, 項(xiàng)目的原有結(jié)構(gòu)可能逐步瓦 解；造成很多代碼補(bǔ)丁,使得程序更難懂得和愛惜； 插入的代碼可

22、能導(dǎo)致模塊違反強(qiáng)內(nèi)聚和弱耦合這一設(shè)計(jì)原就； 要削減需求變更對(duì)質(zhì)量造成的影響, 處理變更時(shí)應(yīng)當(dāng)先對(duì)結(jié)構(gòu)和設(shè)計(jì)進(jìn)行適當(dāng)?shù)?修改,而不是直接修改代碼； 第 9 頁,共 13 頁有歧義的需求 歧義,是需求規(guī)約的大忌 （LawrCncc 1995 ）； 歧義表現(xiàn)為同一讀者可以對(duì)一項(xiàng)需求聲 明作出多種說明,或者不同的讀者對(duì)同一需求產(chǎn)生不同的懂得； 第 10 章列出了很多簡潔產(chǎn)生歧義,給讀者造成負(fù)擔(dān)的詞語；產(chǎn)生歧義的另一個(gè)緣由是 需求不精確和沒有充分細(xì)化； 鍍金問題 以為 “用戶確定會(huì)寵愛的 ”,而實(shí)際上卻是華而不實(shí)的需求就是所謂的 “鍍金問題 （gold plating ） ”； 留意： 用戶通常并不關(guān)懷

23、額外的功能； 應(yīng)當(dāng)把創(chuàng)意和備選方案提交給客戶； 開發(fā)人員應(yīng) 該力求簡潔,而不是自作主見去超越客戶的需求； 要防止鍍金問題,就應(yīng)當(dāng)追溯每項(xiàng)功能的來源,弄清晰為什么添加該功能； 收集需求時(shí),使用用例方法,有助于著重考慮可實(shí)現(xiàn)商業(yè)任務(wù)的功能需求； 過于抽象的需求 營銷人員或經(jīng)理常常寵愛只給出一個(gè)粗略的說明,期望開發(fā)人員在開發(fā)過程中充實(shí)它； 這種方式只適合于那些爭論性項(xiàng)目或需求特殊靈敏的項(xiàng)目； 挫,讓客戶敗興； 忽視了某類用戶 這里描述的是“用戶與產(chǎn)品的關(guān)系”； 否就, 這種做法會(huì)使開發(fā)人員受 a 假如一開頭沒能找出產(chǎn)品的全部重要用戶群,就會(huì)有某些用戶需求得不到滿 足； b 確定全部用戶群后,仍要保證

24、獲得各類用戶的需求 用戶所使用的產(chǎn)品特性,產(chǎn)品的使用頻率以及用戶自身的體會(huì)水平不盡相同； 對(duì)某一產(chǎn)品,確定存在下述情形： 用戶群體 產(chǎn)品特性 產(chǎn)品的使用頻率 對(duì)該產(chǎn)品使用的體會(huì) A B C 不精確的方案 不能充分懂得需求,就會(huì)作出過于樂觀的估量,最終不行防止地陷入超支的泥潭； 造成軟件成本估算失敗的最主要緣由包括頻繁變更需求, 遺漏需求,未與用戶充分溝通, 第 10 頁,共 13 頁需求的說明不精確,以及對(duì)需求的分析不透徹； 給出估算結(jié)果時(shí),應(yīng)當(dāng)供應(yīng)范疇（最好的情形,最可能和最糟的情形）或把握程度； 優(yōu)質(zhì)需求過程的好處 軟件需求過程到底該是怎樣的？我們將通過試驗(yàn)課程嘗試建立； 但目前條件限制,

25、 我們 仍難以體會(huì)一下的好處： 削 減需求缺陷 削減開發(fā)過 程中的返工 削減不必要 的特性 降低改進(jìn)成本 加 快開發(fā)進(jìn)度 提高溝通效 率 把握需求范疇的轉(zhuǎn)變 項(xiàng)目更有序 對(duì)系統(tǒng)測(cè)試 的評(píng)估更精確 提高客戶和開發(fā)人員的中意度 優(yōu)秀需求的特點(diǎn) 本節(jié)重要,但很多內(nèi)容需要在實(shí)踐中懂得； 如何才能將好的需求規(guī)格說明與那些有問題的區(qū)分開來？這一節(jié)第一對(duì)說明中的單條 需求（即需求聲明）特點(diǎn)進(jìn)行爭論,然后將介紹 SRS 作為整體應(yīng)具備的特點(diǎn)；假如想知道 您的需求是否具備這些特點(diǎn), 最好的方法就是請(qǐng)幾位項(xiàng)目相關(guān)人員認(rèn)真批閱您的 SRS；不同 的人會(huì)發(fā)覺不同的問題； 例如, 分析員和開發(fā)人員無法精確判定完備性和正

26、確性, 而用戶就 無法評(píng)判技術(shù)可行性； 需求陳述的特點(diǎn) 抱負(fù)情形下,每一項(xiàng)用戶需求,業(yè)務(wù)需求和功能需求都應(yīng)具備以下性質(zhì)； 完整性 每一項(xiàng)需求都必需完整地描述即將交付使用的功能； 它必需包合開發(fā)人員設(shè)計(jì)和實(shí)現(xiàn)這 項(xiàng)功能需要的全部信息； 假如發(fā)覺缺少某項(xiàng)信息,應(yīng)使用 TBD（ to be determined ,待定） 這一標(biāo)準(zhǔn)符號(hào)加以標(biāo)明 ；在開發(fā)系統(tǒng)的任一部分之前都必需解決需求中全部的 TBD ； 正確性 每一項(xiàng)需求都必需精確地描述將要開發(fā)的功能； 第 11 頁,共 13 頁判定正確性的參考是需求的來源,照實(shí)際用戶和高級(jí)的系統(tǒng)需求； 需求規(guī)約必需經(jīng)過用戶或用戶信任的代理人的批閱； 可行性 需求

27、必需能夠在系統(tǒng)及其運(yùn)行環(huán)境的已知才能和約束條件內(nèi)實(shí)現(xiàn)； 在需求的獵取階段, 應(yīng)支配一名開發(fā)人員始終和營銷人員或需求分析員協(xié)同工作, 由開 發(fā)人員來進(jìn)行可行性檢查, 判定技術(shù)上能夠?qū)崿F(xiàn)哪些需求, 或者什么功能需要額外的成本才 能實(shí)現(xiàn)； 評(píng)估需求可行性的方法包括增量開發(fā)方法和 概念證明（ proof-of-concept ）原型； 概念證明（ proof-of-concept 必要性 ）,基于建模 -使用 -開發(fā) -證明 -試驗(yàn)運(yùn)行 -驗(yàn)證結(jié)果的工程方法； 每一項(xiàng)需求記錄的功能都必需是用戶的真正需要, 或者是為符合外部系統(tǒng)需求或某一標(biāo) 準(zhǔn)而必需具備的功能 ；每項(xiàng)需求都必需來源于有權(quán)定義需求的一方；

28、 對(duì)每項(xiàng)需求都必需追溯 至特定的客戶需求的來源,譬如用例,業(yè)務(wù)規(guī)章或其它來源； 有優(yōu)先次序 為每一項(xiàng)功能需求, 特性或用例指定一個(gè)實(shí)現(xiàn)優(yōu)先級(jí), 以說明它在產(chǎn)品的某一版本中的 重要程度； 假如全部需求都被視為同等重要, 項(xiàng)目經(jīng)理就很難實(shí)行措施應(yīng)對(duì)預(yù)算削減, 進(jìn)度 拖后,人員流失或開發(fā)過程中需求增加等情形； 注 第 14 章將更具體地爭論如何設(shè)置優(yōu)先級(jí)； 補(bǔ)充學(xué)問：軟件愛惜與軟件產(chǎn)品版本升級(jí)； 軟件愛惜與軟件產(chǎn)品版本升級(jí)有確定關(guān)系：例如： 如小愛惜前的版本號(hào)為 ,就小愛惜后的版本號(hào)為 ； 如大愛惜前的版本號(hào)為 ,就大愛惜后的版本號(hào)為 ； 一般而言,版本號(hào)中小圓點(diǎn)的左一位,表示該軟件產(chǎn)品的第幾個(gè)版本；版本號(hào)中小圓點(diǎn) 的右一位,表示該版本的大修改次數(shù)；版本號(hào)中小圓點(diǎn)的右二位,表示該版本的小修改 次數(shù)；即一個(gè)版本的大修改最多是 9 次,小修改最多是 81 次； 只有當(dāng)該軟件產(chǎn)品的運(yùn)行環(huán)境發(fā)生大轉(zhuǎn)變時(shí),或者該軟件產(chǎn)品的功能變化超過 30%時(shí), 其版本才能升級(jí),此時(shí),版本號(hào)中小圓點(diǎn)的左一位才能加 無歧義 1,由 V1.11 變?yōu)?；