規(guī)格說明中尋找錯誤的系統(tǒng)行為。
在編寫軟件需求規(guī)格說明，希望讀者牢記以下的建議：
對節(jié)、小節(jié)和單個需求的號碼編排必須一致。
在右邊部分留下文本注釋區(qū)。
允許不加限制地使用空格。
正確使用各種可視化強調(diào)標志（例如，黑體、下劃線、斜體和其它不同字體）。
創(chuàng)建目錄表和索引表有助于讀者尋找所需的信息。
對所有圖和表指定號碼和標識號，并且可按號碼進行查閱。
    使用字處理程序中交叉引用的功能來查閱文檔中其它項或位置，而不是通過頁碼或節(jié)號。
    為了滿足軟件需求規(guī)格說明的可跟蹤性和可修改性的質(zhì)量標準，必須唯一確定每個軟件需求。這可以使你在變更請求、修改歷史記錄、交叉引用或需求的可跟蹤矩陣中查閱特定的需求。由于要達到這一目的，用單一的項目列表是不夠的，因此，我將描述幾個不同的需求標識方法，并闡明它們的優(yōu)點與缺點?？梢赃x擇最適合你的方法。
(1) 序列號最簡單的方法是賦予每個需求一個唯一的序列號，例如SRS-13。當一個新的需求加入到商業(yè)需求管理工具的數(shù)據(jù)庫之后，這些管理工具就會為其分配一個序列號（許多這樣的工具也支持層次化編號）。序列號的前綴代表了需求類型，例如SRS代表“軟件需求說明”。由于序列號不能重用，所以把需求從數(shù)據(jù)庫中刪除時，并不釋放其所占據(jù)的序列號，而新的需求只能得到下一個可用的序列號。這種簡單的編號方法并不能提供任何相關需求在邏輯上或?qū)哟紊系膮^(qū)別，而且需求的標識不能提供任何有關每個需求內(nèi)容的信息。
(2) 層次化編碼這也許是最常用的方法。如果功能需求出現(xiàn)在軟件需求規(guī)格說明中第3 . 2部分，那么它們將具有諸如3.2.4.3這樣的標識號。標識號中的數(shù)字越多則表示該需求越詳細，屬于較低層次上的需求。即使在一個中型的軟件需求規(guī)格說明中，這些標識號也會擴展到許多位數(shù)字，并且這些標識也不提供任何有關每個需求目的的信息。如果你要插入一個新的需求，那么該需求所在部分其后所有需求的序號將要增加。刪除或移去一個需求，那么該需求所在部分其后所有需求的序號將要減少。但其他地方的引用將混亂，對于這種簡單的層次化編號的一種改進方法是對需求中主要的部分進行層次化編號，然后對于每個部分中的單一功能需求用一個簡短文字代碼加上一個序列號來識別。例如，軟件需求規(guī)格說明可能包含“第3.2.5部分—編輯功能”，并將此部分編寫成子模塊文檔，然后配置管理。
    有時，你覺得缺少特定需求的某些信息。在解決這個不確定性之前，可能必須與客戶商議、檢查與另一個系統(tǒng)的接口或者定義另一個需求。使用“待確定”（to be determined, TBD或采用漢語拼音略寫DQD）符號作為標準指示器來強調(diào)軟件需求規(guī)格說明中這些需求的缺陷。通過這種方法，你可以在軟件需求規(guī)格說明中查找所要澄清需求的部分。記錄誰將解決哪個問題、怎樣解決及什么時候解決。把每個TBD編號并創(chuàng)建一個TBD列表，這有助于方便地跟蹤每個項目。
    在繼續(xù)進行構(gòu)造需求集合之前，必須解決所有的TBD問題，因為任何遺留下來的不確定問題將會增加出錯的風險和需求返工。當開發(fā)人員遇到一個TBD問題或其它模糊之處時，他可能不會返回到原始需求來解決問題。多半開發(fā)者對它進行猜測，但并不總是正確的。如果有TBD問題尚未解決，而你又要繼續(xù)進行開發(fā)工作，那么盡可能推遲實現(xiàn)這些需求，或者解決這些需求的開放式問題，把產(chǎn)品的這部分設計得易于更改。
    編寫優(yōu)秀的需求文檔沒有現(xiàn)成固定的方法，最好是根據(jù)經(jīng)驗進行。從過去所遇到的問題中可使你受益匪淺。許多需求文檔可以通過使用有效的技術(shù)編寫風格和使用用戶術(shù)語而不是計算機專業(yè)術(shù)語的方式得以改進。
你在編寫優(yōu)秀的需求文檔時，希望讀者還需牢記以下幾點建議：
保持語

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html