11、給分析人員講解您的業務
分析人員要依靠客戶講解業務概念及術語，但客戶不能指望分析人員會成為該領域的專家，而只能讓他們明白您的問題和目標；不要期望分析人員能把握客戶業務的細微潛在之處，他們可能不知道那些對於客戶來說理所當然的「常識」。
12、抽出時間清楚地說明並完善需求
客戶很忙，但無論如何客戶有必要抽出時間參與「頭腦高峰會議」的討論，接受採訪或其他獲取需求的活動。有些分析人員可能先明白了您的觀點，而過後發現還需要您的講解，這時請耐心對待一些需求和需求的精化工作過程中的反覆，因為它是人們交流中很自然的現象，何況這對軟體產品的成功極為重要。
13、準確而詳細地說明需求
編寫乙份清晰、準確的需求文件是很困難的。由於處理細節問題不但煩人而且耗時，因此很容易留下模糊不清的需求。但是在開發過程中，必須解決這種模糊性和不準確性，而客戶恰恰是為解決這些問題作出決定的最佳人選，否則，就只好靠開發人員去正確猜測了。
在需求分析中暫時加上「待定」標誌是個方法。用該標誌可指明哪些是需要進一步討論、分析或增加資訊的地方，有時也可能因為某個特殊需求難以解決或沒有人願意處理它而標註上「待定」。客戶要盡量將每項需求的內容都闡述清楚，以便分析人員能準確地將它們寫進「軟體需求報告」中去。如果客戶一時不能準確表達，通常就要求用原型技術，通過原型開發，客戶可以同開發人員一起反覆修改，不斷完善需求定義。
14、及時作出決定
分析人員會要求客戶作出一些選擇和決定，這些決定包括來自多個使用者提出的處理方法或在質量特性衝突和資訊準確度中選擇折衷方案等。有權作出決定的客戶必須積極地對待這一切，盡快做處理，做決定，因為開發人員通常只有等客戶做出決定才能行動，而這種等待會延誤專案的進展。
15、尊重開發人員的需求可行性及成本評估
所有的軟體功能都有其成本。客戶所希望的某些產品特性可能在技術上行不通，或者實現它要付出極高的代價，而某些需求試圖達到在操作環境中不可能達到的效能，或試圖得到一些根本得不到的資料。開發人員會對此作出負面的評價，客戶應該尊重他們的意見。
16、劃分需求的優先順序
絕大多數專案沒有足夠的時間或資源實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，是需求開發的主要部分，這只能由客戶負責設定需求優先順序，因為開發者不可能按照客戶的觀點決定需求優先順序；開發人員將為您確定優先順序提供有關每個需求的花費和風險的資訊。
在時間和資源限制下，關於所需特性能否完成或完成多少應尊重開發人員的意見。儘管沒有人願意看到自己所希望的需求在專案中未被實現，但畢竟是要面對現實，業務決策有時不得不依據優先順序來縮小專案範圍或延長工期，或增加資源，或在質量上尋找折衷。
17、評審需求文件和原型
客戶評審需求文件，是給分析人員帶來反饋資訊的乙個機會。如果客戶認為編寫的「需求分析報告」不夠準確，就有必要盡早告知分析人員並為改進提供建議。
更好的辦法是先為產品開發乙個原型。這樣客戶就能提供更有價值的反饋資訊給開發人員，使他們更好地理解您的需求；原型並非是乙個實際應用產品，但開發人員能將其轉化、擴充成功能齊全的系統。
18、需求變更要立即聯絡
不斷的需求變更，會給在預定計畫內完成的質量產品帶來嚴重的不利影響。變更是不可避免的，但在開發周期中，變更越在晚期出現，其影響越大；變更不僅會導致代價極高的返工，而且工期將被延誤，特別是在大體結構已完成後又需要增加新特性時。所以，一旦客戶發現需要變更需求時，請立即通知分析人員。
19、遵照開發小組處理需求變更的過程
為將變更帶來的負面影響減少到最低限度，所有參與者必須遵照專案變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最後做出合適的決策，以確定應將哪些變更引入專案中。
20、尊重開發人員採用的需求分析過程
軟體開發中最具挑戰性的莫過於收集需求並確定其正確性，分析人員採用的方法有其合理性。也許客戶認為收集需求的過程不太划算，但請相信花在需求開發上的時間是非常有價值的；如果您理解並支援分析人員為收集、編寫需求文件和確保其質量所採用的技術，那麼整個過程將會更為順利。
「需求確認」意味著什麼
在「需求分析報告」上簽字確認，通常被認為是客戶同意需求分析的標誌行為，然而實際操作中，客戶往往把「簽字」看作是毫無意義的事情。「他們要我在需求文件的最後一行下面簽名，於是我就籤了，否則這些開發人員不開始編碼。」
這種態度將帶來麻煩，譬如客戶想更改需求或對產品不滿時就會說：「不錯，我是在需求分析報告上籤了字，但我並沒有時間去讀完所有的內容，我是相信你們的，是你們非讓我簽字的。」
同樣問題也會發生在僅把「簽字確認」看作是完成任務的分析人員身上，一旦有需求變更出現，他便指著「需求分析報告」說：「您已經在需求上簽字了，所以這些就是我們所開發的，如果您想要別的什麼，您應早些告訴我們。」
這兩種態度都是不對的。因為不可能在專案的早期就了解所有的需求，而且毫無疑問地需求將會出現變更，在「需求分析報告」上簽字確認是終止需求分析過程的正確方法，所以我們必須明白簽字意味著什麼。
對「需求分析報告」的簽名是建立在乙個需求協議的基線上，因此我們對簽名應該這樣理解：「我同意這份需求文件表述了我們對專案軟體需求的了解，進一步的變更可在此基線上通過專案定義的變更過程來進行。我知道變更可能會使我們重新協商成本、資源和專案階段任務等事宜。」對需求分析達成一定的共識會使雙方易於忍受將來的摩擦，這些摩擦**於專案的改進和需求的誤差或市場和業務的新要求等。
需求確認將迷霧撥散，顯現需求的真面目，給初步的需求開發工作畫上了雙方都明確的句號，並有助於形成乙個持續良好的客戶與開發人員的關係，為專案的成功奠定了堅實的基礎。
需求分析的20條法則
需求分析的20條法則 節摘自軟體工程專家網 客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後的磨擦 如一方要求而另一方不願意或不能夠滿足要求 1 分析人員要使用符合客戶語言習慣的表達 需求...
需求分析的20條法則
客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後的磨擦 如一方要求而另一方不願意或不能夠滿足要求 1 分析人員要使用符合客戶語言習慣的表達 需求討論集中於業務需求和任務，因此要使用術語。客...
需求分析的20條法則
1 分析人員要使用符合客戶語言習慣的表達 2 分析人員要了解客戶的業務及目標 3 分析人員必須編寫軟體需求報告 4 要求得到需求工作結果的解釋說明 5 開發人員要尊重客戶的意見 6 開發人員要對需求及產品實施提出建議和解決方案 7 描述產品使用特性 8 允許重用已有的軟體元件 9 要求對變更的代價提...