軟件開發(fā)需求分析怎么做0002

1、目錄 1 到用戶前的準(zhǔn)備 2 1.1 組織隊伍 2 1.2 準(zhǔn)備相應(yīng)文檔 2 1.3 聯(lián)系及了解用戶方 2 1.4 編寫計劃 3 2 需求調(diào)研 3 2.1 第一日 3 2.2 調(diào)研過程 3 2.3 三個階段 4 3 一般情況下需明確的問題 4 4 需求完全明確情況 5 5 需求不完全明確情況 5 6 需求分析的方法 6 7 完成需求確認(rèn) 8 8 誤區(qū) 8 8.1 分析結(jié)果越復(fù)雜越好 8 8.2 必須一次到位 8 8.3 客戶的需求必須全部滿足 9 1 到用戶前的準(zhǔn)備 1.1 組織隊伍 根據(jù)實際的工作量及其他情況，組建需求調(diào)研隊伍，提供辦分設(shè)備，明確 責(zé)任、啟動任務(wù)。 1.2 準(zhǔn)備相應(yīng)文檔 開發(fā)

2、商方的系統(tǒng)分析人員同用戶的需求提供人員正式接觸前，完成一個問 詢表及需求分析計劃。 一般情況下只需要完成一個整體細(xì)節(jié)問詢表，問詢用戶為明確需求已經(jīng)完 成的文檔情況（如果可以在進(jìn)行正式接觸前可以得到并了解完成最好） 、業(yè)務(wù) 目的、當(dāng)前目標(biāo)、長遠(yuǎn)目標(biāo)、當(dāng)前準(zhǔn)備情況、完成的業(yè)務(wù)功能列表、將來系統(tǒng) 操作人員的業(yè)務(wù)及電腦技術(shù)了解情況、最終操作用戶、當(dāng)前及將來的硬件、軟 件及網(wǎng)絡(luò)環(huán)境等問題。 由開發(fā)商系統(tǒng)分析人員根據(jù)對業(yè)務(wù)的了解程度，適當(dāng)編寫各業(yè)務(wù)功能細(xì)節(jié) 問詢表。不過業(yè)務(wù)功能細(xì)節(jié)問詢表的使用，是在業(yè)務(wù)需求調(diào)研過程中用戶表明 其需求后，再根據(jù)問題還沒有明確的情況下再進(jìn)行問詢的。 其他業(yè)務(wù)相關(guān)政策法規(guī)、技術(shù)

3、文檔、技術(shù)支持人員的通信錄等也要進(jìn)行相 應(yīng)的準(zhǔn)備。 1.3 聯(lián)系及了解用戶方 同用戶進(jìn)行聯(lián)系并取得對方的人員名單、分工情況、權(quán)重、工作計劃、工 作時間、節(jié)假日安排（特別是用戶公司內(nèi)部的額外規(guī)定） ，如果可能的情況下 要求也有用戶的 IT 人員參加需求過程，實際的需求如果沒有 IT 人員的參加， 在后面的更改一般是 IT 人員提出的。應(yīng)在需求過程中把用戶 IT 人員的需求調(diào) 研，作為業(yè)務(wù)調(diào)研中一部分。 1.4 編寫計劃 根據(jù)當(dāng)前情況，編寫需求分析計劃，明確正式開始日期，中間階段性日期 （時間段可多個，調(diào)研時間不大于 3 天），結(jié)束時間，人員名單，分工情況， 需用戶提供的幫助等。 將計劃發(fā)送給用戶

