一份合格的軟件需求規(guī)格說(shuō)明書(shū)的要求

1、合格的軟件需求規(guī)格說(shuō)明書(shū)軟件需求規(guī)格說(shuō)明作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有 的需求。開(kāi)發(fā)者和客戶不能作任何假設(shè)。如果任何所期望的功能或非功能需求未 寫(xiě)入軟件需求規(guī)格說(shuō)明那么它將不能作為協(xié)議的一部分并且不能在產(chǎn)品中出現(xiàn)。構(gòu)造并編寫(xiě)軟件需求規(guī)格說(shuō)明，并使用戶和其它讀者能理解它牢記以下可讀 性的建議：-對(duì)節(jié)、小節(jié)和單個(gè)需求的號(hào)碼編排必須一致。-在右邊部分留下文本注釋區(qū)。-允許不加限制地使用空格。-正確使用各種可視化強(qiáng)調(diào)標(biāo)志（例如，黑體、下劃線、斜體和其它不同字體）。 創(chuàng)建目錄表和索引表有助于讀者尋找所需的信息。-對(duì)所有圖和表指定號(hào)碼和標(biāo)識(shí)號(hào)，并且可按號(hào)碼進(jìn)行查閱。使用字處理程序中交叉

2、引用的功能來(lái)查閱文檔中其它項(xiàng)或位置，而不是通過(guò)頁(yè) 碼或節(jié)號(hào)。1.5優(yōu)秀需求具有的特性怎樣才能把好的需求規(guī)格說(shuō)明和有問(wèn)題的需求規(guī)格說(shuō)明區(qū)別開(kāi)來(lái)？下面討 論單個(gè)需求陳述說(shuō)明的幾個(gè)特點(diǎn)（Davis 1993； IEEE 1998）。讓風(fēng)險(xiǎn)承擔(dān)者從 不同角度對(duì)S R S需求說(shuō)明進(jìn)行認(rèn)真評(píng)審，能很好地確定哪些需求確實(shí)是需要的。 只要你在編寫(xiě)、評(píng)審需求時(shí)把這些特點(diǎn)記在心中，就會(huì)寫(xiě)出更好的（盡管并不十 分完美）需求文檔，同時(shí)也會(huì)開(kāi)發(fā)出更好的產(chǎn)品。1.5.1需求說(shuō)明的特征完整性每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚，以使開(kāi)發(fā)人員獲得設(shè)計(jì)和實(shí) 現(xiàn)這些功能所需的所有必要信息。正確性每一項(xiàng)需求都必須準(zhǔn)確地陳述其要

3、開(kāi)發(fā)的功能。做出正確判斷的參考是需求 的來(lái)源，如用戶或高層的系統(tǒng)需求規(guī)格說(shuō)明。若軟件需求與對(duì)應(yīng)的系統(tǒng)需求相抵 觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用 戶的積極參與的原因。沒(méi)有用戶參與的需求評(píng)審將導(dǎo)致此類(lèi)說(shuō)法：“那些毫無(wú)意 義，這些才很可能是他們所要想的。”其實(shí)這完全是評(píng)審者憑空猜測(cè)?？尚行悦恳豁?xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的。為 避免不可行的需求，最好在獲取(e l i c i t a t i o n)需求(收集需求) 過(guò)程中始終有一位軟件工程小組的組員與需求分析人員或考慮市場(chǎng)的人員在一 起工作，由他負(fù)責(zé)檢查技術(shù)可行性。必要性每一項(xiàng)需求

4、都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來(lái)?！氨匾浴币部梢岳斫鉃槊宽?xiàng)需求都是用來(lái)授權(quán)你編寫(xiě)文檔的“根源”。要使每 項(xiàng)需求都能回溯至某項(xiàng)客戶的輸入，如使用實(shí)例或別的來(lái)源。劃分優(yōu)先級(jí)給每項(xiàng)需求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級(jí)以指明它在特定產(chǎn)品中所 占的分量。如果把所有的需求都看作同樣重要，那么項(xiàng)目管理者在開(kāi)發(fā)或節(jié)省預(yù) 算或調(diào)度中就喪失控制無(wú)二義性對(duì)所有需求說(shuō)明的讀者都只能有一個(gè)明確統(tǒng)一的解釋?zhuān)捎谧匀徽Z(yǔ)言極易導(dǎo) 致二義性，所以盡量把每項(xiàng)需求用簡(jiǎn)潔明了的用戶性的語(yǔ)言表達(dá)出來(lái)。避免二義 性的有效方法包括對(duì)需求文檔的正規(guī)審查，編寫(xiě)測(cè)試用例，開(kāi)發(fā)原型以及設(shè)計(jì)特 定的方案腳本?？沈?yàn)證性檢查一

5、下每項(xiàng)需求是否能通過(guò)設(shè)計(jì)測(cè)試用例或其它的驗(yàn)證方法，如用演示、 檢測(cè)等來(lái)確定產(chǎn)品是否確實(shí)按需求實(shí)現(xiàn)了。如果需求不可驗(yàn)證，則確定其實(shí)施是 否正確就成為主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的 需求也是不可驗(yàn)證的。1.5.2需求規(guī)格說(shuō)明的特點(diǎn)完整性不能遺漏任何必要的需求信息。遺漏需求將很難查出。注重用戶的任務(wù)而不 是系統(tǒng)的功能將有助于你避免不完整性。如果知道缺少某項(xiàng)信息，用TBD ( “待 確定”）作為標(biāo)準(zhǔn)標(biāo)識(shí)來(lái)標(biāo)明這項(xiàng)缺漏。在開(kāi)始開(kāi)發(fā)之前，必須解決需求中所有 的T B D項(xiàng)。一致性一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務(wù)）需求不相矛盾。在開(kāi)發(fā)前 必須解決所有需求間的不一致部分。只有進(jìn)行一番調(diào)查研究，才能知道某一項(xiàng)需 求是否確實(shí)正確?？尚薷男栽诒匾獣r(shí)或?yàn)榫S護(hù)每一需求變更歷史記錄時(shí)，應(yīng)該修訂S R S。這就要求每 項(xiàng)需求要獨(dú)立標(biāo)出，并與別的需求區(qū)別開(kāi)來(lái)，從而無(wú)二義性。每項(xiàng)需求只應(yīng)在S RS中出現(xiàn)一次。這樣更改時(shí)易于保持一致性。另外，使用目錄表、索引和相互 參照列表方法將使軟件需求規(guī)格說(shuō)明更容易修改?？筛櫺詰?yīng)能在每項(xiàng)軟件需求與它的根源和設(shè)計(jì)元素、