編寫優(yōu)秀的需求文檔沒有現(xiàn)成固定的方法，最好是根據(jù)經(jīng)驗進行。從過去所遇到的問題中可使你受益匪淺。許多需求文檔可以通過使用有效的技術(shù)編寫風(fēng)格和使用用戶術(shù)語而不是計算機專業(yè)術(shù)語的方式得以改進（ Kovitz 1999）。你在編寫軟件需求文檔時，應(yīng)牢記以下幾點建議：
? 保持語句和段落的簡短。
? 采用主動語態(tài)的表達方式。
? 編寫具有正確的語法、拼寫和標(biāo)點的完整句子。
? 使用的術(shù)語與詞匯表中所定義的應(yīng)該一致。
? 需求陳述應(yīng)該具有一致的樣式，例如“系統(tǒng)必須??”或者“用戶必須??”，并緊跟一個行為動作和可觀察的結(jié)果。例如，“倉庫管理子系統(tǒng)必須顯示一張所請求的倉庫中有存貨的化學(xué)藥品容器清單。”
? 為了減少不確定性，必須避免模糊的、主觀的術(shù)語，例如，用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術(shù)、優(yōu)越的、可接受的和健壯的。當(dāng)用客說“用戶友好”或者“快”或者“健壯”時，你應(yīng)該明確它們的真正含義并且在需求中闡明用戶的意圖。
? 避免使用比較性的詞匯，例如：提高、最大化、最小化和最佳化。定量地說明所需要提高的程度或者說清一些參數(shù)可接受的最大值和最小值。當(dāng)客戶說明系統(tǒng)應(yīng)該“處理”、“支持”或“管理”某些事情時，你應(yīng)該能理解客戶的意圖。含糊的語句表達將引起需求的不可驗證。由于需求的編寫是層次化的，因此，可以把頂層不明確的需求向低層詳細分解，直到消除不明確性為止。編寫詳細的需求文檔，所帶來的益處是如果需求得到滿足，那么客戶的目的也就達到了，但是不要讓過于詳細的需求影響了設(shè)計。如果你能用不同的方法來滿足需求且這種方法都是可接受的，那么需求的詳細程度也就足夠了。然而，如果評審軟件需求規(guī)格說明的設(shè)計人員對客戶的意圖還不甚了解，那么就需要增加額外的說明，以減少由于誤解而產(chǎn)生返工的風(fēng)險。
需求文檔的編寫人員總是力求尋找到恰如其分的需求詳細程度。一個有益的原則就是編寫單個的可測試需求文檔。如果你想出一些相關(guān)的測試用例可以驗證這個需求能夠正確地實現(xiàn)，那么就達到了合理的詳細程度。如果你預(yù)想的測試很多并且很分散，那么可能就要將一些集合在一起的需求分離開。已經(jīng)建議將可測試的需求作為衡量軟件產(chǎn)品規(guī)模大小的尺度（Wilson 1995）。
文檔的編寫人員必須以相同的詳細程度編寫每個需求文檔。我曾見過在同一份軟件需求規(guī)格說明中，對需求的說明五花八門。例如，“組合鍵C o n t r o l - S代表保存文件”和“組合鍵C o n t r o l - P代表打印文件”被當(dāng)成兩個獨立的需求。然而，“產(chǎn)品必須響應(yīng)以語音方式輸入的編輯指令”則被作為一個子系統(tǒng)，而并不作為一個簡單的功能需求。文檔的編寫人員不應(yīng)該把多個需求集中在一個冗長的敘述段落中。在需求中諸如“和”，“或”之類的連詞就表明了該部分集中了多個需求。務(wù)必記住，不要在需求說明中使用“和/或”，“等等”之類的連詞。文檔的編寫人員在編寫軟件需求規(guī)格說明時不應(yīng)該出現(xiàn)需求冗余。雖然在不同的地方出現(xiàn)相同的需求可能會使文檔更易讀，但這也造成了維護上的困難。需求的多個實例都需要同時更新，以免造成需求各實例之間的不一致。在軟件需求規(guī)格說明中交叉引用相關(guān)的各項，在進行更改時有助于保持它們之間的同步。讓獨立性強的需求在需求管理工具或數(shù)據(jù)庫中只出現(xiàn)一次，這樣可以緩和冗余問題。
適合某種模式的需求編號列表的表格化示例
文檔的編寫人員應(yīng)考慮用最有效的方法表達每個需求?？紤]符合如下句型的一系列需求：“文本編輯器應(yīng)該能分析定義有<管區(qū)>法律的<格式>文檔?！睂τ? 2種相似的需求中， <格式>所取的可能值有3種，<管區(qū)>所取的可能值有4種。當(dāng)
你評審與此類似的需求時，很難發(fā)現(xiàn)遺漏了一個需求，例如“文本編輯器應(yīng)該能分析定義了國際法的無標(biāo)記文檔?！笨梢杂帽碇械倪@種格式表示需求，以確保你沒有遺漏掉任何一個需求。