地分析出系統(tǒng)應該提供哪些功能。首先，研發(fā)團隊一定要注意對涉眾真實需求的收集和理解。更進一步看，在涉眾需求的收集和定義階段，風險主要存在于定義了錯誤的需要解決的問題;相對去后續(xù)階段的設計而言，在定義系統(tǒng)需求階段，系統(tǒng)工程師應該只是抽象地描述解決方案，這個階段的風險存在于不必要地帶入過多地設計約束，影響詳細方案的可能選擇。
    可能有讀者會抱怨或懷疑這個思想是不是太理想了:用戶常常就告訴開發(fā)團隊他關于解決方案的設計和想法，這時候怎么辦?這就更要求我們的需求捕獲人員有清晰的思路，首先，“用戶可能自己也不知道自己需要什么”，這是常常發(fā)生的事情，我們需要適當?shù)靥岢觥盀槭裁础眮硪龑Э蛻?其次，假定客戶知道自己想要的，那么客戶提出關于實現(xiàn)的想法也反映了他的潛在目標，也就成為了我們設計時的約束。
市場和研發(fā)的平衡
    在很多上了一定規(guī)模的公司中，有兩個團隊是一定存在且非常重要的：市場部和研發(fā)部。市場團隊主要和“人”打交道，進行市場的調研和需求的獲取，這處在圖2中沙漏的上半部分。在沙漏的下半部分是工程領域，也就是開發(fā)隊伍工作的領域。對開發(fā)人員來說，他們很少有機會真正地面對客戶，他們工作的基礎就是需求。對一個項目或產品的成功， 這兩個團隊必須緊密合作，扮演好自己的角色。一旦此間的平衡被打破，團隊就會遇到麻煩。很多公司里市場部門“坐大”，為了贏得客戶的定單，或不深入理解客戶的要求，或是直接“指示”研發(fā)部門按照自己對系統(tǒng)實現(xiàn)的理解進行開發(fā)。這都違反了上文中提及的需求捕獲的關鍵原則。當另一方面，我也遇到這樣一些公司，它們是由研發(fā)起家， 整個研發(fā)部門在公司中占有比較多的“話語權”。會有這樣的開發(fā)經(jīng)理或人員，可能是出于追求技術領先或完美的熱情， 在滿足用戶需求的同時，也會增加設計/ 實現(xiàn)其他“多余”的功能點。這些功能點其實是“無源之水”，并沒有實際的市場和用戶需求與之相對應。
    需求將市場部和研發(fā)部緊密地聯(lián)系起來，讓兩者之間的有效連接并維護平衡的角色就是團隊中的需求專家。市場部和直接的用戶，以及相關系統(tǒng)的投資方、監(jiān)管方、維護方等等進行交流，我們不能保證他們能夠提供準確的清晰的需求描述，因為他們只是在提出他們的問題和對結果的期望，而且要求我們的客戶去學習什么是好的需求和如何提需求是不現(xiàn)實的。現(xiàn)實的是團隊中有這么一些人，熟悉領域且受到過需求管理方面的指導和培訓，他們知道應該怎么去收集、分析和總結需求。例如在西門子， 負責捕獲客戶需求的工作主要由市場部人員去做，但并不是直接將這些需求轉給開發(fā)部。有一個需求管理小組，隸屬于研發(fā)中心，主要職責則相當于市場部和開發(fā)部的一個接口。需求工程師對從市場部那里獲取的零散和龐大的需求文檔進行整理和分類，然后提交給開發(fā)部。開發(fā)人員不需要和市場部爭論哪些事情做得到還是做不到，而是由需求工程師來做。(具體參見《探索需求管理的三步曲》——《程序員》2005年9月刊) 這是一個很好的做法，需求工程師可以是一個職位，也可以是一個角色。單獨的職位可能在小的團隊中不太實際，但擁有這個角色的人自己必須很清楚自己的位置：是處在市場和研發(fā)中間，需要維護好平衡，做好接口的工作。
產品線需求 vs 具體項目需求
    研發(fā)團隊的項目性質很大程度上決定了需求管理做到的深度和廣度。有項目經(jīng)理問，我的項目周期常常只有幾個月半年的，還需要做需求管理嗎?誠然，若是一些沒有專注業(yè)務領域的團隊，他們項目的時間短，而且沒有類似的后續(xù)項目，可以不必在需求管理上面投入太多的資源。而另一方面，如果這個項目是一個產品發(fā)展的某一個階段，我們就要重新審視這個問題。就如一個做打印機的日本公司在上海的研發(fā)團隊，他們的項目周期也是半年左右

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html