如何做需求分析

1、第四章 需求分析 1目 錄一 軟件需求的誤區(qū)二 軟件需求的定義三 需求的層次四 需求風(fēng)險(xiǎn)五 什么是優(yōu)秀的需求六 如何做需求分析 1獲取用戶需求 2分析用戶需求 3編寫需求文檔 4評(píng)審需求文檔 5管理需求七 需求建模的方法2一 軟件需求的誤區(qū)對(duì)大多數(shù)人來說，若要建一幢數(shù)百萬元的房子，會(huì)關(guān)注什么?而軟件開發(fā)，會(huì)關(guān)注什么?人們卻變得“大大咧咧”起來。軟件項(xiàng)目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根” ?？稍S多組織采用一些不合規(guī)范的方法，導(dǎo)致的后果是一條鴻溝(期望差異)開發(fā)者開發(fā)的與用戶所想得到的軟件存在著巨大期望差異。3二 軟件需求的定義IEEE軟件工程標(biāo)準(zhǔn)詞匯表(1997年)中

2、定義需求為： (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)能的文檔說明。4三需求的層次 三個(gè)不同的層次業(yè)務(wù)需求、用戶需求和功能需求,也包括非功能需求。業(yè)務(wù)需求(businessrequirement)反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，在項(xiàng)目視圖與范圍文檔中予以說明。用戶需求(userrequirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，在使用實(shí)例(usecase)文檔或方案腳本(scenario)說明中予以說明

3、。5需求的層次功能需求(functionalrequirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。非功能需求，描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。 6最為困難的部分開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求，這包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。如果你的用戶告訴你需求就是這些了，不要相信他，繼續(xù)刨根問底，直到你們都筋疲力盡了。 7四 需求風(fēng)險(xiǎn)1 用戶參與度不夠客戶經(jīng)常不明白為什么收集

4、需求和確保需求質(zhì)量需花費(fèi)那么多功夫，開發(fā)人員可能也不重視用戶的參與。原因：一是因?yàn)榕c用戶合作不如編寫代碼有意思；二是因?yàn)殚_發(fā)人員覺得已經(jīng)明白用戶的需求了。(與實(shí)際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求) 。 8需求風(fēng)險(xiǎn)2.用戶需求的不斷增加 在開發(fā)中若不斷地補(bǔ)充需求，項(xiàng)目就越變?cè)烬嫶笠灾鲁^其計(jì)劃及預(yù)算范圍。這使得問題更難解決。問題根源在于用戶需求的改變和開發(fā)者對(duì)新需求所作的修改。不斷延續(xù)的變更會(huì)使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維護(hù)。 要想把需求變更范圍控制到最小，必須一開始就對(duì)項(xiàng)目視圖、范圍、目標(biāo)、約束限制和成功標(biāo)準(zhǔn)給予明確說明，并將此說明作為評(píng)價(jià)

5、需求變更和新特性的參照框架。9需求風(fēng)險(xiǎn)3.模棱兩可的需求 模棱兩可是需求中最為可怕的問題。它的一層含義是指諸多讀者對(duì)需求說明產(chǎn)生了不同的理解；另一層含義是指單個(gè)讀者能用不止一個(gè)方式來解釋某個(gè)需求說明。模棱兩可的需求會(huì)使不同的風(fēng)險(xiǎn)承擔(dān)者產(chǎn)生不同的期望，它會(huì)使開發(fā)人員為錯(cuò)誤問題而浪費(fèi)時(shí)間，并且使測(cè)試者與開發(fā)者所期望的不一致。10需求風(fēng)險(xiǎn)3.模棱兩可的需求(續(xù)) 處理模棱兩可需求的一種方法是組織好負(fù)責(zé)從不同角度審查需求的隊(duì)伍。如果不同的評(píng)審者從不同的角度對(duì)需求說明給予解釋，讓每個(gè)評(píng)審人員都真正了解需求文檔，這樣二義性就不會(huì)直到項(xiàng)目后期才被發(fā)現(xiàn)，付出的代價(jià)太大。 11需求風(fēng)險(xiǎn)4.不必要的特性 “畫蛇添

