優(yōu)秀需求具有的特性

申請免費試用、咨詢電話：400-8352-114

一、 需求說明的特征

1. 完整性

　　每一項需求都必須將所要實現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設計和實現(xiàn)這些功能所需的所有必要信息。

2. 正確性

　　每一項需求都必須準確地陳述其要開發(fā)的功能。做出正確判斷的參考是需求的來源，如用戶或高層的系統(tǒng)需求規(guī)格說明。若軟件需求與對應的系統(tǒng)需求相抵觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用戶的積極參與的原因。沒有用戶參與的需求評審將導致此類說法：“那些毫無意義，這些才很可能是他們所要想的?！逼鋵嵾@完全是評審者憑空猜測。

3. 可行性

　　每一項需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實施的。為避免不可行的需求，最好在獲?。╡licitation）需求(收集需求)過程中始終有一位軟件工程小組的組員與需求分析人員或考慮市場的人員在一起工作，由他負責檢查技術(shù)可行性。

4. 必要性

　　每一項需求都應把客戶真正所需要的和最終系統(tǒng)所需遵從的標準記錄下來。“必要性”也可以理解為每項需求都是用來授權(quán)你編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如使用實例或別的來源。

5. 劃分優(yōu)先級

　　給每項需求、特性或使用實例分配一個實施優(yōu)先級以指明它在特定產(chǎn)品中所占的分量。如果把所有的需求都看作同樣重要，那么項目管理者在開發(fā)或節(jié)省預算或調(diào)度中就喪失控制自由度。

6. 無二義性

　　對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。避免二義性的有效方法包括對需求文檔的正規(guī)審查，編寫測試用例，開發(fā)原型以及設計特定的方案腳本。

7. 可驗證性

　　檢查一下每項需求是否能通過設計測試用例或其它的驗證方法，如用演示、檢測等來確定產(chǎn)品是否確實按需求實現(xiàn)了。如果需求不可驗證，則確定其實施是否正確就成為主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的需求也是不可驗證的。

二、 需求規(guī)格說明的特點

1. 完整性

　　不能遺漏任何必要的需求信息。遺漏需求將很難查出。注重用戶的任務而不是系統(tǒng)的功能將有助于你避免不完整性。如果知道缺少某項信息，用TBD (“待確定” )作為標準標識來標明這項缺漏。在開始開發(fā)之前，必須解決需求中所有的TBD項。

2. 一致性

　　一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務）需求不相矛盾。在開發(fā)前必須解決所有需求間的不一致部分。只有進行一番調(diào)查研究，才能知道某一項需求是否確實正確。

3. 可修改性

　　在必要時或為維護每一需求變更歷史記錄時，應該修訂SRS。這就要求每項需求要獨立標出，并與別的需求區(qū)別開來，從而無二義性。每項需求只應在SRS中出現(xiàn)一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明更容易修改。

4. 可跟蹤性

　　應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結(jié)構(gòu)化的，粒度好（fine-grained）的方式編寫并單獨標明，而不是大段大段的敘述。