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

1、目錄1 到用戶前的準備 21.1 組織隊伍 21.2 準備相應文檔 21.3 聯(lián)系及了解用戶方 21.4 編寫計劃 32 需求調(diào)研 32.1 第一日 32.2 調(diào)研過程 32.3 三個階段 43 一般情況下需明確的問題 44 需求完全明確情況 55 需求不完全明確情況 56 需求分析的方法 67 完成需求確認 88 誤區(qū) 88.1 分析結(jié)果越復雜越好 88.2 必須一次到位 88.3 客戶的需求必須全部滿足 91 到用戶前的準備1.1 組織隊伍根據(jù)實際的工作量及其他情況，組建需求調(diào)研隊伍，提供辦分設備，明確 責任、啟動任務。1.2 準備相應文檔開發(fā)商方的系統(tǒng)分析人員同用戶的需求提供人員正式接觸

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

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

4、工作。對于計劃如果能編寫及控制到每日是最好的，但是否可以達到真正可控制 到日，那就看你的能力了。如果每 3 天為一個中間性階段進行控制，延遲的時 間可以通過加班來彌補。計劃最好根據(jù)一天工作 8 小時進行。如果要去用戶所在地進行工作，還要準備相應的辦公工具，人手一臺筆記 本電腦（電源插座及網(wǎng)絡互連線也要考慮）是比較好的資源配置。2 需求調(diào)研2.1 第一日本次所說的第一日是開發(fā)商系統(tǒng)開發(fā)人員到用戶處正式需求調(diào)研過程的第 一日。如果是異地調(diào)研，那么在第一日前一日開發(fā)商系統(tǒng)開發(fā)人員應到達用戶 所在地，住宿，了解住宿地周邊情況。最好是早些休息，為第一日工作開始做 好準備。一般第一日的上午是開發(fā)商系統(tǒng)分析

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

6、注意：在調(diào)研過程的中系統(tǒng)開發(fā)人員的變更會對計劃產(chǎn)生重大的影響，不 要簡單認為是人員更換的問題。因為在調(diào)研過程中對業(yè)務的理解，不是通過看 看文檔就可以達到。 3 天通過討論達到對需求理解的程序， 9 天對文檔的學習也 不一定能達到。2.3 三個階段分析的初期，即總體分析階段，需要得到整體意義上的輪廓需求，此時， 應與客戶方總工以上層次的人員進行交流，這一層次的人，對未來的系統(tǒng)會有 完整的描繪，可以劃分出子系統(tǒng)、及其之間的關(guān)系，這也是高級管理層對系統(tǒng) 的期望?？梢砸源俗鳛榫V領性的文檔指導進一步的分析，并約束后續(xù)的分析過 程，避免需求范圍漫無邊際的擴大；專業(yè)系統(tǒng)分析階段，通常，客戶單位都會有專業(yè)分工

7、，彼此之間既相互獨 立，又會在某些點上發(fā)生聯(lián)系。此階段應與客戶方專業(yè)人員進行深入的討論。 這一層次的人，對自己的專業(yè)相當熟悉，對專業(yè)內(nèi)的需求會非常到位，大都年 富力強，有相當?shù)拈啔v和理解能力，甚至自己都可以繪制業(yè)務流圖，總結(jié)業(yè)務 功能點。對他們應充分鼓勵，盡量調(diào)動其積極性；系統(tǒng)關(guān)聯(lián)分析階段，在各專業(yè)系統(tǒng)得到充分分析的基礎上，緊接著就要理 清它們之間的關(guān)系，這是提升需求檔次的關(guān)鍵階段，也是高級領導層和專業(yè)人 員都關(guān)心的階段。通常，客戶單位都會有一些零散的軟件，如財務軟件，部頒 軟件等，這些專業(yè)軟件都發(fā)揮著重要的作用，但都是些信息孤島，客戶會很自 然的希望能把這些信息融合到整個系統(tǒng)中來，為更多的人

8、所共享。同時，也希 望數(shù)據(jù)能夠在各專業(yè)系統(tǒng)間順暢的流動，從而減少重復勞動，提高工作效率。 此階段應把總工層和專業(yè)人員召集到一起，共同理清系統(tǒng)間的接口。經(jīng)過這三個階段，對需求的描述將比較準確和完整。3 一般情況下需明確的問題當前整體業(yè)務需求的目的 要求提供的需求功能列表將來發(fā)展的設想 明確服務器、客戶機的軟、硬件及性能要求（容量、速度、可操作性等） 用戶目前相關(guān)的技術(shù)人員和業(yè)務人員情況 將來最終系統(tǒng)操作人員的技術(shù)及業(yè)務人員情況 用戶需求的系統(tǒng)及用戶本身或其它系統(tǒng)的接口要求用戶的其它要求4 需求完全明確情況對于整體調(diào)研過后就要進行各個具體業(yè)務需求的調(diào)研，對于具體需求調(diào)研 如果是用戶提供的現(xiàn)有文檔，

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

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

