1樓：小奕
當前的業務系統開發的成功率之所以越來越低，除了使用者的需求越來越複雜之外，還有一個很重要的原因就是使用者的需求越來越不明確。當使用者在考慮開發這個系統時，他們之前的需求並不明確，他們並沒有考慮到所有需求的細節，而只是想了一個大概。
面對這種情況傳統的做需求的方法，肯定不能滿足。而敏捷所提倡的和使用者工作在一起，迭代式做需求的方法是一個很好的方法。但是其實在使用這些方法的時候也會遇到很多問題。
例如，會有下面的問題：問題1：一般開發公司和使用者都有物理距離的限制，而需求分析人員以及設計人員開發人員也不可能從專案開始到結束都在客戶這邊。
這裡面有開發公司成本問題。問題2：專案的需求分析人員並不是一定熟悉專案業務領域，更不是這個領域的專家，所以這對需求的獲取和分析都會帶來一些困難。
問題3：如果專案時**的專案，而且如果負責提出主要需求的是個領導，那就會很麻煩了。因為領導可能整天開會，能和你一起討論需求時間很少，所以這時就會需到很大的問題。
問題4：如果專案是個爛尾專案呢？什麼是爛尾專案呢？
就是指面子工程，當然客戶基本上也都是xx
，不是xx
，誰也沒有那麼多閒錢來搞這些東西，但東西，這些專案確實又養活了很多軟體公司。這樣的專案基本上有大致的需求，但細節沒有人關心，基本上也沒有人去做需求，等領導來檢查了，然後就開始急著提需求，然後要求馬上就要做出來。這種情況下，基本上需求都要靠開發公司自己來想，並且在很長時間內使用者可能沒有任何需求，但如果領導要來檢查，可能又會提出一系列的要求，並要求在很短的時間內提交。
問題5：如果客戶方的專案負責人不是當前領域的專家，那就更麻煩了。因為他是專案的負責人，所以基本上所有的需求都應該和這個人交流。
但是這個人確實不熟悉他們的業務領域，所以做出來的需求可能並不是使用者真正需要的。當真正使用這些功能的人員時間交流時，可能會出現偏差，否定之前那個人的需求。這時可能剛開始提出那個需求的人就會有些意見。
這也會導致一系列的問題。
最近我們的一個專案，做需求就遇到了一些困難：
首先我們的這個專案時xx的專案，是規劃方面的。他們的一個領導是規劃方面出身，是這個專案的最終負責人。但這個領導很忙，整天開會，時間很少，所有就讓下面的一個人來負責我們的需求。
但是這個人又不是搞規劃出身，所以基本上提不出特別好的需求。有些需求做出來之後，當那個領導有時間討論時，發現有些需求可能是不對的，所以造成了我們做需求很困難。
問題3：如果專案時**專案，領導又很忙的話，那就讓他指派一個人，專門負責這個專案的需求，並定期的和這個領導彙報就可以了。問題4：
如果這個專案時一個爛尾專案，需求不好做，我覺得就可以專門有個人盯著這個專案，平常也可以幹別的事，等使用者提要求了，再做。既然使用者是這樣的，我們也沒有太好的辦法，只能使用非常規手段了。問題5：
一定要讓客戶安排一個領域方面的專家來和自己交流需求，否則，做需求的時候肯定會遇到很多困難。
第二：即使開發公司瞭解該領域的業務，也應該派一個人和使用者在一起工作，請教使用者各種他們工作的細節以及領域方面的知識。派誰去呢?
需求分析人員還是其他人？我覺得專案經理最合適，因為一般專案經理從專案開始啟動，到專案最後結束都要跟著，而其他的人員可能在中間會參與其他的專案。而需求的獲取，改變在整個專案的生命週期中也都會有。
而專案經理要和使用者進行交流，必須瞭解使用者的領域業務，否則如果連使用者說的一些領域名詞都不能理解的話，那需求做起來就比較麻煩了。
第三：使用者方要找到一個懂得業務的人員來和軟體開發方的人員交流需求，並且有充足的時間來和使用者一起討論需求。如果使用者方讓一個不懂業務的人員來和你一起交流業務的話，作為專案經理，你最好拒絕。
就想我們這個專案似的，現在遇到了很多的麻煩，就和這個地方有關，但現在由於很多原因，不能中間換人，所以搞的我們現在很被動。
第四：那就是迭代做需求，這個是敏捷開發的精神，所以我預設大家都是這麼做需求的，並放在了最後一條。
2樓：匿名使用者
國內的有阿里巴巴的一個工具，叫雲效，可以支援敏捷開發，在工具上就支援敏捷，據說他們的雙11大型專案的敏捷快速迭代都是用這個軟體做的。
如何在敏捷開發中做需求分析
3樓：猴家奈
【敏捷專案沒有需求分析嗎?】 在很多人的印象中，敏捷軟體開發是種類似黑客行為的過程，是程式設計師最愛的勾當。不寫文件，不作需求分析，沒有專案經理，做什麼東西完全是程式設計師自己的行為。
所以他們認為這樣的過程無法滿足真正大型專案和複雜專案的需要，因此在經過考慮後，放棄了敏捷方法。 專案經理圈子真的是這樣嗎?敏捷過程到底是如何做需求分析?
使用者故事和用例有什麼區別?敏捷過程如何去管理需求的?這些是一些想要實踐敏捷的人一直在困惑的事情。
我們常常看到書中講，程式設計師拿到一個使用者故事後，怎麼計劃，怎麼分解，怎麼寫單元測試，怎麼小步前進，怎麼持續整合。這是典型的程式設計師視角。事實上，敏捷方法分為三部分，敏捷專案管理，敏捷需求分析，敏捷軟體開發。
上述書中提到的完全是敏捷開發中的實踐，很多人瞭解到的敏捷，只是敏捷的三分之一。 【敏捷專案中誰來做需求分析?】 在敏捷的團隊中，作一個敏捷程式設計師確實是非常舒服的事情。
從程式設計師的角度來看，只需要選擇一張他感興趣的故事卡片，瞭解清楚該卡片的需求，開始從功能測試寫**，等通過了所有測試就完工。基本上不需要考慮太多的事情，非常輕鬆愉快。但程式設計師向誰去問清楚需求?
故事卡片是怎樣寫出來的呢?讓我們來關注開發前發生的事情。 瞭解敏捷過程的人都知道，kent beck在xp過程中提到了現場客戶，如果一個敏捷團隊能夠有現場客戶，這當然是最棒的事情。
但多數情況下，客戶都是很忙碌的，很難全力投入到軟體開發過程中。這時候，我們就需要商務分析師這個角色，來充當客戶的角色。 我在公司的團隊中曾擔任的就是商務分析師這個角色。
商務分析師最重要的職責就是與客戶交談，瞭解和分析需求，將其製作成使用者故事並將需求轉述給程式設計師。同時，商務分析師也要代替客戶負責功能驗收測試。 【敏捷專案中如何進行需求分析?
】 敏捷思想的核心是人與交流。需求問題實際上是一個交流問題。商務分析師要和客戶交流，搞清楚客戶到底需要什麼，到底為什麼需要這些東西。
商業價值是商務分析師關注的最終目標。有了目標的指向，就可以不迷失方向。和客戶進行交流，最終目的就是挖掘出客戶的商業目標。
可能大家會經常有這樣的經驗，客戶說，我要這個功能，我想要怎麼怎麼樣。這時候要特別注意，他說的這些東西並不是真正的需求。商務分析師需要詳細的問客戶為什麼，挖掘出他真正的目標。
在這個目標下，商務分析師開始進行需求的分析：我們到底是否真的需要這個需求?有沒有更好的解決方案?
有沒有簡單並且低廉的方式?換一種形式是不是也能達到這樣的需求?這個需求有多少地方涉及到以前的軟體變更?
搞清楚這些事情後，就可以寫出使用者故事。使用者故事的書寫遵循一定的原則，一般包括三部分："作為(系統的一個涉眾)，我想要(做一件事)，從而(達到一個商業價值)"。
在書寫的時候格式比較隨意，可以在故事卡背面寫上註釋或疑問，甚至畫上介面原形圖。 舉一個最常見的使用者故事例子，「作為一個普通使用者，我希望能夠用使用者名稱和密碼登入，以便我能享受到個性化的服務」。其中，使用者是系統涉眾，登入是他想要做的事情，而他的目標是獲得個性化的服務。
從這個例子我們可以想象到，這個頁面可能存在兩個文字框，用於輸入使用者名稱和密碼，有一個按鈕來登入，並且不登入就不能看到個人資料，另外，如果使用者輸入錯誤需要提示「登入失敗請重試」。這就是可見性，也可以稱為可測試性。我們可以根據這樣的可見性寫出功能測試，從而驅動這個使用者故事的開發，這被稱為 acceptance driven development。
使用者故事的作用有兩個，一個是作為進度跟蹤的依據，一個是作為與人交談的備忘錄。使用者故事卡片並不是很精確的需求，因此不需要把事情描述的非常清楚。將需求的詳細分析推遲到實現前夕來完成，這是敏捷需求分析的精華所在。
任何提前做好的東西都會導致浪費，敏捷過程提倡足夠就好，避免浪費。 不少人對使用者故事和用例的區別感到疑惑。使用者故事的作用是備忘功能，而不是文件。
而用例需要詳細的描述其操作步驟，以及每個異常路徑，因而起到了文件的作用。使用者故事是可見的商業價值，而不是功能描述。每個使用者故事的粒度和工作量都相差不多，這和用例有很大的區別。
使用者故事是小粒度的，可測試的，可見的，並且是有價值的。 【敏捷專案需求分析案例】 公司有個專案組作的是一個網遊物品交易平臺。該平臺是典型的網際網路專案，在開工的時候客戶對功能需求還不明確，但需要快速推出搶佔市場，正是最適合敏捷過程的專案。
在專案伊始，商務分析師和客戶做了深入的談話，瞭解他的商業構想，他的盈利模式，搞清楚巨集觀的結構，然後思考並整理獲得的結果，花1-2天時間將客戶需求大略整理為幾十個使用者故事。這些使用者故事並不完善，不足以做好整個系統。但對於我們開始專案的前一陣，已經足夠了。
我們可以從這裡開始專案。敏捷方法希望快速交付可用的軟體。實現軟體的快速交付是通過迭代來完成。
在迭代開始前，由一組有經驗的開發人員大致評估一下使用者故事，標記出不同的難度和風險，並提出問題供商務分析師來獲得更詳細的資訊，商務分析師會和相關涉眾去討論。然後商務分析師將推薦優先順序最高的一組使用者故事給客戶來挑選，客戶可以選擇這些使用者故事，或者指出從他的視角看到的優先順序更高的使用者故事。這些將成為下一個迭代的內容。
專案經理圈子客戶看到每個迭代交付的可執行的軟體後或者得到使用者反饋後，常常會有新的想法冒出來。有些想法是好的，有些想法就屬於看到別家**有這個功能，不假思索的提出的功能。這些不同的需求都需要經過認真的分析，找出哪些是值得我們立即考慮的，哪些是不用急迫的去實現的。
有一次和客戶談話時，他說到希望增加拍賣功能。那麼，我們為什麼需要拍賣呢?客戶說希望讓使用者拍賣物品以獲得最**格。
經過考慮，我們發現網遊物品的實時性和唯一性決定了系統不適合使用拍賣機制。拍賣的時效性無法滿足實時交易的要求，因此，使用者最終放棄了這個特性。 另一次，客服人員提出增加一個查詢使用者交易的功能，而此時我們有其他更加重要的功能需要先去考慮，查詢使用者交易功能可以由技術人員臨時通過資料庫直接代為查詢，因為專案運營初期交易不是很多，暫時還不需要專門的後臺功能來支援客服的工作。
所以把這個需求卡片一直貼在牆壁上，始終沒有排到最高的優先順序。 客戶一開始也不是很能夠接受敏捷需求中強調商業價值和優先順序的做法。但經過幾個月的磨合，客戶也逐漸適應了許多敏捷思想，甚至我在和客戶討論時，偶然提起了後期的某種可能的情況，他們還能夠幫我糾正應當考慮目前的情況，為近期的情況作計劃。
使用者故事的跟蹤和管理是由專案經理來進行。每個迭代跟蹤卡片的進展，是否已經開始實現?是否已經完成**開發?
是否已經開始功能測試?不同的卡片在迭代前都會評估為不同的大小。我們一般分為大中小**。
等實踐過幾個迭代後，團隊的開發速度基本保持恆定，我們就可以很容易的知道每個迭代能做多少個使用者故事，這樣就可以安排下一迭代的開發。 每個迭代內分析好恰好足夠下一個迭代開發的需求，就是商務分析師每個迭代的主要工作內容。商務分析師的需求分析工作在上一個迭代完成，包括需求的瞭解，分析，評估和排列優先順序。
在每個迭代開始的時候，由商務分析師主持召開迭代計劃會議，在會議上向所有的程式設計師解釋這個迭代要完成的使用者故事，然後由程式設計師自由提問，知道他們能夠獲得足夠開始實現該功能的資訊。 在程式設計師完成一個使用者故事後，商務分析師還要來代表客戶做功能驗收測試，檢視是否完成了預計的功能，是否有程式設計師還沒有想到的異常情況。如果存在問題需要退回給程式設計師繼續完成。
這在一定程度上保證了系統完成的需求不偏離客戶的要求。當然，更多的測試還需要qa來完成。 我們的實踐充分表明了，敏捷過程並不是沒有需求分析，而是把需求分析過程分散到整個開發的過程中，讓開發和需求分析並行進行。
這就是公司敏捷方法實施成功的祕訣之一。而商務分析師在這個過程中，起到了紐帶和橋樑的作用，是一個團隊不可缺少的角色 。
如何做需求分析
一 我們應當如何做需求分析 需求分析不是一蹴而就的，它應當貫穿整個開發週期，不斷的分析確認的過程。這就是敏捷開發倡導的需求反饋。敏捷開發認為，需求分析階段不可能解決所有的需求問題，因此在設計 開發 測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時獲得反饋。只有這樣才能及時糾...
怎樣做招聘需求分析如何做招聘需求分析
首先了解企業經營目標，進行分配人員的招聘，然後讓各部門做月度或者年度類的招聘需求，每月度之前再確認，最主要的是你們要有明確的目標，還有可根據去年的招聘情況和經營目標做一個對比，成比例的一個增長，然後也根據去年的離職率哪個月份比較多，哪些時間好招聘去做好一個招聘計劃等等。1 進行人力資源盤點，瞭解企業...
現代IT專案中的需求管理如何做
專案的需求來管理是個很復源雜的事情,上到公司bai老總,下到普du通員工,內部要考慮研發zhi 生產dao 實施 銷售各個環節,外部要考慮客戶的各部分業務和部門,甚至客戶的客戶。所以在這裡沒法完整的回答您,因為要考慮的問題太多。在這裡給您一點建議供您參考把。建議您綜合pmi的專案管理 需求管理,以及...