6、足”是指開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能。12需求風(fēng)險(xiǎn)5.過于精簡(jiǎn)的規(guī)格說明 僅涉及了產(chǎn)品概念上的內(nèi)容，然后讓開發(fā)人員在項(xiàng)目進(jìn)展中去完善，結(jié)果可能會(huì)出現(xiàn)開發(fā)人員先建立產(chǎn)品的結(jié)構(gòu)之后再完成需求說明。這種方法可能適合于尖端研究性的產(chǎn)品或需求十分靈活的情況，不過商業(yè)應(yīng)用情況下，這會(huì)給開發(fā)人員帶來挫折(使他們產(chǎn)生不正確的假設(shè)前提和極其有限的指導(dǎo)下工作)，也會(huì)給客戶帶來煩惱(他們無法得到他們所設(shè)想的產(chǎn)品)。 13需求風(fēng)險(xiǎn)6.忽略了用戶分類 系統(tǒng)是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經(jīng)驗(yàn)水平也不盡相同。如果不能在項(xiàng)目早期對(duì)這些主要用戶進(jìn)行分

7、類，必然導(dǎo)致有的用戶對(duì)產(chǎn)品感到失望。14需求風(fēng)險(xiǎn)7.不準(zhǔn)確的計(jì)劃 對(duì)需求分析缺乏理解會(huì)導(dǎo)致過分樂觀的估計(jì)，而當(dāng)發(fā)生超支、超時(shí)時(shí)，會(huì)帶來頗多麻煩。成本估計(jì)極不準(zhǔn)確的原因主要有五點(diǎn)：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析。 15風(fēng)險(xiǎn)承擔(dān)者風(fēng)險(xiǎn)承擔(dān)者包括客戶、用戶、業(yè)務(wù)或需求分析員、開發(fā)人員、測(cè)試人員、用戶文檔編寫者、項(xiàng)目管理者和客戶管理者。16五. 什么是優(yōu)秀的需求軟件需求過程的標(biāo)準(zhǔn)是：清楚(Clear)、完整(Complete)、一致(Consistent)、可測(cè)試(Testable)，此外還有其他的概念，如可跟蹤的、可修改的等等。 17什么是優(yōu)秀的

8、需求1.清楚：需求分析采用的是自然語言。自然語言對(duì)需求分析最大的弊病是什么?二義性。所以不得不對(duì)需求分析中采用的語言做某些限制.例如:盡量采用主語動(dòng)作的簡(jiǎn)單表達(dá)方式。需求分析中的描述讓人看上去像是剛學(xué)習(xí)寫作的小孩子，不要采用疑問句、修飾這些華麗的表達(dá)方式。 18什么是優(yōu)秀的需求 除了語言的二義性之外，不要使用行話，就是計(jì)算機(jī)術(shù)語。需求分析最重要的是和用戶溝通，用戶多半不是計(jì)算機(jī)的專業(yè)人士，如果在需求分析中使用了行話，就會(huì)造成用戶理解上的困難。19什么是優(yōu)秀的需求需求描述的例子：如果要做一個(gè)銀行的信用卡系統(tǒng)，如何描述需求？這樣描述需求： 銀行卡部管理信用卡，每張信用卡只屬于一個(gè)帳戶。信用卡有卡號(hào)

9、、余額。一張信用卡有多筆的交易記錄。20什么是優(yōu)秀的需求2.完整：需求的完整性是非常重要的，若遺漏需求而不得不返工(是惡夢(mèng))。而需求的遺漏是經(jīng)常發(fā)生的，不僅僅是你的問題，更多的問題發(fā)生在用戶那里，他們不知道該做些什么。要做到需求的完整性是很艱難的一件事情，涉及到需求分析過程的各各方面，貫穿了整個(gè)過程，從最初的計(jì)劃制定到最后的需求評(píng)審。21什么是優(yōu)秀的需求3.一致：需求是有層次的，一致性就是用戶需求必須和業(yè)務(wù)需求一致，功能需求必須和用戶需求一致。嚴(yán)格的遵守不同層次間的一致性關(guān)系，就可以保證最后開發(fā)出來的軟件系統(tǒng)不會(huì)偏離最初的實(shí)現(xiàn)目標(biāo)。22什么是優(yōu)秀的需求4.可測(cè)試：一個(gè)項(xiàng)目的測(cè)試從什么時(shí)候開始？