11、時有些人可能會說為什么這么長時間才出這 點點東西，到時以便說明原因。6 需求分析的方法1. 繪制系統(tǒng)關(guān)聯(lián)圖，這種關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接 口的簡單模型。同時它也明確了通過接口的信息流和物質(zhì)流。2. 創(chuàng)建用戶界面原型，當開發(fā)人員或用戶不能確定需求時，開發(fā)一個用戶界面 原型一個可能的局部實現(xiàn)，這樣使得許多概念和可能發(fā)生的事更為直觀 明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。3. 分析需求可行性，在允許的成本、性能要求下，分析每項需求實施的可行性， 明確與每項需求實現(xiàn)相聯(lián)系的風險，包括與其它需求的沖突，對外界因素的 依賴和技術(shù)障礙。4. 確定需求的優(yōu)先

12、級別，應用分析方法來確定使用實例、產(chǎn)品特性或單項需求 實現(xiàn)的優(yōu)先級別。以優(yōu)先級為基礎確定產(chǎn)品版本將包括哪些特性或哪類需求。 當允許需求變更時，在特定的版本中加入每一項變更，并在那個版本計劃中 作出需要的變更。5. 為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。 它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和 冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框 圖、對象類及交互作用圖。6. 依據(jù)分析階段確定合適的客戶方配合人員。7. 多方位描述同一需求 有一些需求貫穿了從基層人員到高層領導，對此需求應該從各個角度、 各個方位給以描述，總結(jié)

13、之后才能得到完整的表達，否則可能會漏掉一些 信息。這也為后續(xù)的設計工作打好基礎。比如，在設備管理類軟件中，有一個概念叫 缺陷 ，指由于材料老化或 外力作用，使得設備處于不正常的運行狀態(tài)，但還沒有到立刻就釀成 事故 的程度，但如不及時檢修，就可能出事。對于設備缺陷業(yè)務，就涉及到從 班組人員到領導，上上下下對此都非常關(guān)心，但各層次的人關(guān)心的側(cè)重點 卻不盡相同：領導關(guān)心 消缺率（即缺陷消除率）、消缺及時率 ；專業(yè)人 員關(guān)心缺陷類型和處理方法；班組人員關(guān)心消缺工作的人員安排及時間地 點。缺陷的業(yè)務處理流程依賴于 設備缺陷單 （用于記錄缺陷及消除情況） ， 如果僅僅局限于從由基層得到的設備缺陷單上的數(shù)據(jù)

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

15、常熟悉，一些由于技術(shù)所帶來的潛在需求 對于客戶來說，一般很難被發(fā)現(xiàn)。不實現(xiàn)這些需求，對整個系統(tǒng)也沒什么 實質(zhì)性的影響；實現(xiàn)這些需求，則會錦上添花。對這些潛在需求，會有兩種處理方式：告訴客戶，客戶會得到啟發(fā)， 可能進一步提出新的需求，會有一些更大膽的想法，從而擴大了需求范圍， 增加了工作量，甚至會影響到工期；不告訴客戶，等客戶想到了再說。這些需求如果對于產(chǎn)品軟件，可能會是一個賣點，要盡可能的去挖掘。 但對項目軟件，考慮各種風險，有時候可能會回避，或?qū)蛻綦[瞞。10. 積累領域知識領域知識對于分析人員很重要，這些知識的廣度和深度影響分析結(jié)果的準確性和分析進度。分析人員應該通過各種途徑去獲取這些，不

16、斷積累，并進行比較和總結(jié)。11. 抱著學習與指導并存的態(tài)度面對一個新的客戶時，分析人員首先必須抱著謙遜的學習的態(tài)度，把 這看成是豐富領域知識的機會。但并非客戶單位的任何層次的人都有值得 學習的東西，隨著分析人員接觸的領域客戶不斷增多，分析人員對該領域 的理解也會越來越深，逐漸會成長為領域?qū)＜?，會有很多地方超過客戶對 領域的理解，此時，要以自己的深入理解去指導客戶，說服客戶，甚至糾 正客戶的一些錯誤的認識，得到客戶的信任與尊敬，這對迅速順利的完成 需求分析會很有幫助。7 完成需求確認對于需求最終的確認需求先由系統(tǒng)開發(fā)人員對編寫的文檔進行內(nèi)部審核及 修訂，然后交由用戶業(yè)務人員進行確認，明確系統(tǒng)開發(fā)

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