需求的規格化與驗證
一、需求規格說明文件的重要性
在複雜的系統開發中，編寫需求規格說明文件能夠清晰、明確、結構化地將軟體系統的需求資訊和解決方案更好的傳遞給所有開發者。其中包括設計人員、程式設計師、測試人員及使用者使用手冊的文件編寫人員等。可以保障資訊一致、重複地傳遞給需要的人，因此，需求規格說明文件有著極其重要的作用。
二、優秀的需求規格說明文件特性：
[ieee830-1998]指出乙份優秀的需求規格說明文件應該具備下面的特性：正確性、無歧義、完備性、一致性、根據重要性和穩定性分級、可驗證、可修改、可追蹤。
（一） 完備性
需求規格說明文件應描述了使用者所有有意義的需求，包括效能、功能、約束、質量屬性和對外介面。每一條需求也是完備的，定義了軟體對所有輸入情況的響應，為文件中所有的插圖、圖、表和術語、度量單位的定義提供了完整的引用和標記。
（二）一致性
其一致性主要包含兩方面：一是細節的需求不能同高層次需求相衝突，二是同一層次的需求之間也不能相互衝突。
為保證文件的一致性，由開發人員和非開發人員對其進行手工評審是非常必要的。人們也在努力的建立和使用一些能夠自動檢查文件一致性的分析工具。
（三）根據重要性和穩定性分級
在高質量的需求集中，開發人員、客戶及其他風險承擔人已經根據客戶的重要性和穩定性給單個需求分級了。分級過程對於專案的範圍管理極其重要。如果現有資源不足以實現進度和預算中的所有需求，那麼知道什麼需求是易變的、對使用者是關鍵的就顯得尤為重要了。
（四）可修改
可修改是指：它的結構和風格使得人們可以對任一需求進行容易的、完整的、一致的修改，同時還不會影響文件現有的結構和風格。需求規格說明文件必須要求可修改，尤其是在目前迭代開發的模式下。
（五）可跟蹤
文件可跟蹤當且僅當每個需求的**清晰，並且存在一種機制使在未來的開發中引用該需求是可行的。
三、書寫需求規格說明文件的細節描述問題
（一）定義術語表或資料字典
（1）術語不一致
在人們計畫和編寫文件的時候，通常使用一些術語，然後因為後期加入了新的想法或者對問題域有了更深的認識，造成對術語進行無數次修改。因此，建立並維護乙個術語表，將方便人們對術語進行「替換」和「修改」，從而一定程度上避免出現屬於不一致。
（2）「方言」問題
由於每個人的理解能力和理解問題的思考角度不同，即使相同的文件描述，不同的人也會有不同的理解，正所謂「一千個讀者就有一千個哈姆雷特」。例如，將「客戶」可能稱為「顧客」、「投資人」等，為了避免這種情況發生，在建立術語表時，可以逐一解釋術語的「方言」形式，這樣就妥善地解決了「方言」問題。
（3）錯誤術語和冗餘術語
正所謂「言多必失」，太多重複的文字描述容易降低文件的精確性和清晰性。因此，將文件使用的詞彙限制在一些必要的基礎詞匯集及問題域的詞匯集上，將能夠降低這種問題發生的可能性。
（二）避免面干擾文字
干擾文字指那些沒有實用目的，對文件內容的理解沒有貢獻的文字。其中，元文字就是常見的干擾文字，主要表現為出現「這一段的意思是」、「上一句話是指」等。雖然，有時候元文字是必要的，能夠加強讀者對文件的；理解，但大多數情況下會浪費讀者閱讀時間。較好的使用元文字就是將其放在「引言」部分，能夠讓讀者大致理解本文的內容和結構。
（三）避免歧義詞彙
四、需求規格說明文件的寫作技巧
（一）內容組織
（1）所有內容位置得當
文件應該有規範的章節、清晰的邏輯結構、簡明的文章內容，以便於讀者去理解。
（2）引用或強化，但不重複
對於文件的必要的冗餘重複資訊，可以考慮使用引用在文件中交叉引用相關的各項。關於強化，「引言」、「圖表」就是一種很重要的冗餘強化，「引言」能夠簡要地快速讓讀者明白文章意圖，「圖表」清晰的邏輯、數量關係則給人強烈的視覺衝擊，就如「一圖抵千金」，「圖表」的有效利用能夠加深讀者的理解認識，減少文字的敘述，方便閱讀。
（二）表達方式
（1）形式依賴於內容
檔過程中，沒有規定的形式，一般根據實際需要表達的內容，選擇合適的表達方式。可將示意圖和**按照實際需要進行使用，其最重要的目的就是能夠傾向表達內容的方式。
（2）使用系統的表達方式
讀文件或寫作時，會傾向於用一種系統的方式來計畫和檢查這些文件的內容，因此在使用相同語句格式來描述多有的細節需求、使用列表或者**來組織獨立、並列的資訊及使用編號來表達繁雜資訊之間的關係（包括順序關係、巢狀關係、層次關係）等時，在內容表達能力相同的情況下，人們會傾向於系統的表達方式。
五、結語
書寫需求規格說明文件，既要完備又要簡明，利用多種形式是文件內容簡化，但仍舊要滿足完備性，能夠描述使用者的所有需求。寫乙份好的說明文件不光需要完美的模板和優秀的寫作技巧，最重要是對系統有清晰明了的認識的認識，保證闡述內容完備並簡要。
《軟體需求工程》閱讀筆記05
第四章 需求分析 1.建立系統關聯圖 這個是我們在課堂上學習的系統上下文圖，目的之一是確定收集需求資訊的範圍，用圖形表示系統與外部實體之間的關係。2.分析需求的可行性 基本任務是在允許的成本和效能要求以及系統的範圍內，分析每項需求得以實施的可行性 3.構建使用者介面原型 對於軟體開發人員或使用者不能...
05需求工程軟體建模與分析閱讀筆記之五
此次閱讀了解到了常見的問題框架。大致分為六種 1 需求行為控制系統 存在物理世界的某個部分，其行為須要收到控制，以使得他們滿足特定的條件，問題是要建立乙個系統，系統將施加所須要的控制。2 命令行為控制系統 存在物理世界的某個部分，其行為需要根據操作者發出的命令進行控制。問題是要建立乙個系統，他將將接...
《需求工程 軟體建模與分析》04
一 需求捕獲過程 一 需求內容 1 需求。主要表現為使用者對系統的期望及目標，在獲取中體現為涉眾的問題 期望 觀點 看法和態度等。2 問題與描述。主要用於承載和解釋需求的問題域特性，表現為現實世界的業務運 況。3 環境與約束。這屬於一種特殊的問題域特性，其主要 於涉眾的描述和對應用環境的觀察。1 涉...