10、有人說從編碼完成后開始。更清楚一點(diǎn)的說是編碼的時(shí)候同時(shí)進(jìn)行單元測(cè)試，編碼完成后進(jìn)行系統(tǒng)測(cè)試。實(shí)際上測(cè)試是從需求分析過程就開始了： 需求分析是測(cè)試計(jì)劃的輸入和參照。只有系統(tǒng)的所有需求是可以被測(cè)試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統(tǒng)是成功的。 23六 怎樣做需求分析形成軟件需求步驟：1獲取用戶需求2分析用戶需求3編寫需求文檔4評(píng)審需求文檔5管理需求。圖1 獲取用戶需求的活動(dòng)24怎樣做需求分析1 獲取用戶需求該階段是最重要的，任務(wù)： 先了解客戶方的所有用戶類型以及潛在的類型。然后，根據(jù)他們的要求來確定系統(tǒng)的整體目標(biāo)和系統(tǒng)的工作范圍。 對(duì)用戶進(jìn)行訪談和調(diào)研。交流的方式可以是會(huì)議、電話、

11、電子郵件、小組討論、模擬演示等不同形式。需要注意的是，每一次交流一定要有記錄，對(duì)于交流的結(jié)果還可以進(jìn)行分類，便于后續(xù)的分析活動(dòng)。 25怎樣做需求分析2 用戶需求的分析和整理： 幾條常見的準(zhǔn)則：對(duì)于用戶提出的每個(gè)需求都要知道“為什么”，并判斷用戶提出的需求是否有充足的理由； 。將以“如何實(shí)現(xiàn)”的表述方式轉(zhuǎn)換為“實(shí)現(xiàn)什么”的方式，因?yàn)樾枨蠓治鲭A段關(guān)注的目標(biāo)是“做什么”，而不是“怎么做”；分析由用戶需求衍生出的隱含需求，并識(shí)別用戶沒有明確提出來的隱含需求，這一點(diǎn)往往容易被忽略，經(jīng)常會(huì)因?yàn)閷?duì)隱含需求考慮得不充分而引起需求變更。 26怎樣做需求分析2 用戶需求的分析和整理（續(xù)）： 根據(jù)大家共同確認(rèn)需求，

12、分析人員所提交的結(jié)果是否真實(shí)地反映了用戶的意圖。需求分析人員在這個(gè)任務(wù)中需要執(zhí)行的活動(dòng)：明確標(biāo)識(shí)出待確定的需求項(xiàng)（在需求分析初期往往有很多這樣的待定項(xiàng)）；使需求符合系統(tǒng)的整體目標(biāo)；保證需求項(xiàng)之間的一致性，解決需求項(xiàng)之間可能存在的沖突。 27分析用戶需求2 用戶需求的分析和整理（續(xù)）： 分析用戶需求是與獲取用戶需求并行的，主要通過建立模型的方式來描述用戶的需求，為客戶、用戶、開發(fā)方等不同參與方提供一個(gè)交流的渠道。這些模型是對(duì)需求的抽象，以可視化的方式提供一個(gè)易于溝通的橋梁。 用戶需求的分析與獲取用戶需求有著相似的步驟，區(qū)別在于分析用戶需求時(shí)使用模型來描述，以獲取用戶更明確的需求。28分析用戶需求