4、請其確認(rèn)，在可能的情況下協(xié)調(diào)用戶和開發(fā)商的計劃， 以便共同開展工作。 對于計劃如果能編寫及控制到每日是最好的，但是否可以達(dá)到真正可控制 到日，那就看你的能力了。如果每 3 天為一個中間性階段進(jìn)行控制，延遲的時 間可以通過加班來彌補(bǔ)。計劃最好根據(jù)一天工作 8 小時進(jìn)行。 如果要去用戶所在地進(jìn)行工作，還要準(zhǔn)備相應(yīng)的辦公工具，人手一臺筆記 本電腦（電源插座及網(wǎng)絡(luò)互連線也要考慮）是比較好的資源配置。 2 需求調(diào)研 2.1 第一日 本次所說的第一日是開發(fā)商系統(tǒng)開發(fā)人員到用戶處正式需求調(diào)研過程的第 一日。如果是異地調(diào)研，那么在第一日前一日開發(fā)商系統(tǒng)開發(fā)人員應(yīng)到達(dá)用戶 所在地，住宿，了解住宿地周邊情況。最好

5、是早些休息，為第一日工作開始做 好準(zhǔn)備。 一般第一日的上午是開發(fā)商系統(tǒng)分析人員和用戶業(yè)務(wù)需要者進(jìn)行整體介紹， 了解辦公環(huán)境，建立需求調(diào)研過程辦公環(huán)境。如果是小型項目涉及人員不多 （雙方人員共同不多于 3人），一般上午可以進(jìn)行調(diào)研工作 1到 2小時，不然 下午才能正式開始工作（也就說做計劃時第 1天一般只有半日的工作時間） 。 2.2 調(diào)研過程 調(diào)研的過程推薦開發(fā)商系統(tǒng)開發(fā)人員有專人進(jìn)行會議記錄，并在每日會議 結(jié)束后，當(dāng)場宣布本次會議的結(jié)果，并由參加會議人員進(jìn)行簽字。第二日復(fù)印 或發(fā)送電子文件給參加會議人員及相關(guān)人員。以便做到有據(jù)可查，明確過程。 開發(fā)商系統(tǒng)開發(fā)人員每周對用戶提供開發(fā)周報，告訴用

6、戶當(dāng)前開發(fā)的進(jìn)展、 是否有問題、是否用戶協(xié)助等，這是一個好的加強(qiáng)雙方溝通的方法。 注意：在調(diào)研過程的中系統(tǒng)開發(fā)人員的變更會對計劃產(chǎn)生重大的影響，不 要簡單認(rèn)為是人員更換的問題。因為在調(diào)研過程中對業(yè)務(wù)的理解，不是通過看 看文檔就可以達(dá)到。 3 天通過討論達(dá)到對需求理解的程序， 9 天對文檔的學(xué)習(xí)也 不一定能達(dá)到。 2.3 三個階段 分析的初期，即總體分析階段，需要得到整體意義上的輪廓需求，此時， 應(yīng)與客戶方總工以上層次的人員進(jìn)行交流，這一層次的人，對未來的系統(tǒng)會有 完整的描繪，可以劃分出子系統(tǒng)、及其之間的關(guān)系，這也是高級管理層對系統(tǒng) 的期望?？梢砸源俗鳛榫V領(lǐng)性的文檔指導(dǎo)進(jìn)一步的分析，并約束后續(xù)的

7、分析過 程，避免需求范圍漫無邊際的擴(kuò)大； 專業(yè)系統(tǒng)分析階段，通常，客戶單位都會有專業(yè)分工，彼此之間既相互獨 立，又會在某些點上發(fā)生聯(lián)系。此階段應(yīng)與客戶方專業(yè)人員進(jìn)行深入的討論。 這一層次的人，對自己的專業(yè)相當(dāng)熟悉，對專業(yè)內(nèi)的需求會非常到位，大都年 富力強(qiáng)，有相當(dāng)?shù)拈啔v和理解能力，甚至自己都可以繪制業(yè)務(wù)流圖，總結(jié)業(yè)務(wù) 功能點。對他們應(yīng)充分鼓勵，盡量調(diào)動其積極性； 系統(tǒng)關(guān)聯(lián)分析階段，在各專業(yè)系統(tǒng)得到充分分析的基礎(chǔ)上，緊接著就要理 清它們之間的關(guān)系，這是提升需求檔次的關(guān)鍵階段，也是高級領(lǐng)導(dǎo)層和專業(yè)人 員都關(guān)心的階段。通常，客戶單位都會有一些零散的軟件，如財務(wù)軟件，部頒 軟件等，這些專業(yè)軟件都發(fā)揮著重

