需求描述就是將需求捕獲、分析的結果進行文件化的過程。
在軟體開發時，將分析的結果文件化是不可或缺的任務，也稱為編寫規約活動。而在某個專案中，可能還會由使用者代表或需求捕獲人員對捕獲的內容進行整理，形成使用者需求說明書。
需求描述風格的選擇
在描述需求時，首先要選擇使用什麼風格來表述。是羅列文字還是運用大量的圖表，另外還應該選擇與專案、團隊特點相符合的格式模板。
常見的有自然語言、圖形化和形式化三種。
1、自然語言
使用結構合理的自然語言來表述需求，這種方式一直都是描述需求的首選方法。
2、圖形化模型
在日常交流中，經常會在紙上繪製一些非標準的、低保真的示意圖，以更好地完成溝通。
3、形式化規格表述
形式化規格化描述比圖形規模的進度更高一些，對於邏輯性很強、精度要求很高的場合一般選擇的是規格化描述。
選擇建議
根據不同專案、軟體開發團隊的特點，應考慮將不同的風格組合。
1、現在常見的組合方式是以自然語言為主，輔之以圖形化模型，需要的地方少量使用形式化規格描述。適用於大多數資訊系統、軟體產品。
2、圖形化模型為主，輔之以自然語言作為補充，需要的地方少量使用形式化規格描述；這是rup所推薦的方法，當專案團隊對模型標準有較高的認識時可以考慮這種方法。
3、以形式化規格語言為主，輔之圖形化模型，以自然語言為補充，適用於質量要求很高的領域，例如航天、軍工中的一些重要專案。
做好需求描述時，應謹記「資訊的有效傳遞」，為了真正達到這一目標，我們應該做到以下幾點：
1、可獲得：隨時可以獲得最新的版本，需要用文件管理制度來解決。
2、有更新：應該有專人更新，需要制度來保障。
3、可獲知：寫的人、讀的人都能夠正確地從文件中獲得所需的資訊，需要通過良好的文件模板來解決。
4、易更新：應該確保一類資訊在一處出現，這需要良好的文件模板來解決。
注意：溝通決定內容，內容決定格式。模板不是萬能的，作為需求分析人員，應該結合自身專案的特點、團隊特點、開發方**等特點來建立符合自身專案的模板。
需求文件 故障處理描述
售後服務請求級別說明表 請求級別 描述 最高端系統或重要應用停機，或受到嚴重影響 系統崩潰 高階系統核心應用受到影響，沒有辦法可以繞過去解決，或著繞過去的辦法非常繁瑣。中級系統和應用出現錯誤，但是還可以採用其他方法繞過此問題。低階功能不符合文件上描述的功能或增加的請求。請求級別與解決問題週期對應表 ...
簡單需求描述（自己備用）
1 系統綜述 1.1開發背景 1.2主要任務 1.3相關業務總體流程 2 功能需求 2.1總體功能 2.2基礎資料 2.2.1 基礎資料1 2.2.2 基礎資料2 2.3採購 2.3.1 採購詢價 任務描述 功能與角色 資料項 業務規則 其他附加說明 2.3.2 採購訂單 2.3.3 採購收貨 2....
EDA筆記 8 VHDL描述風格
目錄 一.行為描述 二.資料流描述 三.結構描述 四.總結 1.如果vhdl的結構體只描述了所希望電路的功能 行為，而沒有直接指明或涉及實現這些行為的硬體結構，則稱為行為描述。2.行為描述只表示輸入與輸出間轉換的行為，它不包含任何結構資訊。3.行為描述主要使用函式 過程和程序語句，以演算法形式描述資...