咨詢熱線：
當軟件開發公司在承接軟件外包項目時，需求公司團隊進行項目開發，交付產品，需求分析是一個非常主要核心的過程，所以我們對需求分析進行分解。
1到用戶前的準備
1.1 組織隊伍
根據實際的工作量及其他情況，組建需求調研團隊，提供辦公設備，明確崗位職責、召開項目啟動會。1.2準備相應文檔
乙方的系統分析師同甲方的需求提供人員正式接觸前，制定一個問詢表及需求分析計劃。一般情況下只需要完成一個整體細節問詢表，問詢用戶為明確需求已經完成的文檔情況（如果可以在進行正式接觸前可以得到并了解完成好）、業務目的、當前目標、長遠目標、當前準備情況、完成的業務功能列表、將來系統操作人員的業務及電腦技術了解情況、終操作用戶、當前及將來的硬件、軟件及網絡環境等問題。
由軟件開發公司的系統分析師根據對業務的了解程度，適當編寫各業務功能細節問詢表。不過業務功能細節問詢表的使用，是在業務需求調研過程中用戶表明其需求后，再根據問題還沒有明確的情況下再進行問詢的。
其他業務相關政策法規、技術文檔、技術支持人員的通信錄等也要進行相應的準備。
1.3 聯系及了解用戶方
同用戶進行聯系并取得對方的人員名單、分工情況、權重、工作計劃、工作時間、節假日安排（特別是用戶公司內部的額外規定），如果可能的情況下要求也有用戶的IT人員參加需求過程，實際的需求如果沒有IT人員的參加，在后面的更改一般是IT人員提出的。應在需求過程中把用戶IT人員的需求調研，作為業務調研中一部分。1.4 編寫計劃
根據當前情況，編寫需求分析計劃，明確正式開始日期，中間階段性日期（時間段可多個，調研時間不大于3天），結束時間，人員名單，分工情況，需用戶提供的幫助等。將計劃發送給用戶請其確認，在可能的情況下協調用戶和開發商的計劃，以便共同開展工作。對于計劃如果能編寫及控制到每日是好的，但是否可以達到真正可控制到日，那就看你的能力了。如果每3天為一個中間性階段進行控制，延遲的時間可以通過加班來彌補。計劃好根據一天工作8小時進行。如果要去用戶所在地進行工作，還要準備相應的辦公工具，人手一臺筆記本電腦（電源插座及網絡互連線也要考慮）是比較好的資源配置。2需求調研
2.1 需求調研啟動
本次所說的第一日是軟件開發公司的系統開發人員到用戶處正式需求調研過程的第一日。如果是異地調研，那么在第一日前一日軟件開發公司的系統開發人員應到達用戶所在地，住宿，了解住宿地周邊情況。好是早些休息，為第一日工作開始做好準備。一般第一日的上午是軟件開發公司的系統分析人員和用戶業務需要者進行整體介紹，了解辦公環境，建立需求調研過程辦公環境。如果是小型項目涉及人員不多（雙方人員共同不多于3人），一般上午可以進行調研工作1到2小時，不然下午才能正式開始工作（也就說做計劃時第1天一般只有半日的工作時間）。2.2 調研過程
調研的過程推薦軟件開發公司系統開發人員有專人進行會議記錄，并在每日會議結束后，當場宣布本次會議的結果，并由參加會議人員進行簽字。第二日復印或發送電子文件給參加會議人員及相關人員。以便做到有據可查，明確過程。軟件開發公司系統開發人員每周對用戶提供開發周報，告訴用戶當前開發的進展、是否有問題、是否用戶協助等，這是一個好的加強雙方溝通的方法。注意：在調研過程的中系統開發人員的變更會對計劃產生重大的影響，不要簡單認為是人員更換的問題。因為在調研過程中對業務的理解，不是通過看看文檔就可以達到。3天通過討論達到對需求理解的程序，9天對文檔的學習也不一定能達到。
2.3 三個階段
分析的初期，即總體分析階段，需要得到整體意義上的輪廓需求，此時，應與客戶方總工以上層次的人員進行交流，這一層次的人，對未來的系統會有完整的描繪，可以劃分出子系統、及其之間的關系，這也是高級管理層對系統的期望。可以以此作為綱領性的文檔指導進一步的分析，并約束后續的分析過程，避免需求范圍漫無邊際的擴大；專業系統分析階段，通常，客戶單位都會有專業分工，彼此之間既相互獨立，又會在某些點上發生聯系。此階段應與客戶方專業人員進行深入的討論。這一層次的人，對自己的專業相當熟悉，對專業內的需求會非常到位，大都年富力強，有相當的閱歷和理解能力，甚至自己都可以繪制業務流圖，總結業務功能點。對他們應充分鼓勵，盡量調動其積極性；系統關聯分析階段，在各專業系統得到充分分析的基礎上，緊接著就要理清它們之間的關系，這是提升需求檔次的關鍵階段，也是高級領導層和專業人員都關心的階段。通常，客戶單位都會有一些零散的軟件，如財務軟件，部頒軟件等，這些專業軟件都發揮著重要的作用，但都是些信息孤島，客戶會很自然的希望能把這些信息融合到整個系統中來，為更多的人所共享。同時，也希望數據能夠在各專業系統間順暢的流動，從而減少重復勞動，提高工作效率。此階段應把總工層和專業人員召集到一起，共同理清系統間的接口。經過這三個階段，對需求的描述將比較準確和完整。3 一般情況下需明確的問題
當前整體業務需求的目的
要求提供的需求功能列表
將來發展的設想
明確服務器、客戶機的軟、硬件及性能要求（容量、速度、可操作性等）
用戶目前相關的技術人員和業務人員情況
將來終系統操作人員的技術及業務人員情況
用戶需求的系統及用戶本身或其它系統的接口要求
用戶的其它要求
要求提供的需求功能列表
將來發展的設想
明確服務器、客戶機的軟、硬件及性能要求（容量、速度、可操作性等）
用戶目前相關的技術人員和業務人員情況
將來終系統操作人員的技術及業務人員情況
用戶需求的系統及用戶本身或其它系統的接口要求
用戶的其它要求
4 需求完全明確情況
對于整體調研過后就要進行各個具體業務需求的調研，對于具體需求調研如果是用戶提供的現有文檔，軟件開發公司的系統分析人員只是對業務進行了解及進行修改為系統分析人員及業務人員全可以看懂的需求說明書，那么這個過程就比較容易。只要系統分析人員把業務文檔看懂看明白，并且對于一些難理解的業務描述修改為易懂（有些業務名詞有一定的專業性就要進行額外的說明）、明確進出的單據（數據項）就可以。當然編寫需求說明書具體的細節可以參見其他的眾多的書籍及文件模版。
5 需求不完全明確情況
如果用戶對于自己的需求在調研開始并沒有完全明確，需要進行引導及細化，那么這個過程就比較麻煩了。對于用戶本身需求不明情況下，對于業務要先從基本業務進行細化，對于不明業務或不確定業務在后面進行。對于進出的單據一般在這種情況下用戶當沒有現存文檔，這個過程只需明確單據進出的必須數據源就可以，如果做到細節，由用戶在需求調研期確定單證，是不太可能的----只是設計單據的樣式、風格就不是短時間可以完成的。對于報表也只能明確基本報表要求及數據項。一般這種情況使用原型法進行，先做一個簡單的，在簡單的上面再進行完善。對于用戶本身需求不明情況下的調研要做每日（或2到3天,多3天為間隔）的工作（分析進展）記錄，由雙方簽字，因為調研過程會出現為用戶要求添加一支新業務，對新業務進行分析后，因某些原因發現不能添加。這個過程的結果是一個0，但為證明是0這結果可能花了很長的時間。要記錄這個過程，說明調研過程中做了什么事情，有時有些人可能會說為什么這么長時間才出這點點東西，到時以便說明原因。
6 需求分析的方法
- 繪制系統關聯圖，這種關聯圖是用于定義系統與系統外部實體間的界限和接口的簡單模型。同時它也明確了通過接口的信息流和物質流。
- 創建用戶界面原型，當開發人員或用戶不能確定需求時，開發一個用戶界面原型——一個可能的局部實現，這樣使得許多概念和可能發生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。
- 分析需求可行性，在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。
- 確定需求的優先級別，應用分析方法來確定使用實例、產品特性或單項需求實現的優先級別。以優先級為基礎確定產品版本將包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，并在那個版本計劃中作出需要的變更。
- 為需求建立模型，需求的圖形分析模型是軟件需求規格說明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。
- 依據分析階段確定合適的客戶方配合人員。
- 多方位描述同一需求
-
- 清晰化每一數據項
- 充分挖掘潛在需求
對這些潛在需求，會有兩種處理方式：告訴客戶，客戶會得到啟發，可能進一步提出新的需求，會有一些更大膽的想法，從而擴大了需求范圍，增加了工作量，甚至會影響到工期；不告訴客戶，等客戶想到了再說。
這些需求如果對于產品軟件，可能會是一個賣點，要盡可能的去挖掘。但對項目軟件，考慮各種風險，有時候可能會回避，或對客戶隱瞞。
- 積累領域知識
- 抱著學習與指導并存的態度
7 完成需求確認
對于需求終的確認需求先由系統開發人員對編寫的文檔進行內部審核及修訂，然后交由用戶業務人員進行確認，明確系統開發人員已經了解業務需求，并進行簽字確認。
8 誤區
在進行需求分析的時候，容易陷入一些誤區，導致分析結果不理想。
8.1 分析結果越復雜越好
這是技術型分析人員經常碰到的情況，認為分析出錯綜復雜的關系，花哨的圖表才能顯示出分析水平高。其實，分析經常要經歷"簡單-復雜-簡單"的過程，前一個簡單表現為分析人員"認為簡單"；隨著分析的深入，原以為簡單的問題會越來越復雜；后，經過概括、消化、分解，使得需求簡單明了。8.2 必須一次到位
由于項目工期緊，或者客戶單位地理位置偏遠，不想反復去現場，希望通過一次需求分析就能得到完整的、不再改變的結果。有這種情況時，表現為分析人員對客戶方配合人員窮追猛問，或堅持要求配合人員做出保證，承諾需求范圍不再擴大等等。結果往往是雙方關系緊張，配合人員怕擔責任，提出過多的靈活的、可配置的一些要求，無端增加了后續設計和編碼的工作量。一次到位的想法是不現實的，隨著開發工作的進行，用戶經常會提出以前沒想到的需求，或者更改已有的需求。需求必然有一個迭代的過程，變是不可避免的，關鍵是對于變化的控制，比如通過正規而繁復的流程提高需求變化時客戶付出的代價：告知客戶如此變化將會使工期延長，或需要追加資金等等，盡管對于"軟件屬于買方市場"的現狀來說，開發方往往叫不起這個板，但這樣的控制還是有一定的效果的。8.3 客戶的需求必須全部滿足
陷入這一誤區的分析人員，往往自己的領域知識欠缺，對客戶的需求是否合理，缺乏分辨能力，只能由客戶牽著走，這樣會帶來很大的風險：造成需求冗余，項目返工，更有對需求變化失去控制的危險，隨著項目的開展，整個軟件開發團隊會越來越痛苦。所以必須加深自己的領域知識，變被動接受為主動引導，進而拒絕客戶的不合理需求。【北京華盛恒輝科技有限公司 ——（hivekion）是一家軟件定制開發公司，專注IT產品研發與服務，堅持穩健經營、持續創新、開放合作，在安全生產、大數據處理等領域構筑了端到端的解決方案優勢，為企業客戶提供有競爭力的IT解決方案、 產品和服務。】
合作咨詢
