前言：本站為你精心整理了編寫軟件項目管理范文，希望能為你的創作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

編寫優秀的需求文檔沒有現成固定的方法，最好是根據經驗進行。從過去所遇到的問題中可使你受益匪淺。許多需求文檔可以通過使用有效的技術編寫風格和使用用戶術語而不是計算機專業術語的方式得以改進（kovitz1999）。你在編寫軟件需求文檔時，應牢記以下幾點建議：

•保持語句和段落的簡短。

•采用主動語態的表達方式。

•編寫具有正確的語法、拼寫和標點的完整句子。

•使用的術語與詞匯表中所定義的應該一致。

•需求陳述應該具有一致的樣式，例如“系統必須⋯⋯”或者“用戶必須⋯⋯”，并緊跟一個行為動作和可觀察的結果。例如，“倉庫管理子系統必須顯示一張所請求的倉庫中有存貨的化學藥品容器清單。”

•為了減少不確定性，必須避免模糊的、主觀的術語，例如，用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術、優越的、可接受的和健壯的。當用客說“用戶友好”或者“快”或者“健壯”時，你應該明確它們的真正含義并且在需求中闡明用戶的意圖。

•避免使用比較性的詞匯，例如：提高、最大化、最小化和最佳化。定量地說明所需要提高的程度或者說清一些參數可接受的最大值和最小值。當客戶說明系統應該“處理”、“支持”或“管理”某些事情時，你應該能理解客戶的意圖。含糊的語句表達將引起需求的不可驗證。由于需求的編寫是層次化的，因此，可以把頂層不明確的需求向低層詳細分解，直到消除不明確性為止。編寫詳細的需求文檔，所帶來的益處是如果需求得到滿足，那么客戶的目的也就達到了，但是不要讓過于詳細的需求影響了設計。如果你能用不同的方法來滿足需求且這種方法都是可接受的，那么需求的詳細程度也就足夠了。然而，如果評審軟件需求規格說明的設計人員對客戶的意圖還不甚了解，那么就需要增加額外的說明，以減少由于誤解而產生返工的風險。

需求文檔的編寫人員總是力求尋找到恰如其分的需求詳細程度。一個有益的原則就是編寫單個的可測試需求文檔。如果你想出一些相關的測試用例可以驗證這個需求能夠正確地實現，那么就達到了合理的詳細程度。如果你預想的測試很多并且很分散，那么可能就要將一些集合在一起的需求分離開。已經建議將可測試的需求作為衡量軟件產品規模大小的尺度（wilson1995）。

文檔的編寫人員必須以相同的詳細程度編寫每個需求文檔。我曾見過在同一份軟件需求規格說明中，對需求的說明五花八門。例如，“組合鍵control-s代表保存文件”和“組合鍵control-p代表打印文件”被當成兩個獨立的需求。然而，“產品必須響應以語音方式輸入的編輯指令”則被作為一個子系統，而并不作為一個簡單的功能需求。文檔的編寫人員不應該把多個需求集中在一個冗長的敘述段落中。在需求中諸如“和”，“或”之類的連詞就表明了該部分集中了多個需求。務必記住，不要在需求說明中使用“和/或”，“等等”之類的連詞。文檔的編寫人員在編寫軟件需求規格說明時不應該出現需求冗余。雖然在不同的地方出現相同的需求可能會使文檔更易讀，但這也造成了維護上的困難。需求的多個實例都需要同時更新，以免造成需求各實例之間的不一致。在軟件需求規格說明中交叉引用相關的各項，在進行更改時有助于保持它們之間的同步。讓獨立性強的需求在需求管理工具或數據庫中只出現一次，這樣可以緩和冗余問題。

文檔的編寫人員應考慮用最有效的方法表達每個需求。考慮符合如下句型的一系列需求：“文本編輯器應該能分析定義有<管區>法律的<格式>文檔。”對于12種相似的需求中，<格式>所取的可能值有3種，<管區>所取的可能值有4種。當你評審與此類似的需求時，很難發現遺漏了一個需求，例如“文本編輯器應該能分析定義了國際法的無標記文檔。”可以用表中的這種格式表示需求，以確保你沒有遺漏掉任何一個需求。