最近在工作中碰到了些需求上的問題，今天有感而發：
需求獲取應該是主動的,不能等客戶來說，因為大多數時候客戶並不清楚他們的真正需求，需要由需求分析人員抽絲剝繭來逐步問出需求。
在訪談前列出要問的問題，然後發給訪談物件，讓他事先對所問問題有個了解，以防出現訪談過程中過多出現「這個問題要仔細想想，等以後告訴你」的情況。
q:客戶忙，如何進行有效的迭代開發溝通？
a：在專案開始前，盡量需求了解完整；並且和客戶重點說明定期碰頭看產品進度的重要性。
q:同一客戶的多名人員都能聯絡你，你該怎麼辦？
a：首先肯定是事先說明這樣做的害處，假如客戶還是多人發需求，則當發生幾次需求衝突之後，借力講明這個事實，以事實來證明由專人接頭需求處理的好處。
q:維護型專案的文件誰來寫？
a：招乙個文案，幫助開發人員寫文件，因為開發人員對寫文件一般是處於拒絕內心狀態的。
這些也只是我的設想解決辦法，不知道是不是行得通。
開發隨筆 需求又是需求
這兩天新系統要正式上線了,從昨天下午一直到今天的下午,在連夜上線.雖然辛苦,但心裡實在憋屈,不吐不快 需求,該死的需求,這是我唯一的想法,我剛到公司時,在了解了公司的現狀後,就感到很是鬱悶,不為別的,要做東西,需求 很多時候只是口頭確認下,還可能隨時修改.看著忙碌的同志們,不由的糾結.這不都要上線了...
隨筆 需求 20201224
1.需求是什麼 2.如何分析需求 3.需求的優先順序 簡單來說，需求就是使用者問題。舉個例子 2010年，某個使用者在路邊打車，怎麼招手也沒有計程車可以停下。因為區域供給太少。這個時候使用者的問題，是希望能夠快速打到車，但是現實無法滿足。當你所在業務線人員較少時，很多需求都是你的一手需求，需求原因 ...
需求工程 需求管理
需求以自然語言進行描述，應該以某種標識方案進行編號。幾種常見的需求標識和分類的技術 最靈活和不容易出錯的方法是利用資料庫生成唯一識別符號的方法。這是因為資料庫系統支援在併發的情況下對每個新資料記錄生成唯一的識別符號。有些資料庫還可以通過版本號擴充套件唯一識別符號的方式來支援對相同記錄的多個版本的維護...