8、要的作用，但都是些信息孤島，客戶會很自 然的希望能把這些信息融合到整個系統(tǒng)中來，為更多的人所共享。同時，也希 望數(shù)據(jù)能夠在各專業(yè)系統(tǒng)間順暢的流動，從而減少重復(fù)勞動，提高工作效率。 此階段應(yīng)把總工層和專業(yè)人員召集到一起，共同理清系統(tǒng)間的接口。 經(jīng)過這三個階段，對需求的描述將比較準(zhǔn)確和完整。 3 一般情況下需明確的問題 當(dāng)前整體業(yè)務(wù)需求的目的 要求提供的需求功能列表 將來發(fā)展的設(shè)想 明確服務(wù)器、客戶機(jī)的軟、硬件及性能要求（容量、速度、可操作性等） 用戶目前相關(guān)的技術(shù)人員和業(yè)務(wù)人員情況 將來最終系統(tǒng)操作人員的技術(shù)及業(yè)務(wù)人員情況 用戶需求的系統(tǒng)及用戶本身或其它系統(tǒng)的接口要求 用戶的其它要求 4 需求完

9、全明確情況 對于整體調(diào)研過后就要進(jìn)行各個具體業(yè)務(wù)需求的調(diào)研，對于具體需求調(diào)研 如果是用戶提供的現(xiàn)有文檔，開發(fā)商的系統(tǒng)分析人員只是對業(yè)務(wù)進(jìn)行了解及進(jìn) 行修改為系統(tǒng)分析人員及業(yè)務(wù)人員全可以看懂的需求說明書，那么這個過程就 比較容易。 只要系統(tǒng)分析人員把業(yè)務(wù)文檔看懂看明白，并且對于一些難理解的業(yè)務(wù)描 述修改為易懂（有些業(yè)務(wù)名詞有一定的專業(yè)性就要進(jìn)行額外的說明） 、明確進(jìn) 出的單據(jù)（數(shù)據(jù)項）就可以。當(dāng)然編寫需求說明書具體的細(xì)節(jié)可以參見其他的 眾多的書籍及文件模版。 5 需求不完全明確情況 如果用戶對于自己的需求在調(diào)研開始并沒有完全明確，需要進(jìn)行引導(dǎo)及細(xì) 化，那么這個過程就比較麻煩了。 對于用戶本身需求

10、不明情況下，對于業(yè)務(wù)要先從基本業(yè)務(wù)進(jìn)行細(xì)化，對于 不明業(yè)務(wù)或不確定業(yè)務(wù)在后面進(jìn)行。對于進(jìn)出的單據(jù)一般在這種情況下用戶當(dāng) 沒有現(xiàn)存文檔，這個過程只需明確單據(jù)進(jìn)出的必須數(shù)據(jù)源就可以，如果做到細(xì) 節(jié)，由用戶在需求調(diào)研期確定單證，是不太可能的 只是設(shè)計單據(jù)的樣式、 風(fēng)格就不是短時間可以完成的。對于報表也只能明確基本報表要求及數(shù)據(jù)項。 一般這種情況使用原型法進(jìn)行，先做一個簡單的，在簡單的上面再進(jìn)行完善。 對于用戶本身需求不明情況下的調(diào)研要做每日（或 2到3天,最多 3天為間 隔）的工作（分析進(jìn)展）記錄，由雙方簽字，因為調(diào)研過程會出現(xiàn)為用戶要求 添加一支新業(yè)務(wù)，對新業(yè)務(wù)進(jìn)行分析后，因某些原因發(fā)現(xiàn)不能添加。

