合格的軟件需求規格說(shuō)明書(shū)
軟件需求規格說(shuō)明作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有的需求。開(kāi)發(fā)者和客戶(hù)不能作任何假設。如果任何所期望的功能或非功能需求未寫(xiě)入軟件需求規格說(shuō)明那么它將不能作為協(xié)議的一部分并且不能在產(chǎn)品中出現。
構造并編寫(xiě)軟件需求規格說(shuō)明，并使用戶(hù)和其它讀者能理解它牢記以下可讀性的建議：
• 對節、小節和單個(gè)需求的號碼編排必須一致。
• 在右邊部分留下文本注釋區。
• 允許不加限制地使用空格。
• 正確使用各種可視化強調標志（例如，黑體、下劃線(xiàn)、斜體和其它不同字體）。
• 創(chuàng )建目錄表和索引表有助于讀者尋找所需的信息。
• 對所有圖和表指定號碼和標識號，并且可按號碼進(jìn)行查閱。
• 使用字處理程序中交叉引用的功能來(lái)查閱文檔中其它項或位置，而不是通過(guò)頁(yè)碼或節號。
1.5 優(yōu)秀需求具有的特性
怎樣才能把好的需求規格說(shuō)明和有問(wèn)題的需求規格說(shuō)明區別開(kāi)來(lái)？下面討論單個(gè)需求陳述說(shuō)明的幾個(gè)特點(diǎn)（ Davis 1993；IEEE 1998）。讓風(fēng)險承擔者從不同角度對S R S需求說(shuō)明進(jìn)行認真評審，能很好地確定哪些需求確實(shí)是需要的。只要你在編寫(xiě)、評審需求時(shí)把這些特點(diǎn)記在心中，就會(huì )寫(xiě)出更好的（盡管并不十分完美）需求文檔，同時(shí)也會(huì )開(kāi)發(fā)出更好的產(chǎn)品。
1.5.1 需求說(shuō)明的特征
1. 完整性
每一項需求都必須將所要實(shí)現的功能描述清楚，以使開(kāi)發(fā)人員獲得設計和實(shí)現這些功能所需的所有必要信息。
2. 正確性
每一項需求都必須準確地陳述其要開(kāi)發(fā)的功能。做出正確判斷的參考是需求的來(lái)源，如用戶(hù)或高層的系統需求規格說(shuō)明。若軟件需求與對應的系統需求相抵觸則是不正確的。只有用戶(hù)代表才能確定用戶(hù)需求的正確性，這就是一定要有用戶(hù)的積極參與的原因。沒(méi)有用戶(hù)參與的需求評審將導致此類(lèi)說(shuō)法：“那些毫無(wú)意義，這些才很可能是他們所要想的。”其實(shí)這完全是評審者憑空猜測。
3. 可行性
每一項需求都必須是在已知系統和環(huán)境的權能和限制范圍內可以實(shí)施的。為避免不可行的需求，最好在獲?。?e l i c i t a t i o n）需求(收集需求)過(guò)程中始終有一位軟件工程小組的組員與需求分析人員或考慮市場(chǎng)的人員在一起工作，由他負責檢查技術(shù)可行性。
4. 必要性
每一項需求都應把客戶(hù)真正所需要的和最終系統所需遵從的標準記錄下來(lái)。“必要性”也可以理解為每項需求都是用來(lái)授權你編寫(xiě)文檔的“根源”。要使每項需求都能回溯至某項客戶(hù)的輸入，如使用實(shí)例或別的來(lái)源。
5. 劃分優(yōu)先級
給每項需求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級以指明它在特定產(chǎn)品中所占的分量。如果把所有的需求都看作同樣重要，那么項目管理者在開(kāi)發(fā)或節省預算或調度中就喪失控制
6. 無(wú)二義性
對所有需求說(shuō)明的讀者都只能有一個(gè)明確統一的解釋?zhuān)捎谧匀徽Z(yǔ)言極易導致二義性，所以盡量把每項需求用簡(jiǎn)潔明了的用戶(hù)性的語(yǔ)言表達出來(lái)。避免二義性的有效方法包括對需求文檔的正規審查，編寫(xiě)測試用例，開(kāi)發(fā)原型以及設計特定的方案腳本。
7. 可驗證性
檢查一下每項需求是否能通過(guò)設計測試用例或其它的驗證方法，如用演示、檢測等來(lái)確定產(chǎn)品是否確實(shí)按需求實(shí)現了。如果需求不可驗證，則確定其實(shí)施是否正確就成為主觀(guān)臆斷，而非客觀(guān)分析了。一份前后矛盾，不可行或有二義性的需求也是不可驗證的。
1.5.2 需求規格說(shuō)明的特點(diǎn)
1. 完整性
不能遺漏任何必要的需求信息。遺漏需求將很難查出。注重用戶(hù)的任務(wù)而不是系統的功能將有助于你避免不完整性。如果知道缺少某項信息，用T B D (“待確定” )作為標準標識來(lái)標明這項缺漏。在開(kāi)始開(kāi)發(fā)之前，必須解決需求中所有的T B D項。
2. 一致性
一致性是指與其它軟件需求或高層（系統，業(yè)務(wù)）需求不相矛盾。在開(kāi)發(fā)前必須解決所有需求間的不一致部分。只有進(jìn)行一番調查研究，才能知道某一項需求是否確實(shí)正確。
3. 可修改性
在必要時(shí)或為維護每一需求變更歷史記錄時(shí)，應該修訂S R S。這就要求每項需求要獨立標出，并與別的需求區別開(kāi)來(lái)，從而無(wú)二義性。每項需求只應在S R S中出現一次。這樣更改時(shí)易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規格說(shuō)明更容易修改。
4. 可跟蹤性
應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好（ f i n e - g r a i n e d）的方式編寫(xiě)并單獨標明，而不是大段大段的敘述。
聯(lián)系客服
