6： 劃分需求優先級別
大多數項目沒有足夠的時間或資源來實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發的主要部分。只能由你來負責設定需求優先級，因為開發者并不可能按你的觀點決定需求優先級。開發者將為你確定優先級提供有關每個需求的花費和風險的信息。當你設定優先級時，你幫助開發者確保在適當的時間內用最小的開支取得最好的效果。在時間和資源限制下，關于所需特性能否完成或完成多少應該尊重開發人員的意見。盡管沒有人愿意看到自己所希望的需求在項目中未被實現，但畢竟是要面對這種現實的。業務決策有時不得不依據優先級來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。
7：評審需求文檔和原型
正如我們將在第1 4章討論的，無論是正式的還是非正式的方式，對需求文檔進行評審都會對軟件質量提高有所幫助。讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性。評審也給客戶代表提供一個機會，給需求分析人員帶來反饋信息以改進他們的工作。如果你認為編寫的需求文檔不夠準確，就有義務盡早告訴分析人員并為改進提供建議。通過閱讀需求規格說明，很難想象實際的軟件是什么樣子的。更好的方法是先為產品開發一個原型。這樣你就能提供更有價值的反饋信息給開發人員，幫助他們更好地理解你的需求。必須認識到：原型并非是一個實際產品，但開發人員能將其轉變、擴充成功能齊全的系統。
8：需求出現變更要馬上聯系
不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響。變更是不可避免的，但在開發周期中變更越在晚期出現，其影響越大。變更不僅會導致代價極高的返工，而且工期也會被迫延誤，特別是在大體結構已完成后又需要增加新特性時。所以一旦你發現需要變更需求時，請一定立即通知分析人員。
9：應遵照開發組織處理需求變更的過程
為了將變更帶來的負面影響減少到最低限度，所有的參與者必須遵照項目的變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最后作出合適的決策以確定將某些變更引入項目中。
10：尊重開發人員采用的需求工程過程
軟件開發中最具挑戰性的莫過于收集需求并確定其正確性。分析人員采用的方法有其合理性。也許你認為需求過程不太劃算，但請相信花在需求開發上的時間是“很有價值”的。如果你理解并支持分析人員為收集、編寫需求文檔和確保其質量所采用的技術，那么整個過程將會更為順利。盡管去詢問分析人員為什么他們要收集某些信息，或參與與需求有關的活動。
系統分析人員在開發過程中可能會遇到以下問題，一些很忙的客戶可能不愿意積極參與需求過程，而缺少客戶參與將很可能導致不理想的產品。故一定要確保需求開發中的主要參與者都了解并接受他們的義務。如果遇到分歧，通過協商以達成對各自義務的相互理解，這樣能減少今后的摩擦。
7．需求文檔
需求開發的最終成果是：客戶和開發小組對將要開發的產品達成一致協議。協議綜合了業務需求、用戶需求和軟件功能需求。就像我們早先所看到的，項目視圖和范圍文檔包含了業務需求，而使用實例文檔則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文檔，還要編寫產品的非功能需求文檔，包括質量屬性和外部接口需求。只有以結構化和可讀性方式編寫這些文檔，并由項目的風險承擔者評審通過后，各方面人員才能確信他們所贊同的需求是可靠的。
你可以使用以下三種方法編寫軟件需求規格說明：
用好的結構化和自然語言編寫文本型文檔。
建立圖形化模型，這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系。
編寫形式化規格說明，這可以通過使用數學上精確的形式化邏輯語言來定義需求。
由于形式化規格說明具有很強的嚴密性和精確度，因此，所使用的形式化語言只有極少數軟件開發人員才熟悉，更不用說客戶了。雖然結構化的自然語言具有許多缺點，但在大多數軟件工程中，它仍是編寫需求文檔最現實的方法。包含了功能和非功能需求的基于文本的軟件需求規格說明已經為大多數項目所接受。圖形化分析模型通過提供另一種需求視圖，增強了軟件需求規格說明。
軟件需求規格說明不僅是系統測試和用戶文檔的基礎，也是所有子系列項目規劃、設計和編碼的基礎。它應該盡可能完整地描述系統預期的外部行為和用戶可視化行為。除了設計和實現上的限制，軟件需求規格說明不應該包括設計、構造、測試或工程管理的細節。許多讀者使用軟件需求規格說明來達到不同的目的：
客戶和營銷部門依賴它來了解他們所能提供的產品。
項目經理根據包含在軟件需求規格說明中描述的產品來制定規劃并預測進度安排、工作量和資源。
軟件開發小組依賴它來理解他們將要開發的產品。
測試小組使用軟件需求規格說明中對產品行為的描述制定測試計劃、測試用例和測試過程。
軟件維護和支持人員根據需求規格說明了解產品的某部分是做什么的。
產品發布組在需求規格說明和用戶界面設計的基礎上編寫客戶文檔，如用戶手冊和幫助屏幕等。
培訓人員根據需求規格說明和用戶文檔編寫培訓材料。
軟件需求規格說明作為產品需求的最終成果必須具有綜合性：必須包括所有的需求。開發者和客戶不能作任何假設。如果任何所期望的功能或非功能需求未寫入軟件需求規格說明，那么它將不能作為協議的一部分并且不能在產品中出現。
我見過有一個項目突然接到測試人員發出的錯誤災難的報告。結果是他們測試的是老版本的軟件需求規格說明，而他們覺得錯誤的地方正是產品所獨有的特性。他們的測試工作是徒勞的，因為他們一直在老版本的軟件需求規格說明中尋找錯誤的系統行為。
在編寫軟件需求規格說明，希望讀者牢記以下的建議：
對節、小節和單個需求的號碼編排必須一致。
在右邊部分留下文本注釋區。
允許不加限制地使用空格。
正確使用各種可視化強調標志（例如，黑體、下劃線、斜體和其它不同字體）。
創建目錄表和索引表有助于讀者尋找所需的信息。
對所有圖和表指定號碼和標識號，并且可按號碼進行查閱。
使用字處理程序中交叉引用的功能來查閱文檔中其它項或位置，而不是通過頁碼或節號。
為了滿足軟件需求規格說明的可跟蹤性和可修改性的質量標準，必須唯一確定每個軟件需求。這可以使你在變更請求、修改歷史記錄、交叉引用或需求的可跟蹤矩陣中查閱特定的需求。由于要達到這一目的，用單一的項目列表是不夠的，因此，我將描述幾個不同的需求標識方法，并闡明它們的優點與缺點�？梢赃x擇最適合你的方法。
(1) 序列號最簡單的方法是賦予每個需求一個唯一的序列號，例如SRS-13。當一個新的需求加入到商業需求管理工具的數據庫之后，這些管理工具就會為其分配一個序列號（許多這樣的工具也支持層次化編號）。序列號的前綴代表了需求類型，例如SRS代表“軟件需求說明”。由于序列號不能重用，所以把需求從數據庫中刪除時，并不釋放其所占據的序列號，而新的需求只能得到下一個可用的序列號。這種簡單的編號方法并不能提供任何相關需求在邏輯上或層次上的區別，而且需求的標識不能提供任何有關每個需求內容的信息。
(2) 層次化編碼這也許是最常用的方法。如果功能需求出現在軟件需求規格說明中第3 . 2部分，那么它們將具有諸如3.2.4.3這樣的標識號。標識號中的數字越多則表示該需求越詳細，屬于較低層次上的需求。即使在一個中型的軟件需求規格說明中，這些標識號也會擴展到許多位數字，并且這些標識也不提供任何有關每個需求目的的信息。如果你要插入一個新的需求，那么該需求所在部分其后所有需求的序號將要增加。刪除或移去一個需求，那么該需求所在部分其后所有需求的序號將要減少。但其他地方的引用將混亂，對于這種簡單的層次化編號的一種改進方法是對需求中主要的部分進行層次化編號，然后對于每個部分中的單一功能需求用一個簡短文字代碼加上一個序列號來識別。例如，軟件需求規格說明可能包含“第3.2.5部分—編輯功能”，并將此部分編寫成子模塊文檔，然后配置管理。
文章來源于領測軟件測試網 http://www.kjueaiud.com/