前言：本站為你精心整理了軟件項(xiàng)目說(shuō)明特征范文，希望能為你的創(chuàng)作提供參考價(jià)值，我們的客服老師可以幫助你提供個(gè)性化的參考范文，歡迎咨詢。

軟件需求說(shuō)明作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有的需求。開(kāi)發(fā)者和客戶不能作任何假設(shè)。如果任何所期望的功能或非功能需求未寫(xiě)入軟件需求規(guī)格說(shuō)明那么它將不能作為協(xié)議的一部分并且不能在產(chǎn)品中出現(xiàn)。

1.完整性

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

2.正確性

每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開(kāi)發(fā)的功能。做出正確判斷的參考是需求的來(lái)源，如用戶或高層的系統(tǒng)需求規(guī)格說(shuō)明。若軟件需求與對(duì)應(yīng)的系統(tǒng)需求相抵觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用戶的積極參與的原因。沒(méi)有用戶參與的需求評(píng)審將導(dǎo)致此類說(shuō)法：“那些毫無(wú)意義，這些才很可能是他們所要想的?！逼鋵?shí)這完全是評(píng)審者憑空猜測(cè)。

3.可行性

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

4.必要性

每一項(xiàng)需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來(lái)?！氨匾浴币部梢岳斫鉃槊宽?xiàng)需求都是用來(lái)授權(quán)你編寫(xiě)文檔的“根源”。要使每項(xiàng)需求都能回溯至某項(xiàng)客戶的輸入，如使用實(shí)例或別的來(lái)源。

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

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

6.無(wú)二義性

對(duì)所有需求說(shuō)明的讀者都只能有一個(gè)明確統(tǒng)一的解釋，由于自然語(yǔ)言極易導(dǎo)致二義性，所以盡量把每項(xiàng)需求用簡(jiǎn)潔明了的用戶性的語(yǔ)言表達(dá)出來(lái)。避免二義性的有效方法包括對(duì)需求文檔的正規(guī)審查，編寫(xiě)測(cè)試用例，開(kāi)發(fā)原型以及設(shè)計(jì)特定的方案腳本。

7.可驗(yàn)證性

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