參與人事檔案管理系統將近一年了，這一年中通過這個專案發現了很多問題，無論是在軟體設計方面還是在團隊合作方面以及在與使用者交流獲取需求的過程中
暴露出了很多問題，也學到了很多東西。今天主要總結一下在需求分析上的問題與收穫
。在軟體生存週期中，其他四個階段都是面向軟體技術問題，僅僅有需求分析階段是面向使用者的。
需求分析是對使用者的業務活動進行分析，明白在使用者的業務環境中軟體系統應該"做什麼"。
可是在開始的時候。我們和使用者兩方都不能準確地提出系統要"做什麼？"。而我們又不是使用者問題領域的專家，不熟悉使用者的業務活動和業務環境，又不可能在短期內搞清楚；而使用者不熟悉計算機應用的有關問題。因此兩方互相不了解對方的工作。又缺乏共同語言，所以在交流時存在著隔閡。
需求分析是軟體project中非常重要的乙個環節，直接決定著專案的成敗。需求分析是一項重要的工作，也是最難的工作。
需求分析的方法有非常多種，如面向過程（自上向下分解）、 資訊project（資料驅動）（資料流分析結構化分析方法）、 物件導向（物件驅動）。
這些方法非常有用對需求分析過程來說也非經常常使用，可是對於我們這些全然不了解使用者業務的開發者來說再好的分析方法也用不上，不了解業務不知道怎樣將業務一層層分解、不能正確的把握資料的流向，更不用談物件導向了。
面對這種情況，我們僅僅能每次接受使用者的一部分需求，然後做乙個最基礎的原型出來。這種原型要比需求分析方法中的原型方法複雜一點。需求分析的原型方法僅僅要求我們用某些軟體工具高速的建造乙個原型系統。這個系統僅僅是乙個介面，然後聽取使用者的意見。改進這個原型。
以後的目標系統就在原型系統的基礎上開發。而現實中假設我們僅僅做乙個介面的話，乙個沒有資料的乙個空殼子。對於不懂怎樣開發軟體、不知道何為原型的使用者來說，讓他們從這種原型上去提建議、提需求還是有些困難的。所以我們在原型方法的基礎上將獲得的原型功能所有實現了。以此作為乙個原型再去進一步獲取需求。
談到原型方法就得必須談談原型方法的三種型別：探索型、實驗型、進化型。
探索型：目的是要弄清楚對目標系統的要求。確定所希望的特性。並**多種方案的可行性。
實驗型：用於大規模開發和實現前，考核方案是否合適。規格說明是否可靠。
進化型：目的不在於改進規格說明。而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成終於系統。
我們主要以進化型為主以探索型為輔，探索使用者目標需求終於確定一種可行性。這樣迭代將每一種可行性在上一可行性的基礎上疊加，走進化型路線，逐步將原型進化成終於的系統。
對於需求變更是最令人頭疼的事。首先由於我們不清楚業務所以最初是使用者帶著我們走。這樣即使使用者提出的需求存在問題，我們也沒法去發現問題或者向使用者提出我們的建議，去避免這些風險從而避免後期的需求變更。
站在使用者的角度來說。他們非常難精確完整地提出它的功能和效能要求。一開始僅僅能提出乙個大概、模糊的功能，僅僅有經過長時間的重複認識才逐步明白。有時進入到設計、程式設計階段才幹明白，更有甚者，到開發後期還在提新的要求。更何況有時候有些詳細實現明明就是按需求完畢的，但使用者還是會更該需求，由於最初的需求是大概的、抽象的、模糊的。一但這些需求轉變成實現再經過一段重複的認識使用者提出一些更改也是在所難免的。面對需求變更我們要做的一是要做好準備應對需求變更。將風險降到最低。二是做好需求變更記錄。
當我們拿到使用者的需求時，有時這種需求僅僅符合軟體的區域性要求。而要將這些需求實現而且跟其它模組進行融合還須要去巨集觀掌控將這些需求適當改造，達到既能滿足使用者的需求還能符合系統的總體需求，這種需求實現才幹更好的為系統提供服務。
對於將來要變更的需求。我認為緊緊做到嚴格控制需求變更的申請流程以及做好變更記錄是遠遠不夠的，由於有些需求的變更是不可避免的。
我們還要在軟體開發階段將這些風險減少。在軟體開發階段可採取物件導向的設計思想。在設計之初多多應用設計模式，充分考慮將要變化的需求，預留出介面。還有一方面就是將軟體的功能之間盡可能的解耦。做到靈活可配置。兩種方法有點共同之處，首先可能不應用設計模式的話我們只須要乙個類幾個方法就能夠滿足需求，而我們還要去抽象出介面，建立實現類之間的聯絡。這樣有點將簡單的問題複雜話的意思，相同軟體功能做靈活不只須要我們把這個功能實現出來。還須要我們後期將這個功能進一步做成可配置、可管理，這就須要我們額外加入功能去配置去管理將要變化的功能，從而實現將功能的變化控制在乙個可控的範圍內。
以往做系統需求都非常明白，而且還有原型系統作為參考。非常少可以凸顯出需求分析的重要性。
自己提需求，然後自己開發系統，這樣明顯減少了非常多要求，而開發出來的系統也僅僅能自己用。軟體project學了那麼多。需求分析的方法也學了非常多。但與實際應用聯絡起來的實踐機會還非常少，所以我們對知識的掌握還停留在理論層次上，真正碰到問題的時候還不能做到手到擒來。
而這一次是第一次將需求提供與開發角色分離需，也就決定了系統開發不再所有以我們開發者自己的意志為轉移。很多其它的是站在使用者的角度去思考問題、解決這個問題。
談需求分析工作
在專案管理過程中，需求範圍是整個軟體工程的基礎。需求範圍定義的好壞，影響到整個專案的目標，進度，成本等專案因素。只有在前期理解業務人員的業務需求下，通過自身資訊化專業知識去轉化這些業務需求的合理性，必要性及重用性，進而分析出業務需求的整個實施方案。在理解專案需求的過程中，有幾個誤區，值得大家參考。1...
我談需求分析 001
當前期的專案準備工作都完成以後，需求分析人員進入客戶的辦公環境進行需求調研，一切如何開始呢？以下是我的一些工作方法 1 理解專案範圍，比如人力資源管理系統，需求分析人員先要去了解人力資源的一些常用術語和基礎知識，理解客戶的專案範圍是在人力資源的哪個領域。2 確定主要干係人 這裡的主要干係人是指調研的...
專案需求分析
一.需求從哪來？軟體專案的需求分析一般要分資訊管理系統 頻道，這兩個不同方向的需求分析的獲取需求的途徑是截然不同。資訊管理系統的使用者確定，獲取需求的途徑明確，而且有現成的業務模式和業務流程，相關的資訊表單 基礎資料等都比較完善，這類專案的需求分析就直接可以從這個資訊管理系統的直接使用者那裡在前期相...