11、這個過程 的結(jié)果是一個 0，但為證明是 0 這結(jié)果可能花了很長的時間。要記錄這個過程， 說明調(diào)研過程中做了什么事情，有時有些人可能會說為什么這么長時間才出這 點點東西，到時以便說明原因。 6 需求分析的方法 1. 繪制系統(tǒng)關(guān)聯(lián)圖，這種關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接 口的簡單模型。同時它也明確了通過接口的信息流和物質(zhì)流。 2. 創(chuàng)建用戶界面原型，當(dāng)開發(fā)人員或用戶不能確定需求時，開發(fā)一個用戶界面 原型一個可能的局部實現(xiàn)，這樣使得許多概念和可能發(fā)生的事更為直觀 明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。 3. 分析需求可行性，在允許的成本、性能要求下，分析每

12、項需求實施的可行性， 明確與每項需求實現(xiàn)相聯(lián)系的風(fēng)險，包括與其它需求的沖突，對外界因素的 依賴和技術(shù)障礙。 4. 確定需求的優(yōu)先級別，應(yīng)用分析方法來確定使用實例、產(chǎn)品特性或單項需求 實現(xiàn)的優(yōu)先級別。以優(yōu)先級為基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或哪類需求。 當(dāng)允許需求變更時，在特定的版本中加入每一項變更，并在那個版本計劃中 作出需要的變更。 5. 為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說明極好的補(bǔ)充說明。 它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和 冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框 圖、對象類及交互作用圖。 6. 依據(jù)分析階段確定合

13、適的客戶方配合人員。 7. 多方位描述同一需求 有一些需求貫穿了從基層人員到高層領(lǐng)導(dǎo)，對此需求應(yīng)該從各個角度、 各個方位給以描述，總結(jié)之后才能得到完整的表達(dá)，否則可能會漏掉一些 信息。這也為后續(xù)的設(shè)計工作打好基礎(chǔ)。 比如，在設(shè)備管理類軟件中，有一個概念叫 缺陷 ，指由于材料老化或 外力作用，使得設(shè)備處于不正常的運(yùn)行狀態(tài)，但還沒有到立刻就釀成 事故 的程度，但如不及時檢修，就可能出事。對于設(shè)備缺陷業(yè)務(wù)，就涉及到從 班組人員到領(lǐng)導(dǎo)，上上下下對此都非常關(guān)心，但各層次的人關(guān)心的側(cè)重點 卻不盡相同：領(lǐng)導(dǎo)關(guān)心 消缺率（即缺陷消除率）、消缺及時率 ；專業(yè)人 員關(guān)心缺陷類型和處理方法；班組人員關(guān)心消缺工作的人

14、員安排及時間地 點。缺陷的業(yè)務(wù)處理流程依賴于 設(shè)備缺陷單 （用于記錄缺陷及消除情況） ， 如果僅僅局限于從由基層得到的設(shè)備缺陷單上的數(shù)據(jù)結(jié)構(gòu)（設(shè)備名稱、缺 陷發(fā)現(xiàn)人、發(fā)現(xiàn)時間、二級單位確認(rèn)時間、缺陷性質(zhì)、安排消缺時間、消 缺人員、消除日期、處理方法） ，無法滿足專業(yè)人員的分析要求：對設(shè)備 的缺陷情況按類型、零部件、型號、生產(chǎn)廠家等分類統(tǒng)計，為設(shè)備采購時 作為選型參考、調(diào)整設(shè)備及其零部件的檢修周期以減少缺陷發(fā)生的頻率等， 因此需要在原來的設(shè)備缺陷單上增加一些相關(guān)信息。 8. 清晰化每一數(shù)據(jù)項 由于需求將作為設(shè)計的基礎(chǔ)，弄清所有的數(shù)據(jù)項的來龍去脈對于設(shè)計 是必不可少的。不能有模糊不清的地方，同時通

