如何確定需求分析是正確的？
這個問題一直被開發團隊關注，並且會一直關注下去。
問題是，什麼樣的需求分析是完全符合使用者的需求？如何驗證需求調研人員獲得的需求同使用者需求是一致的？
其實有最簡單的答案，有人想到了，但是很多人認為不可能。
答案就是：給客戶最終的執行的系統，讓使用者看到，就可以確定最終的系統是不是真正的需求。
這個答案是哲學的，也可以說是反過程的，所以跟現實過程有些不相容。
是啊，給了使用者最終執行的系統，那豈不是開發過程已經結束了，那還要需求調研有屁用？
這裡就需要我們仔細分析從需求到最終的系統的全程同使用者需求的關係了。
如果把專案起點定為0，專案結束定為100，那麼從0開始，需求調研人員將會同使用者溝通需求。
隨著需求的多次溝通，專案的進度由0變成10，20，30，比如到了30我們可以進入設計了，進度繼續40，50，60，然後進入開發過程，70，80，90，最後測試和修改，使用者測試完成後，專案100完成。
可以看到，如果沒有前期的過程，就沒有最終的成果，沒有10，20，30，也就沒有後續的數字，也就沒有100。
在需求分析階段，分析人員會通過各種方法進行確認，比如原型工具，uml工具，甚至畫圖和開發可拋棄的原型，通過不同的迭代後，形成了最終需求。
如果我們有乙個工具，類似原型工具，但是比原型工具更先進，可以省略後續的**階段的工作，那豈不是在需求階段就完成了專案的開發？
是的，在需求階段完成專案，就是我們確定需求最簡單，最快捷，最可靠，最節省時間的方式。
專案需求確認要求
邏輯性 對需求的邏輯性進行判斷，判斷需求的邏輯性是否符合產品設計的效果。是否可以根據設計解決實際問題 上下游 根據需求所要求的資料，判斷資料的 是否可以滿足。每乙個資料都要判斷 功能性 判斷產品提出的特殊功能是否可以實現，具體操作情況。er圖 對於功能複雜的設計最好有er圖出現，對整體邏輯程序確認。...
專案需求確認之後如何防止客戶新增需求的蔓延？
在實際做專案的過程中，往往出現這樣的情況。我們和客戶就需求問題簽下了確認檔案，但是在實際開發過程中，客戶根據已經成型的專案，想法開始氾濫。如何有效地控制客戶需求的蔓延，我覺得，可以通過優先順序排序的方式來進行處理。在實際開發過程中，凡是客戶提出的，不在當初確認時簽的需求框架之內的，評估後如果能夠答應...
專案需求確認之後如何防止客戶新增需求的蔓延？
在實際做專案的過程中，往往出現這樣的情況。我們和客戶就需求問題簽下了確認檔案，但是在實際開發過程中，客戶根據已經成型的專案，想法開始氾濫。如何有效地控制客戶需求的蔓延，我覺得，可以通過優先順序排序的方式來進行處理。在實際開發過程中，凡是客戶提出的，不在當初確認時簽的需求框架之內的，評估後如果能夠答應...