❶ 如何做好跨產品線需求管理
眾所周知，產品的從0到1是最難的，也是最考驗產品經理個人能力的階段，但是一旦產品進入了平台期，就會催生N多產品。比如網路圍繞搜索引擎構建的產品服務多達上百個；小米以手機為起點在短短數年內發布了超過200款產品；蘋果公司在鼎盛時期旗下產品數量超過1000個。管理如此多的產品絕對是一個挑戰，我們稱這樣的產品管理者為產品VP（高級副總裁）或CPO（首席產品官）。為了便於管理我們會根據其相關性、屬性、業務模塊等特點劃分為若干產品線，由具體的產品負責人去管理，這樣的管理者我們稱之為產品總監。在產品總監所帶領的產品部門治下會有不同的產品經理去負責所對應的具體產品。由此可見，在需求管理上涉及多產品，多產品線與我們通常處理需求的方式有很大的不同。這要求產品經理不僅在專業上有實踐，還要在綜合管理素質上有沉澱。
在第1章我們已經對產品、產品線、產品組合等產品概念有了一定的認識。從概念定義上我們不難看出產品、產品線和產品組合是在面臨多用戶、多場景、多類型、多需求的情況下，為便於管理而進行的需求解決方案組合。因此，在復雜的產品體系下進行統一需求管理，首先要劃清界限，在需求提出時就應該明確該需求走那條路徑，不同路徑對需求的處理和應對機制不同。在本書的框架下，多產品線需求管理路徑如圖7-4所示，僅供參考。
大型企業都已經建立了標准、規范的需求管理流程，針對短期需求，可以通過瀑布迭代即時發現，即時開發，即時驗證，即時發布；針對長期需求，可以列入產品版本計劃迭代上線；跨產品的需求需要產品線負責人進行整體的規劃，制定產品路線圖，進而按計劃實施交付；跨產品線需求則需要根據需求的大小、價值度、緊急度等因素進行區分，一般規模小、價值低、非緊急的需求可以通過協調跨產品線工作解決，規模大、價值高、緊急的需求要走產品組合投資決策立項流程。以上路徑構成了需求管理體系，基本可以承接所有需求。
伴隨著互聯網的高速發展，市場競爭日趨激烈，對需求的響應速度要求越來越高，同時系統也變得越來越復雜，效率和成本問題日益突出。由此，企業在應對市場客戶需求時，逐步的演化出了業務中台、產品中台、技術中台的管理概念，均在於提升前台需求解決效率、降低成本、提升綜合經營效益。另外，工欲善其事，必先利其器。在大公司，還會有諸多現成的工具輔助；在創業公司需要自己尋覓。好在市場上各種工具繁多，任你挑選，比如禪道、Tower、Worktile等。
❷ 如何把控需求的重要性和緊迫性
需求管理源於業務需要，始於需求挖掘，繼而需求分析，需求定義，需求驗證。周而復始。
一，業務需要說明需求產生的原因，可能是高層制定的目標，中層對工作流程的調整，基層碰到無法解決的問題，用戶需要，外部環境變化，競爭對手策略變化或者政府政策調整等。需求人員在明確業務需要時，首先明確干係人，其次獲取干係人要求/需求。可以採用的方法包括：行業基準（競品），業務規則分析（產品分析），頭腦風暴，焦點小組，功能分解，根源分析等。
二，需求挖掘階段的目標是找出干係人的真實需求。單方面的口頭描述或者規范章程都可能與實際需求相差甚遠，因此需要需求人員收集各方面需要，交叉驗證，合理推導，發掘出用戶的實際需求。工作步驟：確認干係人，收集實際情況，整合多方面信息，確認實際需要。方法包括：訪談，觀察，問卷，焦點小組，頭腦風暴，可用性測試，競品分析，數據分析，文檔分析，咨詢專家等。
三，需求分析階段則是對已經收集的真實需求進行規整，包括兩部分內容，組織整理需求和對需求排優先順序。組織整理需求採用相同粒度描述需求，並描述需求間關系。主要方法包括：功能分解，業務規則分析，數據模型，流程模型，范圍模型，用戶經歷，場景和用例，組織模型。需求優先順序劃分通過定義需求的優先順序，為計劃安排提供有價值的參考。可以參考的定義維度包括：時間，預算，業務價值，業務和技術風險，實施難度，成功可能性，規范和政策，與其他需求的關系，與干係人的協議，緊急程度等。可採用3/4級優先順序定義，或者MoSCoW模型定義，其中M=必須S=應該C=能夠W=將要。
四，需求定義主要工作為根據前期整理的相關文檔整理需求說明。輸出包括：業務需要，需求陳述，組織整理後的需求以及需求優先順序。需求說明主要包括：業務需要，業務需求和系統需求。·五，需求驗證包括需求檢驗和需求確認，即需求過程中的檢查和需求完成的測試。需求跟蹤矩陣是個好東西，可以在需求分析階段產出。
❸ 現代IT項目中的需求管理如何做
在項目管理中，需求是為了成功完成項目而必須完成的一組任務或條件。它包括產品功能、行為、服務甚至是流程。這些需求的目的是確保資源和公司的長期目標在項目結束時保持一致。
一般情況下，需求可以分為以下幾類：
業務需求：指業務的總體需求，旨在實現項目。屬於這一類的需求是更基本的、與組織的長期目標相一致的長期需求。
解決方案需求：更多以產品為中心，並深入研究。它們可以是功能性的，也可以是非功能性的，確保產品的最終結果既滿足產品需要做的事，也滿足產品應該做的事。
利害關系人需求：描述了關鍵人員，他們在里程碑上簽字，完成工作，最終確定可交付成果等等。有時他們可以是客戶、團隊成員、業務夥伴或關鍵領導。它需要一個堅韌的項目經理來確保所有利害關系人的需求在整個項目中得到很好的平衡。這對於良好的利害關系人管理必不可少。
你也可以定義適合項目的需求類別。
8Manage PM提供了一個用於項目需求管理的平台。系統自動偵查需求的變化，並把需求變化與項目的各個階段關聯，以此提醒用戶，讓用戶更好地了解需求變化所帶來的影響。系統也能自動追蹤需求依賴及間接變化，讓用戶盡早了解其潛在影響。
該企業級工具擁有在整個項目過程中准確捕獲和傳達需求、目標、進度和相互依存關系的能力。團隊可以使用該系統來縮短周期時間，提高質量，減少返工並最大程度地減少證明合規性的工作。
無效的需求管理流程，或更常見的是不採用任何需求流程，已被確定為項目失敗的主要原因。從項目生命周期開始就實施的需求流程的投資最終會得到回報。
❹ 如何分析和管理產品需求
有效地管理產品需求
產品經理首先需從用戶那裡收集反饋信息，分析用戶需求，再根據用戶需求進行產品功能規劃，這些待實現的產品功能對於產品來說就是產品需求。
將用戶需求轉化為產品需求
用戶需求收集的來源與方法有很多，包括競品分析、訪談、問卷調查、焦點小組、可行性測試、現場觀察、數據分析、任務和場景分析等，在不同階段應用的收集方法是不一樣的，需求收集是持續的過程，貫穿產品發展的生命周期。
之所以將用戶需求轉換為產品需求再進行管理，是因為多數時候憑借經驗根據用戶需求制定初步的產品解決方案並不需要耗費多大的精力，卻可以讓我們更加深入地理解用戶需求以及產品需求和產品之間的關系，同時也方便我們准確的評估滿足用戶需求的產品新方案的技術可行性和優先順序。
記錄產品需求的屬性和信息
選擇性的記錄產品需求的一些重要屬性，將有助於我們更好的管理產品需求，如產品需求所屬模塊、產品需求的需求類型、需求方代表等。
#產品需求所屬模塊
一個產品往往是一個復雜的功能系統，為了產品更容易分析和開發，產品會被分解為幾個功能模塊，每個功能模塊負責完成產品一部分的系統功能。需求所屬模塊就是產品需求所隸屬的模塊，用來直觀地說明產品需求在產品結構中的具體位置。比如微博數據中心分為粉絲分析、內容分析、互動分析、行業趨勢分析四個模塊，而頁面訪問分析是隸屬互動分析這個模塊。
#需求類型
對產品需求進行必要的分類，不僅可以幫助我們更好的管理需求，而且還可以更好的分析需求，對每個需求的價值大小做出更准確的判斷。同樣的產品需求可以按照不同的維度進行分類，具體採用哪種維度可以根據實際需要來決定。比如微博數據中心的後台管理支持系統就要針對代理商需求與零售商需求進行區分。
#需求方代表
需求方代表就是最初提出該用戶需求的人員，在產品功能規劃與版本升級時，如果需求方案不得不調整，那麼產品經理可以迅速找到相應的需求方代表進行溝通。比如運營人員提出發票錄入系統的相關問題，在產品實施過程中如果需要進行調整可以快速找到其進行溝通，確保新的產品需求能夠正確無誤地反映用戶的真實意願。
確定產品需求優先順序
❺ 如何做好產品需求管理
需求不總是顯而易見的,而且它可來自各個方面。需求並不總是容易用文字明白無誤地表達。存在不同種類的需求,其詳細程度各不相同。如果不加以控制,需求的數量將難以管理。需求相互之間以及與流程的其他可交付工件之間以多種方式相關聯。需求有唯一的特徵或特徵值。例如，它們既非同等重要，處理的難度也不同。需求涉及眾多相關利益責任方，意味著需求要由跨職能的各組人員來管理。需求可能發生變更。需求對時間敏感。當這些問題同時出現，如果沒有需求管理或處理技能不足以及缺乏易用工具等情況時，業務就會進入混亂，甚至是面臨癱瘓與失敗。為此我們不得不重視和加強需求管理。
需求管理是完整管理模式中的一環，同其他特性諸如完整性、一致性等不可分割，彼此相關而成一體。一套需求管理應當是已知產品需求的完整體現，每部分解決方案都是對總體需求一定比例的滿足（甚至是充分滿足），僅僅解決部分需求是沒有意義的。對關鍵需求的疏忽很可能是災難性的，試想一架飛機的安全設計不過關將會帶來什麼樣的後果。不同的需求組合起來，構成了一個需求池，然後通過管道（流程規范）進行流轉，將產品價值交付客戶。可以說，需求管理指明了產品開發所要做和必須做的每一件事，指明了所有設計應該提供的功能和必然受到的制約。需求管理的過程，從需求獲取開始貫於整個項目生命周期，力圖實現最終產品同需求的最佳結合，如圖7-3所示。通過對需求管理在項目進程中實施的不同任務進行分析，我們可以看出需求管理所起的作用。
圖7-3 需求管理流程（示例）
建立需求管理流程的首要任務在於使產品團隊對於需求管理都有一個明確的認識，並明確每一個人在項目中所起的作用，進而對整個項目有一個整體把握。因此，需求管理需要解決的第一位也是最基本的任務就是建立需求流程和規范，並使所有相關人員達成共識。
為了建立一個真正滿足工作需要的需求管理系統,產品團隊首先必須確定系統要解決的問題，即需求來源。然後,團隊必須將採集到的所有需求進行匯總，歸入需求池中進行統一管理。繼而對需求的有效性、真偽、分類、時效、優先順序進行分析、再確定需求是否要接納進行開發，並做好狀態標記。接著對已確定的高優先順序需求指定需求負責人對其進行詳細分析，並提交評審，通過後列入版本計劃。最後由產品開發團隊負責需求實現，交由測試人員嚴重通過後對外發布。如果客戶或內部需求提出人員對交付的結果不滿意，可以進入需求管理循環處理改進，直到客戶滿意或解決問題為止。
需求管理是一個動態的過程，離開了能動的、變化的系統進程而空談需求管理，無異於紙上談兵。需求管理恰如裁縫的量體裁衣，它直接關繫到最終產品的成型。僅從字面出發，如果一個產品滿足了客戶需求，那它無疑就是成功的。
❻ 產品經理如何對產品質量進行有效把控
作為產品人員，對產品的管理主要體現在兩個方面，其一是對產品需求的管理，其二是對產品質量進行有效的把控。只有對這兩個方面都管理好了之後，才能比較好地讓產品符合需求目標，並循序漸進地完成落地。
本文主要討論產品經理如何對產品質量進行有效把控。
一個產品，想要保證質量是沒有問題的，可以對下面幾個方面進行測試驗證：
1. 功能、流程走通，介面符合要求
2. 交互界面，UI設計符合體驗預期
3. 性能優，能承受一定用戶量同時使用壓力
4. 符合其他安全性，兼容性要求
一個產品的完整的測試過程，從需求評審之後那一刻開始就進行了。我們可把測試分為三類測試。第一類是開發人員自己的測試，第二類是第三方人員測試，第三類是測試人員的測試。如下所示：
在開發人員開發之前，產品人員，可對開發的開發完成成果提出要求，如要求屬於開發職責范圍內的開發內容，需要自測，並保證流程完整，邏輯正確，同時界面交互需要保證沒有明顯錯誤。這樣做的好處是，能有一個比較清晰的界限讓開發也知道做到怎樣的程度才算是完成開發任務，才能正式地交付給測試。
在開發開發過程中，就會一邊開發一邊自測。而開發完成了之後，提交測試之前，建議多一個開發結果的檢查環節，讓開發能從用戶的使用角度，自己演示自己的開發結果給到團隊的核心成員。這樣，一方面讓開發能為自己做出來的東西負責，另一個方面，也可以在投入測試資源之前能對開發的結果進行檢查，避免需要測試的內容卻是還沒有開發的內容，這樣測試的效率就會低很多。
在測試這個環節，產品人員，運營人員，UI人員，交互人員等，以及其他的非開發和測試，但有參與到項目中的人，都可以叫做第三方人員。第三方人員可以在開發過程，開發完成之後，參與到測試當中。但是各類第三方人員參與測試的測試重點是不同的。
產品人員需要仔細檢查關鍵流程，功能實現情況，以及實現效果有沒有符合用戶的使用體驗。交互設計人員，需要檢查交互細節。UI人員，需要檢查界面，元素，以及UI細節。
在產品進行需求評審之後，產品人員可對測試人員的測試提出相關的要求。測試人員可根據產品的需求說明書，或產品的原型進行測試用例的編寫。編寫了之後的用例，是否符合產品的輸出要求，需要進行詳細的測試用例評審，評審完成之後，才能進入測試。
在測試過程中，則可對產品的功能，介面、兼容性進行測試，另外，可進行性能相關的測試，如壓力測試，安全性測試等。最終出具測試結果報告，以及BUG清單，給到相關人員，向上匯報，向下提供給到開發人員進行相應的修改調整。
通過以上的分析，可以看到，產品人員需要做下面幾件事情：
1. 需要為產品的測試提供詳細的產品需求說明/產品原型，為測試提供產品測試的依據。
2. 需要對測試用例進行詳細評審，為測試確定目標。
3. 需要自行進行產品的功能，流程，交互，UI等相關的測試
4. 需要在開發人員開發之前，提供開發完成的標准（如功能，流程走通，界面基本美觀等）
5. 需要在開發開發完成只有，聽取開發對開發結果的講解，並確定是否可以進入到測試流程。
❼ 需求管理的手段有哪些
本文梳理了什麼是做需求分析與需求管理，以及為什麼要做與如何去做。
01 概述
本文是梳理需求分析與需求管理方法-產品經理工作職責&工作核心技能之一，筆者寫本文的目的一是把自己的知識體系做個輸出，包含來自己的經驗總結和最近學習到的知識總結，其二順便分享。知識方法無定論，任何內容先看思路，實戰為主。
在分析一個問題時，可以用一個通用的框架方法論，WWH法：是什麼？為什麼？怎麼做？這樣可以把思路理清晰。因此引出了本文的主要內容：什麼是需求？為什麼要做需求分析？什麼時候做需求分析？怎麼做需求分析？
說明：時間有限，本文的案例不代表實戰解決方法案例，更為了快速說明和應用方法而舉例。
02 需求定義
1. 什麼是需求？
需是是用戶在某種場景下的未被滿足的期望。
為什麼要明確需求的定義，需求很容易被誤解，這里我們要區分下用戶需求和產品需求。
我們的產品在未被定義之前，我們研究的需求是用戶需求，我們通常也會叫作問題（沒有明確的解決方案），當我們定義產品時，我們就要把用戶需求轉化為產品需求，提供具體的可落地的解決發難，才能實現產品。
我要吃飯睡覺打豆豆，這不是需求，這種需求對於產品沒有任何價值。
看定義，用戶需求是用戶基於某種場景下的未被滿足的期望，在這里提煉出需求的基本結構：用戶+場景+期望。強調：需求不是獨立存在的，是依附於用戶+場景一起存在的。
用戶需求案例： 小明（用戶），每天早上起床後就要趕著去上班，沒有也不想在家吃早餐，但是到了公司就要工作，所以常常沒有早餐吃，又餓又不健康（場景），小明又想多睡會兒又想在上班前吃上早餐（期望）
2. 什麼是需求分析？
需求分析，就是挖掘和提煉用戶需求，解決用戶痛點問題，即找到用戶需求，並把用戶需求轉為產品需求（解決方案）的過程。
這里強調兩點：
找到用戶需求
解決用戶問題
案例： 還是小明吃早餐的案例，目前小明希望在上班前能吃上早餐這個是用戶需求，只找到用戶需求，沒有解決方案，等於0，我們還要幫小明解決問題。如，提供早餐外賣，小明可以提前在手機上預定早餐外賣，一起床就有早餐可以吃。這是一個較完整的產品需求。
03 為什麼要做需求分析
產品首先要滿足的就是用戶需求，為用戶產生價值，才能創造商業價值。滿足用戶需求是產生商業價值的本源。
04 在什麼階段做需求分析
需求分析貫穿在產品整個生命周期。
1. 產品概念期
這個階段做需求分析，更強調需求調研，目的是定位目標用戶群，做產品定位，市場研究並確認細分產品市場。提煉產品核心功能，解決目標用戶群痛點問題。 交付物：BRD需求文檔。（或類似的相關的文檔，如需求調研報告、市場調研報告等）
2. 產品設計開發期
這個階段的需求分析，目的是要設計一個可落地的解決用戶痛點，滿足用戶需求的產品。設計一個目標用戶可用好用的產品。深層次的挖掘和分析用戶，描述需求，解決問題。實現用戶如何通過一步步的使用產品滿足其需求。該階段交付物：產品原型+PRD操作文檔。
3. 上線後-成長期
上線後的需求分析，目的是驗證真實產品滿足真實用戶需求的結果，收集用戶需求，優化產品。
4. 成熟運營期
本階段需求分析，目的在為產品提供更好的運營方案，制定競爭策略。讓產品持續更好的更多的為企業創造商業價值。
5. 產品衰退期
當產品進入衰退期時，需求分析重在研究市場發展趨勢，以幫助決策是調整發展戰略。
05 需求分析方法
需求分析可以分為三大步： 明確問題–拆解需求–提供解決方案。
1. 明確問題
明確問題之前，我們首先要從各方搜集需求，然後經過分析，提出真正的需求。
需求獲取渠道
以下是我們常用的一手需求獲取渠道：
收集到的一手需求還不是真正的需求，要先進行一個清洗過程，把一些無用的無根據的站不住腳的異常的等等都過濾掉。具體過程不做介紹啦。
明確問題（提出要解決的問題）
這里一定要注意，提問題的標准：提出的問題要聚焦，明確、開放。不能泛，模糊。要又用戶、場景、問題。還要明確該需求帶來的價值。需求最終是要交換成價值的。
正確的問題VS錯誤的問題：
明確需求的價值：
2. 拆解問題（需求）
拆解需求指的是把已經明確的問題，從多個維度進行拆解，目的就是為了找到更合適的解決方案。 該方法是某課程老師總結的拆解方法，筆者認為非常好，非常清晰和明確的一個方法，這里直接引用。（該方法也是老師對《六頂思考帽》里的解決問題方法做的靈活應用，同時書也推薦給大家）
拆解問題的5個維度：
積極層面：通常可以拆解出怎麼做對用戶來講可以產生更積極的情感。
否定層面：通常可以拆解，即使不做什麼，依然可以產生好的結果。
轉移層面：轉移指的是不直接單獨解決當前用戶的問題，通過轉移法，用戶轉移、問題轉移等。
拆解：把當前問題刨根問底的拆，挖掘更多的可能性、找到問題本質。
腦洞：這個更多的靠靈感、經驗等進行頭腦風暴，補充其他維度考慮不到的地方。
案例： 問題：某視頻APP，用戶次日留存率低於30%，需要提高次日留存率 拆解過程如下圖：
注意在拆解問題的時候，不要去考慮能不能實現，先去拆解一切想到的問題，最後在分析解決方案的時候再來進一步篩選。
3. 提供解決方案
問題拆解完後，對所有提出的問題列出解決方案，這里注意，一開始思考解決方案的時候也不要去考慮實現的可行性，盡管去提供。等所有的解決方案都列出來之後，再進行方案分析、評估、排序。
06 需求管理
需求管理指的是如何安排已經明確產生的需求，工作中我們通常會遇到四面八方包括產品經理自己給的需求，但是資源和精力無法讓做到有求必應，我們需要去把需求做一個分類和排序，盡可能的去做性價比高的需求開發。 這里我們介紹幾種方法，幫助我們做需求分類和排序。
1. Kano 模型
KANO 模型是東京理工大學教授狩野紀昭（Noriaki Kano）發明的對用戶需求分類和優先排序的有用工具，以分析用戶需求對用戶滿意的影響為基礎，體現了產品性能和用戶滿意之間的非線性關系。
Kano模型把需求分為5類：
基本型需求
該類需求代表的用戶的核心痛點，是產品的必備功能，如果沒有該功能，用戶會極度不滿，甚至不用你的產品。但是如果有了該功能，用戶並不會對你的產品的滿意度增加。如微博的發布微博功能、社交APP的聊天功能、共享單車的開鎖功能等。
期望型需求
這類需求代表的是用戶的癢點，代表的是品質，對用戶來講是最好有的功能。好比我們的生活，我們都期望我的生活是有一定品質的。擁有此功能，用戶滿意度會明顯提升（過的還可以），沒有此功能，用戶滿意度會明顯下降，但是湊合可以用戶（過得下去）。這種需求一定要去努力挖掘和分析，並做好。代表了產品的競爭優勢。如社交軟體的語音聊天視頻功能。
興奮型需求
這類需求所在暗處，用戶自己都想不到的需求。擁有此功能，即便表現的並不完善或完美，用戶滿意度也顯著提升，但即便沒有此功能，用戶也並不會對產品對滿意度降低。如，在微信剛剛推出紅包功能的時候，這是一個非常典型的興奮型需求。
無差異型需求
該功能對用戶來講，是不痛不癢的需求。可用可不用，有或者沒有都不會影響用戶的滿意度。如，我們在設計某個按鈕，是20px，還是22px，是第一個還是第二個位置。無論怎麼做，對用戶並無明顯影響。我們就盡量不要去花精力在這上面，只需要執行任意一種即可。
反向型需求
該類需求提供對應的功能後，用戶會對產品的滿意度降低。該類需求，最好不做。如，前段時間上熱搜的一款監測學生上課是否集中注意力的智能科技「緊箍咒」，得到的是網友幾乎一邊倒的差評和抵制。
Kano模型實施方法：
如何評估需求屬於Kano模型中的哪一類需求，我們可以實施以下方法：
Kano模型問卷調研法 可以直接設計問卷調研，通過定量問卷調研得出需求屬於哪一種：
按照上表的格式，對每一個功能做一個的調研，充分收集用戶的數據並得出結果。
2. 時間管理四象限法
本方法可以快速幫助我們評估需求開發的時間優先順序。從緊急重要程度兩個維度比較合理的幫助產品有條理的安排開發秩序，避免盲目排序。
3. ICE排序法
ICE排序法也是一種比較嚴謹科學的需求排序方法，通過從幾個維度考慮給需求打分，以總分高低去排序。
I（Impact）：影響范圍
C（confidence）：對上線效果的自信程度評估
E（ease）：開發難易程度（工作量+技術難易程度）評估
應用實例：
本文由 @娟姐 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
❽ 如何進行需求管理
會面前做充分的准備
你一定要拿出事先准備的問題列表，利用日事清的管理系統看板的強大功能，針對每一個功能點對員工進行提問，一個都不能放過。對非功能的需求也同樣不能放過，如客戶需要的系統至少連續運行多少小時不出問題，系統在若干數量的訪問者訪問時的響應時間范圍等。
一、 讓客戶打開話匣子
對客戶進行提問，引導客戶說出他們的需求，是非常關鍵的，這裡面的學問也是很大的，問恰當的問題，問能讓客戶打開話匣子的問題，你就勝利了。 這時你會面前的准備工作就顯得尤為重要了，你要針對他們要做的軟體的功能，一部分一部分的問，不能著急，要深入，並細致，
二、 千萬不要浪費客戶的時間
和客戶面談時特別要注意一點，就是千萬不能浪費客戶的時間，讓他覺得非常無聊，這是捕獲需求最大的忌諱
三、 發揮原型的效力
原型對於提高客戶對軟體的認知程度有很好的效果，他能使客戶對軟體有一個直觀的認識，面對原型，他們可以更好地提出他們的想法和意見，尤其對那些對軟體缺乏認識的客戶。
四、 充分利用需求確認會議
需求確認會議通常由全體涉眾（利益相關人）參加，這可是個確認需求的難得的機會，大家能聚在一起，這樣的機會其實很難得，所以一定要珍惜
❾ 軟體需求該如何管理
啟動軟體項目的原因是軟體需求的存在,軟體開發模型有瀑布模型、快速模型和增量模型等,但無論採用哪一種模型,軟體需求分析是軟體開發過程的基礎。在軟體開發統計數據中,軟體項目中40%~60%的問題都是在需求分析階段埋下的隱患。而在以往失敗的軟體項目中,80%的失敗項目是由於需求分析的結果不明確造成的。因此，一個軟體項目成功的關鍵因素之一就是對需求分析的把握程度,而軟體項目的整體風險往往表現出需求不明確、業務流程不合理,所以,需求管理是項目管理的重要一環。
軟體需求是:①用戶為解決某一問題或達到某一目標所需條件或權能;②系統或系統構件為了滿足合同、規約、標准或其他正式實行的文檔所需具有的條件或權能;③一種反映上述①或②所述條件或權能的文檔說明。它包括功能性需求及非功能性需求,非功能性需求對設計和實現提出了限制,例如性能要求、質量標准,或者設計限制。
軟體需求就是指用戶希望軟體能做什麼事情,實現什麼樣的功能,達到什麼樣的性能。因此,軟體項目管理人員要准確地理解用戶所提出的要求,進行細致的需求調查分析,將用戶的非形式化的需求陳述轉化為完整的需求定義,並依據此定義轉化為需求規格說明書。