13、分析用戶需求執(zhí)行的活動(dòng)： 以圖形表示的方式描述系統(tǒng)的整體結(jié)構(gòu)，包括系統(tǒng)的邊界與接口； 通過原型、網(wǎng)頁或其它方式向用戶提供可視化的界面，用戶可以對(duì)需求做出自己的評(píng)價(jià)； 系統(tǒng)可行性分析，需求實(shí)現(xiàn)的技術(shù)可行性、環(huán)境分析、費(fèi)用分析、時(shí)間分析等； 以模型描述系統(tǒng)的功能項(xiàng)、數(shù)據(jù)實(shí)體、外部實(shí)體、實(shí)體之間的關(guān)系、實(shí)體之間的狀態(tài)轉(zhuǎn)換等方面的內(nèi)容。 29需求建模的方法需求建模的常用方法：數(shù)據(jù)流圖（DFD）、實(shí)體關(guān)系圖（ERD）和用例圖（Use Case）三種方式。DFD作為結(jié)構(gòu)化系統(tǒng)分析與設(shè)計(jì)的主要方法；DFD適用于MIS系統(tǒng)的表述。DFD使用四種基本元素來描述系統(tǒng)的行為（過程、實(shí)體、數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)）。DFD方

14、法直觀易懂，使用者可以方便地得到系統(tǒng)的邏輯模型和物理模型，但是從DFD圖中無法判斷活動(dòng)的時(shí)序關(guān)系。 30用于需求建模的方法ERD方法用于描述系統(tǒng)實(shí)體間的對(duì)應(yīng)關(guān)系，需求分析階段使用ERD描述系統(tǒng)中實(shí)體的邏輯關(guān)系，在設(shè)計(jì)階段則使用ERD描述物理表之間的關(guān)系。需求分析階段使用ERD來描述現(xiàn)實(shí)世界中的對(duì)象。ERD只關(guān)注系統(tǒng)中數(shù)據(jù)間的關(guān)系，而缺乏對(duì)系統(tǒng)功能的描述。如果將ERD與DFD兩種方法相結(jié)合，則可以更準(zhǔn)確地描述系統(tǒng)的需求。31用于需求建模的方法 Use Case面向?qū)ο蠓治龅姆椒ǎ菏褂肬se Case來獲取軟件的需求。Use Case通過描述“系統(tǒng)”和“活動(dòng)者”之間的交互來描述系統(tǒng)的行為。通過分解

15、系統(tǒng)目標(biāo)，Use Case描述活動(dòng)者為了實(shí)現(xiàn)這些目標(biāo)而執(zhí)行的所有步驟。Use Case方法最主要的優(yōu)點(diǎn)，在于它是用戶導(dǎo)向的，用戶可以根據(jù)自己所對(duì)應(yīng)的Use Case來不斷細(xì)化自己的需求。此外，使用Use Case還可以方便地得到系統(tǒng)功能的測(cè)試用例。 323、編寫需求文檔需求文檔描述方式:可以使用自然語言或形式化語言來描述，還可以添加圖形的表述方式和模型表征的方式。需求文檔包括:用戶的所有需求（功能性需求和非功能性需求）。編寫需求文檔的工具：軟件開發(fā)工具，其中的信息庫作用較大。 334、評(píng)審需求文檔需求文檔完成后，需要經(jīng)過正式評(píng)審。一般的評(píng)審分為用戶評(píng)審和同行評(píng)審兩類。用戶和開發(fā)方對(duì)于軟件項(xiàng)目?jī)?nèi)容的描述，是以需求規(guī)格說明書作為基礎(chǔ)的； 用戶驗(yàn)收的標(biāo)準(zhǔn)則是依據(jù)需求規(guī)格說明書中的內(nèi)容來制訂，所以評(píng)審需求文檔時(shí)用戶的意見是第一位的。而同行評(píng)審的目的，是在軟件項(xiàng)目初期發(fā)現(xiàn)那些潛在的缺陷或錯(cuò)誤，避免這些錯(cuò)誤和缺陷遺漏到項(xiàng)目的后續(xù)階段。345、管理需求 需求的變更如何以可控的方式管理軟件的需求，有利于項(xiàng)目的順利。需求管理要保證需求分析各個(gè)活動(dòng)都得到了充分