此外，確定項目對外部因素存在的依賴。例如，如果你打算把其它項目開發的組件集成到系統中，那么你就要依賴那個項目按時提供正確的操作組件。如果這些依賴已經記錄到其它文檔(例如項目計劃)中了，那么在此就可以參考其它文檔。
c. 外部接口需求
利用本節來確定可以保證新產品與外部組件正確連接的需求。關聯圖表示了高層抽象的外部接。需要把對接口數據和控制組件的詳細描述寫入數據字典中。如果產品的不同部分有不同的外部接口，那么應把這些外部接口的詳細需求并入到這一部分的實例中。
c.1 用戶界面
陳述所需要的用戶界面的軟件組件。描述每個用戶界面的邏輯特征。而對于用戶界面的細節，例如特定對話框的布局，應該寫入一個獨立的用戶界面規格說明中，而不能寫入軟件需求規格說明中。
c.2 硬件接口
描述系統中軟件和硬件每一接口的特征。這種描述可能包括支持的硬件類型、軟硬件之間交流的數據和控制信息的性質以及所使用的通信協議。
c.3 軟件接口
描述該產品與其它外部組件（由名字和版本識別）的連接，包括數據庫、操作系統、工具、庫和集成的商業組件。明確并描述在軟件組件之間交換數據或消息的目的。描述所需要的服務以及內部組件通信的性質。確定將在組件之間共享的數據。
c.4 通信接口
描述與產品所使用的通信功能相關的需求，包括電子郵件、We b 瀏覽器、網絡通信標準或協議及電子表格等等。定義了相關的消息格式。規定通信安全或加密問題、數據傳輸速率和同步通信機制。
d. 系統特性
d.1 說明和優先級
提出了對該系統特性的簡短說明并指出該特性的優先級是高、中，還是低�；蛘吣氵�可以包括對特定優先級部分的評價，例如利益、損失、費用和風險，其相對優先等級可以從1（低）到9 （高）。
d.2 激勵/響應序列
列出輸入激勵（用戶動作、來自外部設備的信號或其它觸發器）和定義這一特性行為的系統響應序列。這些序列將與使用實例相關的對話元素相對應。
d.3 功能需求
詳列出與該特性相關的詳細功能需求。這些是必須提交給用戶的軟件功能，使用戶可以使用所提供的特性執行服務或者使用所指定的使用實例執行任務。描述產品如何響應可預知的出錯條件或者非法輸入或動作。就像本章開頭所描述的那樣，你必須唯一地標識每個需求。
e. 其它非功能需求
這部分列舉出了所有非功能需求，如產品的易用程度如何，執行速度如何，可靠性如何，當發生異常情況時，系統如何處理，而不是外部接口需求和限制。
e.1 性能需求
闡述了不同的應用領域對產品性能的需求，并解釋它們的原理以幫助開發人員作出合理的設計選擇。確定相互合作的用戶數或者所支持的操作、響應時間以及與實時系統的時間關系。你還可以在這里定義容量需求，例如存儲器和磁盤空間的需求或者存儲在數據庫中表的最大行數。盡可能詳細地確定性能需求�？赡苄枰槍γ總�功能需求或特性分別陳述其性能需求，而不是把它們都集中在一起陳述。
e.2 安全設施需求
詳盡陳述與產品使用過程中可能發生的損失、破壞或危害相關的需求。定義必須采取的安全保護或動作，還有那些預防的潛在的危險動作。明確產品必須遵從的安全標準、策略或規則。
e.3 安全性需求
詳盡陳述與系統安全性、完整性或與私人問題相關的需求，這些問題將會影響到產品的使用和產品所創建或使用的數據的保護。定義用戶身份確認或授權需求。明確產品必須滿足的安全性或保密性策略。
e.4 軟件質量屬性
詳盡陳述與客戶或開發人員至關重要的其它產品質量特性。這些特性必須是確定、定量的并在可能時是可驗證的。至少應指明不同屬性的相對側重點，例如易用程度優于易學程度，或者可移植性優于有效性。
e.5 業務規則
列舉出有關產品的所有操作規則，例如什么人在特定環境下可以進行何種操作。這些本身不是功能需求，但它們可以暗示某些功能需求執行這些規則。
e.6 用戶文檔
列舉出將與軟件一同發行的用戶文檔部分，例如，用戶手冊、在線幫助和教程。明確所有已知的用戶文檔的交付格式或標準。
f. 其它需求
定義在軟件需求規格說明的其它部分未出現的需求，例如國際化需求或法律上的需求。你還可以增加有關操作、管理和維護部分來完善產品安裝、配置、啟動和關閉、修復和容錯，以及登錄和監控操作等方面的需求。
附錄A ：詞匯表
定義所有必要的術語，以便讀者可以正確地解釋軟件需求規格說明，包括詞頭和縮寫。你可能希望為整個公司創建一張跨越多項項目的詞匯表，并且只包括特定于單一項目的軟件需求規格說明中的術語。
附錄B ：分析模型
這個可選部分包括或涉及到相關的分析模型的位置，例如數據流程圖、類圖、狀態轉換圖或實體-關系圖。
附錄C ：待確定問題的列表
編輯一張在軟件需求規格說明中待確定問題的列表，其中每一表項都是編上號的，以便于跟蹤調查。
2）指明需求來源：指明需求的來源為了讓所有項目風險承擔者明白需求規格說明書中為何提供這些功能需求，要都能追溯每項需求的來源，這可能是一種使用實例或其它客戶要求，也可能是某項更高層系統需求、業務規范、政府法規、標準或別的外部來源。
3）為每項需求注上標號：為了滿足軟件需求規格說明的可跟蹤性和可修改性的質量標準，必須唯一確定每個軟件需求。為每項需求注上標號制定一種慣例來為需求規格說明書中的每項需求提供一個獨立的可識別的標號或記號。這種慣例應當很健全，允許增加、刪除和修改。作了標號的需求使得需求能被跟蹤，記錄需求變更并為需求狀態和變更活動建立度量。需求標識方法有序列號;層次化編碼;使用"待確定"（to be determined, TBD ）符號等。
4）記錄業務規范：是指關于產品的操作原則，比如誰能在什么情況下采取什么動作。將這些編寫成需求規格說明書中的一個獨立部分，或一獨立的業務規范文檔。某些業務規范將引出相應的功能需求；當然這些需求也應能追溯相應業務規范。
5）創建需求跟蹤能力矩陣：建立一個矩陣把每項需求與實現、測試它的設計和代碼部分聯系起來。這樣的需求跟蹤能力矩陣同時也把功能需求和高層的需求及其它相關需求聯系起來了。在開發過程中建立這個矩陣，而不要等到最后才去補建。
這里我們還要介紹需求規格說明書中設計階段，用到的圖形模型--數據字典、數據流圖、數據流圖、狀態轉換圖、對話圖和類圖。
數據字典：一個定義應用程序中使用的所有數據元素和結構的含義、類型、數據大小、格式、度量單位、精度以及允許取值范圍的共享倉庫。數據字典的維護獨立于軟件需求規格說明，并且在產品的開發和維護的任何階段，各個風險承擔者都可以訪問數據字典。它定義了原數據元素、組成結構體的復雜數據元素、重復的數據項、一個數據項的枚舉值以及可選的數據項。
數據流圖：是結構化系統分析的基本工具。一個數據流圖確定了系統的轉化過程、系統所操縱的數據或物質的收集（存儲），還有過程、存儲、外部世界之間的數據流或物質流。數據流模型把層次分解方法運用到系統分析上，這種方法很適用于事務處理系統和其它功能密集型應用程序。
數據流圖：描繪了系統的數據關系。分析實體聯系圖有助于對業務或系統數據組成的理解和交互，并暗示產品將有必要包含一個數據庫。相反，當你在系統設計階段建立實體聯系圖時，通常要定義系統數據庫的物理結構。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
