• 保持語句和段落的簡短。
• 采用主動語態的表達方式。
• 編寫具有正確的語法、拼寫和標點的完整句子。
• 使用的術語與詞匯表中所定義的應該一致。
• 需求陳述應該具有一致的樣式，例如“系統必須??”或者“用戶必須??”，并緊跟一個行為動作和可觀察的結果。例如，“倉庫管理子系統必須顯示一張所請求的倉庫中有存貨的化學藥品容器清單。”
• 為了減少不確定性，必須避免模糊的、主觀的術語，例如，用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術、優越的、可接受的和健壯的。當用客說“用戶友好”或者“快”或者“健壯”時，你應該明確它們的真正含義并且在需求中闡明用戶的意圖。
• 避免使用比較性的詞匯，例如：提高、最大化、最小化和最佳化。定量地說明所需要提高的程度或者說清一些參數可接受的最大值和最小值。當客戶說明系統應該“ 處理”、“支持”或“管理”某些事情時，你應該能理解客戶的意圖。含糊的語句表達將引起需求的不可驗證。由于需求的編寫是層次化的，因此，可以把頂層不明 確的需求向低層詳細分解，直到消除不明確性為止。編寫詳細的需求文檔，所帶來的益處是如果需求得到滿足，那么客戶的目的也就達到了，但是不要讓過于詳細的 需求影響了設計。如果你能用不同的方法來滿足需求且這種方法都是可接受的，那么需求的詳細程度也就足夠了。然而，如果評審軟件需求規格說明的設計人員對客 戶的意圖還不甚了解，那么就需要增加額外的說明，以減少由于誤解而產生返工的風險。
• 編寫可測試需求文檔。需求文檔的編寫人員總是力求尋找到恰如其分的需求詳細 程度。一個有益的原則就是編寫單個的可測試需求文檔。如果你想出一些相關的測試用例可以驗證這個需求能夠正確地實現，那么就達到了合理的詳細程度。如果你 預想的測試很多并且很分散，那么可能就要將一些集合在一起的需求分離開。已經建議將可測試的需求作為衡量軟件產品規模大小的尺度（Wilson 1995）。
• 文檔的編寫人員必須以相同的詳細程度編寫每個需求文檔。我曾見過在同一份軟件需求規格說明中，對需求的說明五花八門。例 如，“組合鍵C o n t r o l - S代表保存文件”和“組合鍵C o n t r o l - P代表打印文件”被當成兩個獨立的需求。然而，“產品必須響應以語音方式輸入的編輯指令”則被作為一個子系統，而并不作為一個簡單的功能需求。文檔的編寫 人員不應該把多個需求集中在一個冗長的敘述段落中。在需求中諸如“和”，“或”之類的連詞就表明了該部分集中了多個需求。務必記住，不要在需求說明中使用 “和/或”，“等等”之類的連詞。文檔的編寫人員在編寫軟件需求規格說明時不應該出現需求冗余。雖然在不同的地方出現相同的需求可能會使文檔更易讀，但這 也造成了維護上的困難。需求的多個實例都需要同時更新，以免造成需求各實例之間的不一致。在軟件需求規格說明中交叉引用相關的各項，在進行更改時有助于保持它們之間的同步。讓獨立性強的需求在需求管理工具或數據庫中只出現一次，這樣可以緩和冗余問題。

================可有可無的分割線================

首先，應重視需求分析的目的（意義），編寫目的明確，寫的詳細，能確保文檔的質量有所提高。
下面是一段需求分析意義的范例，希望對大家有所幫助。
1.6進行需求分析的意義
1. 本說明書將對用戶生產信息管理的業務、對系統要實現的主要功能、性能等需求進行全面地闡述，以便幫助用戶判斷所要開發的軟件是否符合他們的要求。該說明書將在軟件開發目標和需求方面為用戶和開發者之間創建一個共同的基礎和共識。
2. 由 于需求說明書要有用戶的審核、修改完善、認定的過程，在這個過程中可以使用戶在軟件設計之前廣泛地征求各業務部門的意見、提出有關系統建設的建議、對自己 的需求和要求進行周密地思考，并要把這些意見和建議反映到用戶需求說明書中。這樣就能減少事后重新設計、重新編碼和重新測試的返工行為。
3. 用戶需求的調查分析過程也是用戶對自己的業務和管理進行總結和規范的過程，通過用戶需求說明書把用戶更加規范的管理反映到了軟件開發中，從而使用戶的管理更加完善和規范。
4. 需求說明書是開發者進行軟件設計的依據，軟件設計要依據本說明書將進行系統分析、數據庫設計、模塊設計、接口設計、輸入輸出格式設計等。
5. 需求說明書使開發者在軟件進行設計和開發之前，能夠充分了解和熟悉用戶的要求，并判斷這些要求是否有不能解決的技術問題，若有應提出一個用戶認可的代替解決方案。以免出現設計出的一個目標不能在開發過程中實現的問題
6. 在需求調查和分析期間可以搜集有關系統開發的有關原始數據和代碼，以便在系統開發中建立開發環境時應用
7. 在軟件開發方面為用戶和開發者提供一個標準，為系統開發結束進行確認和驗收提供一個雙方認可的依據。
8. 便于軟件的維護和提高，為軟件維護和為今后對所開發的軟件進行完善擴充提供進一步分析的基礎。
總之，用戶需求說明書的編寫是軟件工程中的非常關鍵的一個環節，用戶說明書也是軟件工程中的非常重要的一個文檔。一個好的用戶需求說明書不但能夠提高軟件開發的效率、保障軟件開發的質量，而且有利于系統的驗收和以后軟件的維護及擴充。

        下面正式談一下我對需求文檔的一些寫作思路：   

        首先要對用戶機構機構有清晰的了解，寫出各機構所涉及的業務，畫出相應業務的用例圖；之后提取出相應的業務流程，畫出相應的流程圖。通過業務流程，即可抽 象出系統需實現的功能。再將各業務（功能）涉及到對象（如人員，物品等）信息描述出來，根據提取出的信息將功能以IPO表（即輸入、處理、輸出表）的形式 進行描述，逐項定量和定性地敘述對軟件所提出的功能要求，詳細的說明輸入什么量、經怎樣的處理、得到什么輸出，并說明待開發軟件應支持的終端數和應支持的 并行操作的用戶數。需求文檔的主要部分就這樣完成了。

====================完全沒有必要的分割線=====================

引用topic:

http://www.javaeye.com/topic/178200