製造工廠內部的it應用系統開發（一般的erp專案）是否能成功很大程度上取決於「需求分析」的***不好。
在乙個不是很it的組織裡就像我們製造工廠的it部門，要想做好「需求分析」是很有挑戰的，就像要「寫出好的**「一樣有挑戰性。
老闆在催上線，老婆在家等吃飯！誰還管你，需求分析的好不好，
**質量高不高，總之先上線一版完成任務！
噼里啪啦一天天，回頭一看全是坑啊！需求不順，流程有點扭，**裡全是陷阱！夜黑風高夜，全是救火的幹活！
被自己被別人坑了這麼多年，坑里生死幾多回，才明白，老闆所關心的」業務要求「最終還是會落在軟體的質量上，而軟體的質量最終還是要依靠「做好需求，寫好**」來保證。
需求分析不是誰都能做的，不是想做好就能做好的，就像」寫出好**「一樣需要任務的歷練！
最初兩年我做系統設計和程式編碼做的很順，因為前面需求分析做的很好，文件描述準確，流程合理、順暢，系統邊界定義很清晰，人員角色的定義符合業務要求，資料字典定義統一沒有歧義，分析師可把握全域性有原則知道什麼需求在什麼時候可以改，最終要不要改。
但是後來需求分析師做了我的老闆，自己不幹活了，招了個剛畢業的同學做需求分析，從此我們的苦日子來了，各種彆扭，使用者反映寫出的程式不是他們所要的。
麻煩大了，才發現不是簡單按照需求文件的格式寫好文件，需求就能做好的。從此之後需求分析和系統設計的界限開始模糊我們直接和使用者接觸，自己做需求分析，系統設計和編碼，新的需求分析師就做文件整理，程式更新和源**版本管理。
於是我們就開始思考這樣的乙個問題，誰可以做需求分析？如何做好需求分析？
我們先來看看需求分析師面對的挑戰：
從不同方言的業務人員口中，總結出全域性統一的資料字典並合理編碼。
接觸不同的業務人員結合組織架構和崗位設定從中整理出合理的職位角色。
從紛繁複雜的利益糾葛中，梳理出清晰合理的流程。
從不同的業務表單中整理或者重新設計出符合「系統要求」的表單格式。
對關鍵流程關鍵業務功能點的前置條件和後置條件要清楚明了。
最後最重要的一點，要有原則，知道什麼需求能改，該不該改，不能因為需求提出者位高權重或者美貌如花就喪失原則！
需求分析師不一定要會寫**但是「心中一定要有碼」，
要知道物料編碼的通用原則，資料的一般型別和取值長度，知道如何使用編碼來明確區分出唯一筆業務資料。要有全域性概念，可以產出全域性統一的資料字典，你不能弄出個同樣的業務概念在不同的子系統裡資料名字和格式不統一。比如訂單管理系統裡中的規格描述是長度1，長度2，到了倉庫管理系統裡就變成了長度min和長度max，這就是大錯，嚴重的前後不統一。
了解了需求分析的主要工作，那麼誰可以做需求分析，需求分析有哪些產出就不言而明了。
如何做需求分析是乙個因人而異的問題，只要你擅長和人打交道，會根據需求產出的要求提出問題，引導使用者回答問題，從使用者的表述中提煉出有用的資訊並得到使用者肯定，這是乙個很厲害的本領，只有靠經驗積累，經歷任務歷練才成。
當新系統上線運作後，如何對管理好需求變更也是分析師的主要職責，可以參考我們的需求變更流程圖。
總之要做好需求分析和變更管理就要求分析師一定要：
（1）有全域性意識，了解統一的業務流程和組織、職位角色設定，全域性的資料字典，唯一的資料編碼觀念等。
（2）善於和不同的人打交道，會提出關鍵問題，會分析和提煉資訊，形成觀點和概念。
（3）要有原則，知道什麼可以改，什麼不可以改，什麼時候改，由誰來執行等。
需求變更管理
需求變更 是業界公認的專案管理重大挑戰，尤其是專案後期產生的需求變更，對專案的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對專案和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。對於如何應對需求變更，主要的思路有兩條 首先是從源頭做起，提高需...
15 需求分析篇 需求變更
在需求變更這件事上，沒有贏家，每個人都是受害者。國內很多軟體公司，需求變更是常事，導致開發過程中很多 需要修改，不得不加班加點趕進度。1 需求的確定性 建築需求是很具象的，各方都明確地知道要什麼。而軟體工程的需求經常是抽象 模糊 不精確的，隨著開發有了雛形才慢慢想清楚真正想要的是什麼。2 需求變更的...
需求變更管理和需求的可追溯性
在專案管理過程中，總是難免會碰到需求的變更，需求變更之所以會產生，可能是使用者不能清晰描述需求或對需求也不是特別明確，也可能是開發人員對需求理解與使用者不一致，或者是使用者需求確實有更改，或者是遇到其他外部環境的影響 如國家政策 需求的變更總會對專案產生一定的影響，比如專案範圍 專案進度 專案質量 ...