15、過對數(shù)據(jù)項來源的分析， 可以讓分析人員更清楚的看到數(shù)據(jù)的流動情況，也會發(fā)現(xiàn)一些新的需求點。 9. 充分挖掘潛在需求 由于分析人員對軟件技術(shù)非常熟悉，一些由于技術(shù)所帶來的潛在需求 對于客戶來說，一般很難被發(fā)現(xiàn)。不實現(xiàn)這些需求，對整個系統(tǒng)也沒什么 實質(zhì)性的影響；實現(xiàn)這些需求，則會錦上添花。 對這些潛在需求，會有兩種處理方式：告訴客戶，客戶會得到啟發(fā)， 可能進(jìn)一步提出新的需求，會有一些更大膽的想法，從而擴(kuò)大了需求范圍， 增加了工作量，甚至?xí)绊懙焦て?；不告訴客戶，等客戶想到了再說。 這些需求如果對于產(chǎn)品軟件，可能會是一個賣點，要盡可能的去挖掘。 但對項目軟件，考慮各種風(fēng)險，有時候可能會回避，或?qū)蛻?/p>

16、隱瞞。 10. 積累領(lǐng)域知識 領(lǐng)域知識對于分析人員很重要，這些知識的廣度和深度影響分析結(jié)果 的準(zhǔn)確性和分析進(jìn)度。分析人員應(yīng)該通過各種途徑去獲取這些，不斷積累， 并進(jìn)行比較和總結(jié)。 11. 抱著學(xué)習(xí)與指導(dǎo)并存的態(tài)度 面對一個新的客戶時，分析人員首先必須抱著謙遜的學(xué)習(xí)的態(tài)度，把 這看成是豐富領(lǐng)域知識的機(jī)會。但并非客戶單位的任何層次的人都有值得 學(xué)習(xí)的東西，隨著分析人員接觸的領(lǐng)域客戶不斷增多，分析人員對該領(lǐng)域 的理解也會越來越深，逐漸會成長為領(lǐng)域?qū)＜遥瑫泻芏嗟胤匠^客戶對 領(lǐng)域的理解，此時，要以自己的深入理解去指導(dǎo)客戶，說服客戶，甚至糾 正客戶的一些錯誤的認(rèn)識，得到客戶的信任與尊敬，這對迅速順利的

17、完成 需求分析會很有幫助。 7 完成需求確認(rèn) 對于需求最終的確認(rèn)需求先由系統(tǒng)開發(fā)人員對編寫的文檔進(jìn)行內(nèi)部審核及 修訂，然后交由用戶業(yè)務(wù)人員進(jìn)行確認(rèn)，明確系統(tǒng)開發(fā)人員已經(jīng)了解業(yè)務(wù)需求， 并進(jìn)行簽字確認(rèn)。 8 誤區(qū) 在進(jìn)行需求分析的時候，容易陷入一些誤區(qū)，導(dǎo)致分析結(jié)果不理想。 8.1 分析結(jié)果越復(fù)雜越好 這是技術(shù)型分析人員經(jīng)常碰到的情況，認(rèn)為分析出錯綜復(fù)雜的關(guān)系，花哨 的圖表才能顯示出分析水平高。其實，分析經(jīng)常要經(jīng)歷 簡單-復(fù)雜 -簡單的過程， 前一個簡單表現(xiàn)為分析人員 認(rèn)為簡單 ；隨著分析的深入，原以為簡單的問題 會越來越復(fù)雜；最后，經(jīng)過概括、消化、分解，使得需求簡單明了。 8.2 必須一次到位 由于項目工期緊，或者客戶單位地理位置偏遠(yuǎn)，不想反復(fù)去現(xiàn)場，希望通 過一次需求分析就能得到完整的、不再改變的結(jié)果。有這種情況時，表現(xiàn)為分 析人員對客戶方配合人員窮追猛問，或堅持要求配合人員做出保證，承諾需求 范圍不再擴(kuò)大等等。結(jié)果往往是雙方關(guān)系緊張，配合人員怕?lián)?zé)任，提出過多 的靈活的、可配置的一些要求，無端增加了后續(xù)設(shè)計和編碼的工作量。一次到 位的想法是不現(xiàn)實的，隨著開發(fā)工作的進(jìn)行，用戶經(jīng)常會提出以前沒想到的需 求，或者更改已有的需求。需求必然有一個迭代的過程，變是不可避免的，關(guān) 鍵是