【正文】 項目的成功帶來極大風(fēng)險導(dǎo)致缺陷的原因主要包括以下方面 缺乏足夠的用戶參與客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費那么多功夫開發(fā)人員可能也不重視用戶的參與究其原因一是因為與用戶合作不如編寫代碼有意思二是因為開發(fā)人員覺得已經(jīng)明白用戶的需求了在某些情況下與實際使用產(chǎn)品的用戶直接接觸很困難而客戶也不太明白自己的真正需求然而在項目的早期讓具有代表性的用戶直接參與到開發(fā)隊伍中并一同經(jīng)歷整個開發(fā)過程很重要用戶需求不斷增加在開發(fā)過程中用戶需求經(jīng)常發(fā)生變化但是不斷的變更會使其整體結(jié)構(gòu)越來越亂整個程序也難以理解和維護(hù)如果要減少需求變更的影響范圍就必須在項目的開始對項目視圖范圍目標(biāo)約束限制和成功標(biāo)準(zhǔn)給予明確說明并將此說明作為評價需求變更和新特性的參照框架需求模棱兩可模棱兩可是需求規(guī)格說明中最嚴(yán)重的問題它意味著不同的人對需求說明產(chǎn)生了不同的理解或者是同一個人能用不止一個方式來解釋某項需求說明模棱兩可的需求帶來的后果便是返工重做一些你認(rèn)為已做好的事情返工會耗費開發(fā)總費用的40而70～85的重做是由于需求方面的錯誤引起的添加不必要的特性有時候開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能然而常常是用戶并不認(rèn)為這些功能性很有用開發(fā)人員應(yīng)當(dāng)為客戶構(gòu)思方案并為他們提供一些具有創(chuàng)新意識的思路具體提供哪些功能要在客戶的需要和允許時限內(nèi)的技術(shù)可行性之間求得平衡規(guī)格說明過于簡單客戶往往不明白需求分析的重要性只是提供一份十分簡略的規(guī)格說明僅涉及產(chǎn)品概念上的內(nèi)容然后讓開發(fā)人員在項目進(jìn)展中去完善從而導(dǎo)致開發(fā)人員先建立產(chǎn)品結(jié)構(gòu)再完成需求說明忽略了用戶分類大多數(shù)產(chǎn)品是由不同的人使用其不同的特性使用頻繁程度也有所差異使用者受教育程度和經(jīng)驗水平也不盡相同如果你不能在項目早期就針對所有這些主要用戶進(jìn)行分類的話必然導(dǎo)致有的用戶對產(chǎn)品感到失望總體來說導(dǎo)致需求缺陷的原因主要體現(xiàn)在三個方面 需求的溝通與理解 需求的變化與控制 需求說明的明確與完整 需求工程中的缺陷將給項目成功帶來極大風(fēng)險如產(chǎn)品的成本過高產(chǎn)品的功能和質(zhì)量無法完全滿足用戶的期望等等即使一個項目團隊的人員和配備都很不錯但不重視需求過程也會付出慘痛的代價本節(jié)知識點 需求工程的內(nèi)容 需求獲取 需求分析 編寫需求文檔 需求驗證需求工程是指應(yīng)用已證實有效的原理和方法系統(tǒng)地描述出待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束通常需求工程由一些過程組成可分為需求開發(fā)和需求管理兩部分需求開發(fā)的主要活動 確定產(chǎn)品所期望的用戶類 獲取每個用戶類的需求 了解實際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求 分析源于用戶的信息以區(qū)別用戶任務(wù)需求功能需求業(yè)務(wù)規(guī)則質(zhì)量屬性建議解決方法和附加信息將系統(tǒng)級的需求分為幾個子系統(tǒng)并將需求中的一部份分配給軟件組件 了解相關(guān)質(zhì)量屬性的重要性 商討實施優(yōu)先級的劃分 將所收集的用戶需求編寫成規(guī)格說明和模型 評審需求規(guī)格說明確保對用戶需求達(dá)到共同的理解與認(rèn)識并在整個開發(fā)小組接受說明之前將問題都弄清楚需求管理的主要活動 定義需求基線 評審提出的需求變更評估每項變更的可能影響從而決定是否實施它 以一種可控制的方式將需求變更融入到項目中 使當(dāng)前的項目計劃與需求一致 估計變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾 讓每項需求都能與其對應(yīng)的設(shè)計源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤 在整個項目過程中跟蹤需求狀態(tài)及其變更情況今天我們引入“需求工程”的概念強調(diào)用工程化的方法進(jìn)行需求開發(fā)和需求管理其中需求開發(fā)是采用有效方法獲得高質(zhì)量需求的過程而需求管理則是在需求說明形成之后有效地控制其變更的過程二者缺一不可一工作內(nèi)容 聆聽用戶的需求 分析和整理所獲取的信息 形成文檔化的描述 二基于用例的方法隨著面向?qū)ο蠹夹g(shù)的發(fā)展基于用例的方法在需求獲取和建模方面應(yīng)用得越來越普遍這種方法是以任務(wù)為中心和以用戶為中心的比起使用以功能為中心的方法它可以使用戶更清楚地認(rèn)識到新系統(tǒng)允許他們做什么用例模型以用戶和任務(wù)為中心將整個工作的焦點集中在從用戶的角度說明系統(tǒng)能夠干什么完全不考慮具體的實現(xiàn)細(xì)節(jié)從而達(dá)到準(zhǔn)確地理解客戶需求的目的在用例模型中角色和用例是兩個基本概念分別代表著系統(tǒng)外部的執(zhí)行者和系統(tǒng)應(yīng)包含的功能因此建立用例模型的主要工作是確定角色確定用例和描述用例 A確定角色角色代表著與系統(tǒng)交互的人或事通過確認(rèn)系統(tǒng)功能使用者和維護(hù)者以及與系統(tǒng)接口的其他系統(tǒng)或硬件設(shè)備等可以有效地識別出系統(tǒng)角色 B確定用例一個完整的系統(tǒng)包含若干個用例每個用例具體說明應(yīng)完成的功能識別用例首先要確定系統(tǒng)所能反映的外部事件并把這些事件與參與的執(zhí)行者和特定的使用實例聯(lián)系起來最終繪制出用例圖 C描述用例單純地使用用例圖不能提供用例所具有的全部信息因此需要使用文字描述那些不能反映在圖形上的信息用例描述實際上是關(guān)于角色與系統(tǒng)如何交互的規(guī)格說明要求清晰明確沒有二義性建立用例模型是一種需求獲取的有效方法其簡潔清晰的描述方式容易被軟件人員和用戶共同理解和接受這種方法已經(jīng)在許多大型系統(tǒng)的開發(fā)中取得成效實踐證明它能有效地解決用戶參與的問題需求分析主要是對收集到的需求進(jìn)行提煉分析和仔細(xì)審查以確保所有的風(fēng)險承擔(dān)者都明白其含義并找出其中的錯誤遺漏或其它不足的地方形成完整的分析模型分析的目的在于開發(fā)出高質(zhì)量的和具體的需求從而支持項目的估算和軟件的設(shè)計開發(fā)和測試需求分析的主要活動包括 繪制系統(tǒng)關(guān)聯(lián)圖 創(chuàng)建用戶接口原型 分析需求可行性 確定需求的優(yōu)先級別 創(chuàng)建數(shù)據(jù)字典 為需求建立模型繪制系統(tǒng)關(guān)聯(lián)圖這種關(guān)聯(lián)圖用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型創(chuàng)建用戶接口原型當(dāng)開發(fā)人員或用戶不能確定需求時開發(fā)一個用戶接口原型可以使許多概念和可能發(fā)生的事更為直觀明了用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題同時找出需求文檔與原型之間所有的沖突之處 分析需求可行性在允許的成本和性能要求下分析每項需求實施的可行性明確與每項需求實現(xiàn)相聯(lián)系的風(fēng)險包括與其它需求的沖突對外界因素的依賴和技術(shù)障礙確定需求的優(yōu)先級別應(yīng)用分析方法來確定用例產(chǎn)品特性或單項需求實現(xiàn)的優(yōu)先級別以優(yōu)先級為基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或哪類需求當(dāng)允許需求變更時在特定的版本中加入每一項變更并在那個版本計劃中作出需要的變更 為需求建立模型需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明它們能提供不同的信息與關(guān)系以幫助找到不正確的不一致的遺漏的和冗余的需求這些模型包括數(shù)據(jù)流圖實體關(guān)系圖狀態(tài)變換圖對話框圖對象類及交互作用圖等 創(chuàng)建數(shù)據(jù)字典數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構(gòu)的定義以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義在需求階段數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項以確保客戶與開發(fā)小組是使用一致的定義和術(shù)語分析建模的方法有很多其中最重要的兩種方法是結(jié)構(gòu)化分析和面向?qū)ο蠓治?結(jié)構(gòu)化分析方法提供實體關(guān)系圖數(shù)據(jù)流圖和狀態(tài)轉(zhuǎn)換圖三種圖形模型分別進(jìn)行數(shù)據(jù)建模功能建模和動態(tài)建模人們習(xí)慣于用自然語言來描述軟件需求但這會產(chǎn)生許多意想不到的問題如不精確二義性等因此需要采用適當(dāng)?shù)姆椒ㄐ纬梢恢碌耐陚涞暮蜔o二義性的軟件需求規(guī)格說明通常編寫軟件需求規(guī)格說明有三種方法 將結(jié)構(gòu)化語言與自然語言結(jié)合編寫文本型文檔 建立可視化的模型 采用形式化的方法進(jìn)行需求規(guī)格說明軟件需求規(guī)格說明是需求開發(fā)的最終結(jié)果它精確地闡述一個軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件軟件需求規(guī)格說明不僅是系統(tǒng)測試和用戶文檔的基礎(chǔ)也是所有子系列項目規(guī)劃設(shè)計和編碼的基礎(chǔ)軟件需求規(guī)格說明是用戶分析人員和設(shè)計人員之間進(jìn)行理解和交流的手段 測試人員可以根據(jù)軟件需求規(guī)格說明中對產(chǎn)品行為的描述制定測試計劃測試用例和測試過程 文檔人員根據(jù)軟件需求規(guī)格說明和用戶界面設(shè)計編寫用戶手冊等 軟件需求規(guī)格說明指導(dǎo)著整個系統(tǒng)的開發(fā)過程評審過的需求規(guī)格說明需要進(jìn)行變更控制a 引言概要敘述軟件需求規(guī)格說明便于讀者理解文檔如何編寫以及如何閱讀和解釋在軟件項目中開發(fā)組織應(yīng)該采用一種標(biāo)準(zhǔn)的軟件需求規(guī)格說明的模板現(xiàn)在有許多軟件需求規(guī)格說明模板可以使用這里介紹其中的一種 a1 目的對產(chǎn)品進(jìn)行定義在該文檔中詳盡說明了這個產(chǎn)品的軟件需求包括修正或發(fā)行版本號如果這個軟件需求規(guī)格說明只與整個系統(tǒng)的一部分有關(guān)系那么就只定義文檔中說明的部分或子系統(tǒng) a2 文檔約定描述編寫文檔時所采用的標(biāo)準(zhǔn)或排版約定包括正文風(fēng)格提示區(qū)或重要符號a3 預(yù)期的讀者和閱讀建議列舉了軟件需求規(guī)格說明所針對的不同讀者例如開發(fā)人員項目經(jīng)理營銷人員用戶測試人員或文檔的編寫人員描述了文檔中剩余部分的內(nèi)容及其組織結(jié)構(gòu)提出了最適合于每一類型讀者閱讀文檔的建議 a4 產(chǎn)品范圍提供了對指定的軟件及其目的的簡短描述包括利益和目標(biāo) a5 參考文獻(xiàn)列舉了編寫軟件需求規(guī)格說明時所參考的資料或其它資源可能包括用戶界面風(fēng)格指導(dǎo)合同標(biāo)準(zhǔn)系統(tǒng)需求規(guī)格說明使用實例文檔或相關(guān)產(chǎn)品的軟件需求規(guī)格說明在這里應(yīng)該給出詳細(xì)的信息包括標(biāo)題名稱作者版本號日期出版單位或資料來源以方便讀者查閱這些文獻(xiàn) b 綜合描述這一部分概述了正在定義的產(chǎn)品以及它所運行的環(huán)境使用產(chǎn)品的用戶和已知的限制假設(shè)和依賴 b1 產(chǎn)品的前景描述了軟件需求規(guī)格說明中所定義的產(chǎn)品的背景和起源說明了該產(chǎn)品是否是產(chǎn)品系列中的下一成員是否是成熟產(chǎn)品所改進(jìn)的下一代產(chǎn)品是否是現(xiàn)有應(yīng)用程序的替代品或者是否是一個新型的自含型產(chǎn)品如果軟件需求規(guī)格說明定義了大系統(tǒng)的一個組成部分那么就要說明這部分軟件是怎樣與整個系統(tǒng)相關(guān)聯(lián)的并且要定義出兩者之間的接口 b2 產(chǎn)品的功能概述了產(chǎn)品所具有的主要功能其詳細(xì)內(nèi)容將在d中描述所以在此只需要概略地總結(jié)例如用列表的方法給出很好地組織產(chǎn)品的功能使每個讀者都易于理解用圖形表示主要的需求分組以及它們之間的聯(lián)系例如數(shù)據(jù)流程圖的頂層圖或類圖都是有用的 b3 用戶類和特征確定你覺得可能使用該產(chǎn)品的不同用戶類并描述它們相關(guān)的特征有一些需求可能只與特定的用戶類相關(guān)將該產(chǎn)品的重要用戶類與那些不太重要的用戶類區(qū)分開 b4 運行環(huán)境描述了軟件的運行環(huán)境包括硬件平臺操作系統(tǒng)和版本還有其它的軟件組件或與其共存的應(yīng)用程序 b5 設(shè)計和實現(xiàn)上的限制確定影響開發(fā)人員自由選擇的問題并說明這些問題為什么成為一種限制可能的限制包括如下內(nèi)容必須使用或者避免的特定技術(shù)工具編程語言和數(shù)據(jù)庫 所要求的開發(fā)規(guī)范或標(biāo)準(zhǔn) 企業(yè)策略政府法規(guī)或工業(yè)標(biāo)準(zhǔn) 硬件限制例如定時需求或存儲器限制 數(shù)據(jù)轉(zhuǎn)換格式標(biāo)準(zhǔn) b6 假設(shè)和依賴列舉出在對軟件需求規(guī)格說明中影響需求陳述的假設(shè)因素以及項目對外部因素存在的依賴 c 外部接口需求利用本節(jié)來確定可以保證新產(chǎn)品與外部組件正確連接的需求 c1 用戶界面陳述所需要的用戶界面的軟件組件描述每個用戶界面的邏輯特征以下是可能要包括的一些特征將要采用的圖形用戶界面 G U I標(biāo)準(zhǔn)或產(chǎn)品系列的風(fēng)格 屏幕布局或解決方案的限制 將出現(xiàn)在每個屏幕的標(biāo)準(zhǔn)按鈕功能或?qū)Ш芥溄永缫粋€幫助按鈕 快捷鍵 錯誤信息顯示標(biāo)準(zhǔn)c2 硬件接口描述系統(tǒng)中軟件和硬件每一接口的特征這種描述可能包括支持的硬件類型軟硬件之間交流的數(shù)據(jù)和控制信息的性質(zhì)以及所使用的通信協(xié)議 c3 軟件接口描述該產(chǎn)品與其它外部組件由名字和版本識別的連接包括數(shù)據(jù)庫操作系統(tǒng)工具庫和集成的商業(yè)組件明確并描述在軟件組件之間交換數(shù)據(jù)或消息的目的描述所需要的服務(wù)及內(nèi)部組件通信的性質(zhì)確定將在組件之間共享的數(shù)據(jù) c4 通信接口描述與產(chǎn)品所使用的通信功能相關(guān)的需求包括電子郵件Web瀏覽器網(wǎng)絡(luò)通信標(biāo)準(zhǔn)或協(xié)議及電子表格等等定義了相關(guān)的消息格式規(guī)定通信安全或加密問題數(shù)據(jù)傳輸速率和同步通信機制 d 系統(tǒng)特性 d1 說明和優(yōu)先級簡短說明該系統(tǒng)的特性并指出該特性的優(yōu)先級是高中還是低另外還可以包括對特定優(yōu)先級部分的評價例如利益損失費用和風(fēng)險 d2 激勵響應(yīng)序列列出輸入激勵用戶動作來自外部設(shè)備的信號或其它觸發(fā)器和定義這一特性行為的系統(tǒng)響應(yīng)序列 d3 功能需求詳列出與該特性相關(guān)的詳細(xì)功能需求這些是必須提交給用戶的軟件功能使用戶可以使用所提供的特性執(zhí)行服務(wù)或者使用所指定的使用實例執(zhí)行任務(wù) e 其他非功能需求 e1 性能需求闡述了不同的應(yīng)用領(lǐng)域?qū)Ξa(chǎn)品性能的需求并解釋它們的原理以幫助開發(fā)人員作出合理的設(shè)計選擇確定相互合作的用戶數(shù)或者所支持的操作響應(yīng)時間以及與實時系統(tǒng)的時間關(guān)系 e2 安全設(shè)施需求詳盡陳述與產(chǎn)品使用過程中可能發(fā)生的損失破壞或危害相關(guān)的需求定義必須采取的安全保護(hù)或動作還有那些預(yù)防的潛在的危險動作明確產(chǎn)品必須遵從的安全標(biāo)準(zhǔn)策略或規(guī)則 e3 安全性需求詳盡陳述與系統(tǒng)安全性完整性或私人問題相關(guān)的需求這些問題將會影響到產(chǎn)品的使用和產(chǎn)品所創(chuàng)建或使用的數(shù)據(jù)的保護(hù)定義用戶身份確認(rèn)或授權(quán)需求明確產(chǎn)品必須滿足的安全性或保密性策略 e4 軟件質(zhì)量屬性詳盡陳述與客戶或開發(fā)人員至關(guān)重要的其它產(chǎn)品質(zhì)量特性這些特性必須是確定定量的并在可能時是可驗證的 e5 業(yè)務(wù)規(guī)則列舉出有關(guān)產(chǎn)品的所有操作規(guī)則例如什么人在特定環(huán)境下可以進(jìn)行何種操作這些本身不是功能需求但它們可以暗示某些功能需求執(zhí)行這些規(guī)則 e6 用戶文檔列舉出將與軟件一同發(fā)行的用戶文檔部分例如用戶手冊在線幫助和教程明確所有已知的用戶文檔的交付格式或標(biāo)準(zhǔn) f 其他需求定義在軟件需求規(guī)格說明的其它部分未出現(xiàn)的需求例如國際化需求或法律上的需求你還可以增加有關(guān)操作管理和維護(hù)部分來完善產(chǎn)品安裝配置啟動和關(guān)閉修復(fù)和容錯以及登錄和監(jiān)控操作等方面的需求這一部分可以省略需求驗證是為了確保需求說明準(zhǔn)確完整地表達(dá)必要的質(zhì)量特點當(dāng)你閱讀軟件需求規(guī)格說明時可能覺得需求是對的但實現(xiàn)時卻很可能會出現(xiàn)問題當(dāng)以需求說明為依據(jù)編寫測試用例時你可能會發(fā)現(xiàn)說明中的二義性而所有這些都必須改善因為需求說明要作為設(shè)計和最終系統(tǒng)驗證的依據(jù)正確性 完整性 可驗證性 無二義性 可修改性 可跟蹤性 一致性審查需求文檔對需求文檔進(jìn)行正式審查是保證軟件質(zhì)量的有效方法組織一個由不同代表如分析人員客戶設(shè)計人員測試人員組成的小組對SRS及相關(guān)模型進(jìn)行仔細(xì)的檢查以需求為依據(jù)編寫測試用例根據(jù)用戶需求所要求的產(chǎn)品特性寫出黑盒功能測試用例客戶通過使用測試用例以確認(rèn)是否達(dá)到了期望的要求從測試用例追溯回功能需求以確保沒有需求被疏忽并且確保所有測試結(jié)果與測試用例相一致同時要使用測試用例來驗證需求模型的正確性如對話框圖和原型等編寫用戶手冊在需求開發(fā)早