關鍵字：軟件 需求分析
7：描述產品易使用的特性
你可以要求分析人員在實現功能需求的同時還要注重軟件的易用性。因為這些易用特性或質量屬性能使你更準確、高效地完成任務。例如，客戶有時要求產品要“用戶友好”或“健壯”或“高效率”，但這對于開發人員來說，太主觀了并無實用價值。正確的應是：分析人員通過詢問和調查了解客戶所要的友好、健壯、高效所包含的具體特性。
8：調整需求，允許重用已有的軟件組件
需求通常要有一定的靈活性。分析人員可能發現已有的某個軟件組件與你描述的需求很相符。在這種情況下，分析人員應提供一些修改需求的選擇以便開發人員能夠在新系統開發中重用一些已有的軟件。如果有可重用的機會出現，同時你又能調整你的需求說明，那就能降低成本和節省時間，而不必嚴格按原有的需求說明開發。所以說，如果想在產品中使用一些已有的商業常用組件，而它們并不完全適合你所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。
9：獲得滿足客戶功能和質量要求的系統
每個人都希望項目獲得成功。但這不僅要求你要清晰地告知開發人員關于系統“做什么”所需的所有信息，而且還要求開發人員能通過交流了解清楚取舍與限制。一定要明確說明你的假設和潛在的期望。否則，開發人員開發出的產品很可能無法讓你滿意。
客戶有下列義務：
1：給分析人員講解你的業務
分析人員要依靠你給他們講解的業務概念及術語。但你不能指望分析人員會成為該領域的專家，而只能讓他們真正明白你的問題和目標。不要期望分析人員能把握你們業務的細微與潛在之處，他們很可能并不知道那些對于你和你的同事來說理所當然的“常識”。
2：抽出時間清楚地說明并完善需求
客戶很忙，經常在最忙的時候還得參與需求開發。但無論如何，你有義務抽出時間參與“頭腦風暴”會議的討論，接受采訪或其它獲取需求的活動。有時分析人員可能先以為明白了你的觀點，而過后發現還需要你的講解。這時，請耐心一些對待需求和需求的精化工作過程中的反復，因為它是人們交流中的很自然的現象，何況這對軟件產品的成功極為重要。
3：準確而詳細地說明需求
編寫一份清晰、準確的需求文檔是很困難的。由于處理細節問題不但煩人而且又耗時，故很容易留下模糊不清的需求。但是，在開發過程中，必須得解決這種模糊性和不準確性。而你恰是為解決這些問題作出決定的最佳人選。不然的話，你就只好靠開發人員去正確猜測了。在需求規格說明中暫時加上待定(to be determined, TBD也可采用漢語拼音略寫“DQD：待確定”)的標志是個不錯的辦法。用該標志可指明了哪些需要進一步探討、分析或增加信息的地方。不過，有時也可能因為某個特殊需求難以解決或沒有人愿意處理它而注上TBD標志。盡量將每項需求的內容都闡述清楚，以便分析人員能準確的將其寫進軟件需求規格說明中。如果你一時不能準確表述，那就得允許獲取必要的準確信息這樣一個過程。通常使用所謂的原型技術。通過開發的原型，你可以同開發人員一起反復修改，不斷完善需求定義。
4：及時地作出決定
正如一位建筑師為你修建房屋，分析人員將要求你做出一些選擇和決定。這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息準確度中選擇折衷方案等。有權做出決定的客戶必須積極地對待這一切，盡快做處理、做決定。因為開發人員通常只有等你做出了決定才能行動，而這種等待會延誤項目的進展。
5：尊重開發人員的需求可行性及成本評估
所有的軟件功能都有其成本價格，開發人員最適合預算這些成本(盡管許多開發人員并不擅長評估預測)。你所希望的某些產品特性可能在技術上行不通，或者實現它要付出極為高昂的代價。而某些需求試圖在操作環境中要求不可能達到的性能或試圖得到一些根本得不到的數據，開發人員會對此作出負面的評價意見，你應該尊重他們的意見。有時，你可以重新給出一個在技術上可行、實現上便宜的需求，例如，要求某個行為在“瞬間”發生是不可行的，但換種更具體的時間需求說法(“在50ms以內”,但若沒有準確的技術分析不能輕易下結論)，這就可以實現了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/