軟件需求規(guī)格說明書的評(píng)審檢查單

1、精選優(yōu)質(zhì)文檔-傾情為你奉上軟件需求規(guī)格說明書的評(píng)審檢查單軟件需求評(píng)審，作為一種軟件產(chǎn)品驗(yàn)證的活動(dòng)之一，通過及早地從軟件產(chǎn)品中識(shí)別并消除缺陷，從而減少后期的返工，加快開發(fā)進(jìn)度，提高產(chǎn)品的質(zhì)量。在需求階段，發(fā)現(xiàn)一個(gè)需求缺陷的價(jià)值是多大呢？業(yè)內(nèi)有個(gè)缺陷修復(fù)成本比例，需求階段：設(shè)計(jì)階段：測試階段：上市階段N:10N:100N:1000N；方案一一、 注意對(duì)需求規(guī)格說明的正確性進(jìn)行評(píng)審 需求規(guī)格說明的正確性通?？梢詮娜缦路矫娴靡泽w現(xiàn)： 1 是否有需求與其他需求相互沖突或者重復(fù)？ 2 是否清晰、簡潔、無二義地表達(dá)了每個(gè)需求? “清晰”是讓人能夠讀懂；“簡潔”是讓人愿意去讀；“無二義”決定”讀”的效果,是讓

2、大家對(duì)需求描述的理解能夠達(dá)成一致 。 3 是否每個(gè)需求都通過了演示、測試、評(píng)審，分析是否得到了驗(yàn)證? 4 是否每個(gè)需求都在項(xiàng)目的范圍內(nèi)? 5 是否每個(gè)需求都沒有內(nèi)容和語法上的錯(cuò)誤? 6 在現(xiàn)有的資源內(nèi), 是否能實(shí)現(xiàn)所有的需求? 7 每一條特定的錯(cuò)誤信息，是否都是唯一的和具有含義的? 二、 注意對(duì)需求規(guī)格說明的實(shí)踐性進(jìn)行評(píng)審 所謂實(shí)踐性是指需求本身是否來源于目前企業(yè)的相關(guān)業(yè)務(wù)規(guī)則和文件制度,而非源于分析師們經(jīng)驗(yàn)主義的臆測。實(shí)踐性是判斷需求規(guī)格說明是不是理論聯(lián)系實(shí)踐、密切和用戶聯(lián)系的一個(gè)關(guān)鍵性指標(biāo)。三、 注意對(duì)需求規(guī)格說明的完整性進(jìn)行評(píng)審 我們經(jīng)常由下面的問題清單來評(píng)審需求說明書是否”完整” 。

3、1 編寫的所有需求，其詳細(xì)程度是否一致和合適? 2 需求是否能為設(shè)計(jì)提供足夠的基礎(chǔ)? 3 所有對(duì)其他需求的內(nèi)部引用是否正確? 4 是否包含了每個(gè)需求的實(shí)現(xiàn)優(yōu)先級(jí)? 5 是否定義了功能說明的內(nèi)在算法? 6 是否包含了所有已知的客戶需求或系統(tǒng)需求? 7 是否遺漏了必要的信息?如果有遺漏的話,把他們標(biāo)記為待確定的問題(TBD) ? 8 是否對(duì)所有預(yù)期的錯(cuò)誤條件所產(chǎn)生的系統(tǒng)行為都編制了文檔? 需求說明的完整性主要體現(xiàn)在需求說明的詳細(xì)程度上，我們?cè)鯓优袛嘣撔枨蟮拿枋鍪欠裨敿?xì)呢?我認(rèn)為需求需要精化，而不是僅僅提出精化功能、對(duì)象要考慮涉眾參與者、做些什么、需要什么數(shù)據(jù)信息、受什么業(yè)務(wù)規(guī)則和條件限制、系統(tǒng)會(huì)有

4、什么響應(yīng)，等等。 四、 注意對(duì)需求方案的可行性和成本預(yù)算進(jìn)行評(píng)審 五、 注意對(duì)需求的質(zhì)量屬性進(jìn)行評(píng)審 我們需要評(píng)審需求規(guī)格說明是否合理地確定了所有的性能目標(biāo)，是否合理地確定了安全性方面要考慮到的問題。 六、 注意對(duì)需求的可實(shí)施性進(jìn)行評(píng)審 是否對(duì)每個(gè)需求都設(shè)置了惟一性并且可以正確地識(shí)別它？是否每個(gè)功能需求都可以跟蹤到高層需求（比如系統(tǒng)需求或用例）? 需求必須可以測試,每個(gè)需求在特定的輸入條件下應(yīng)當(dāng)能給出已知的輸出結(jié)果。同時(shí),需求應(yīng)當(dāng)層次分明,需要把單個(gè)需求下面的相關(guān)需求綜合在一起形成一組需求功能。 需求的可實(shí)施性除了可跟蹤性還包括可測試性。事實(shí)上, 分析人員和測試人員在編寫代碼以前把需求模型,分

5、析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯(cuò)誤的和不必要的需求。軟件需求在概念上的測試是一種很必要的技術(shù)，它可以在項(xiàng)目早期階段發(fā)現(xiàn)需求的歧義和錯(cuò)誤。 七、 注意對(duì)需求包含的用例文檔進(jìn)行評(píng)審 用例是參與者對(duì)系統(tǒng)和參與者的交互過程所達(dá)成的一種契約。需求說明書基于用例的分析方法是也是當(dāng)前較為流行的需求開發(fā)方式。用例文檔作為需求重要的成果性文檔也是需求評(píng)審主體之所在。需求評(píng)審確認(rèn)的重點(diǎn)是對(duì)關(guān)鍵用戶的最常用和最重要的用例進(jìn)行深入和細(xì)致的評(píng)審,首先要通過測試用例的主干過程。而我們是否撰寫有效的用例則要從以下方面著手評(píng)審。 1 用例的目標(biāo)或價(jià)值度量是否明確? 2 用例是否是獨(dú)立的分散任務(wù)? 3 是否明

6、確說明可用用例會(huì)給哪些參與者帶來用處? 4 編寫用例的詳細(xì)程度是否恰當(dāng)?是否有不必要的設(shè)計(jì)和實(shí)現(xiàn)細(xì)節(jié)? 5 所有預(yù)期的分支過程是否都編寫了文檔說明? 6 所有預(yù)估的異常過程是否都編寫了文檔說明? 7 是否存在一些普通的動(dòng)作序列可以分解成獨(dú)立的用例? 8 每個(gè)路徑的步驟是否都清晰明了,無歧義而且完整? 9 用例中的每個(gè)參與者和步驟是否都與所執(zhí)行的任務(wù)有關(guān)? 10 用例中定義的每個(gè)可選路徑是否都可行和可驗(yàn)證? 11用例的前置條件和后置條件是否合理? 分析師必須確認(rèn)用例的前置條件和后置條件準(zhǔn)確界定了用例的邊界范圍,區(qū)分了用例和用例之間的界限。 八、 注意需求評(píng)審會(huì)的過程和結(jié)束標(biāo)準(zhǔn) 需求評(píng)審會(huì)的結(jié)果是

7、對(duì)需求規(guī)格書完成了評(píng)審過程,那我們又如何判斷審查的結(jié)束標(biāo)準(zhǔn)呢?請(qǐng)看如下幾條建議: 1 審查期間評(píng)審員們提出的所有問題都已經(jīng)解決。 2 相關(guān)文檔中的所有更改都已經(jīng)正確完成。 3 修訂過的文檔進(jìn)行了拼寫檢查。 4 所有標(biāo)識(shí)為TBD(待確定)的問題已經(jīng)全部解決, 或者已經(jīng)對(duì)每個(gè)TBD的問題的解決過程、計(jì)劃解決的目標(biāo)日期和責(zé)任解決人等編制了文檔。 5 需求文檔正式進(jìn)入了配置庫。方案二組織和完整性* 所有需求的編寫在細(xì)節(jié)上是否都一致或者合適？* 是否包括了每個(gè)需求的實(shí)現(xiàn)優(yōu)先級(jí)？* 軟件需求規(guī)格說明中是否包括了所有客戶代表或系統(tǒng)的需求？* 是否在需求中遺漏了必要的信息？如果有的話，就把它們標(biāo)記為待確定的問

8、題。* 是否記錄了所有可能的錯(cuò)誤條件所產(chǎn)生的系統(tǒng)行為？正確性* 是否有需求與其它需求相沖突或重復(fù)？* 是否簡明、簡潔、無二義性地表達(dá)每個(gè)需求的？* 是否每個(gè)需求都能通過測試、演示、審查得以驗(yàn)證或分析？* 是否任一個(gè)特定的錯(cuò)誤信息都具有唯一性和明確的意義？質(zhì)量屬性* 是否合理地確定了性能目標(biāo)？* 是否合理地確定了安全與保密方面的考慮？* 在確定了合理的折衷情況下，是否詳實(shí)地記錄了其它相關(guān)的質(zhì)量屬性？可跟蹤性* 是否每個(gè)需求都具有唯一性并且可以正確地識(shí)別它？* 是否可以根據(jù)高層需求（如系統(tǒng)需求或使用實(shí)例）跟蹤到軟件功能需求？特殊的問題* 是否所有的需求都是名副其實(shí)的需求而不是設(shè)計(jì)或?qū)崿F(xiàn)方案？* 是

9、否確定了對(duì)時(shí)間要求很高的功能并且定義了它們的時(shí)間標(biāo)準(zhǔn)？進(jìn)入和退出審查的標(biāo)準(zhǔn)當(dāng)軟件需求文檔滿足特定的前提條件時(shí)，你就可以進(jìn)行需求審查了。這些標(biāo)準(zhǔn)還可以使審查小組避免把時(shí)間浪費(fèi)在審查之前就應(yīng)該解決的問題上。調(diào)解者在決定進(jìn)行審查之前，可以把進(jìn)入審查的標(biāo)準(zhǔn)作為一種清單，并以此作為判斷的標(biāo)準(zhǔn)。* 文檔符合標(biāo)準(zhǔn)模板,并且已經(jīng)做過拼寫檢查和語法檢查。* 在文檔中打印了行序號(hào)以方便在審查中對(duì)特定位置的查閱。* 所有未解決的問題都被標(biāo)記為（待確定）。* 包括了文檔中使用到的術(shù)語詞匯表。相似地，在調(diào)解者宣布審查結(jié)束之前，你應(yīng)該定義所滿足的退出審查的標(biāo)準(zhǔn)。* 已經(jīng)明確闡述了審查員提出的所有問題。* 已經(jīng)正確修改了文

10、檔。* 修訂過的文檔已經(jīng)進(jìn)行了拼寫檢查和語法檢查。* 所有（待確定）的問題已經(jīng)全部解決，或者已經(jīng)記錄下每個(gè)待確定問題的解決過程，目標(biāo)日期和提出問題的人。* 文檔已經(jīng)登記入項(xiàng)目的配置管理系統(tǒng)。評(píng)審形式一需求評(píng)審可以分為正式評(píng)審與非正式評(píng)審，在需求規(guī)格說明書完成后，需求組必須自己對(duì)需求做評(píng)審。如果需求組遞交的需求規(guī)格說明書在指導(dǎo)后面的工作的時(shí)候出現(xiàn)很明顯的錯(cuò)誤，我想拿高工資的需求分析人員是無法向老板交差的。為了需求分析人員的名譽(yù)，他們自己會(huì)對(duì)自己提交的內(nèi)容進(jìn)行審核，直到他們認(rèn)為自己的工作成果足夠好，才會(huì)將需求規(guī)格說明書提交給正式評(píng)審組。    正式評(píng)審組的成員一般由公司內(nèi)經(jīng)驗(yàn)最

11、豐富，技術(shù)最牛的人（技術(shù)總監(jiān)）來擔(dān)任，當(dāng)然參加評(píng)審的人中間還應(yīng)該有項(xiàng)目經(jīng)理、QA人員、測試人員、架構(gòu)師，他們仔細(xì)閱讀需求規(guī)格說明書，并針對(duì)自己將要開展的工作內(nèi)容進(jìn)行檢查，并提出問題    正式評(píng)審是最后一關(guān)，如果正式評(píng)審?fù)ㄟ^了，將進(jìn)入系統(tǒng)設(shè)計(jì)階段，如果在系統(tǒng)設(shè)計(jì)階段再跨里程碑來修改需求的話，所花費(fèi)的代價(jià)將大大增加。因此正式評(píng)審將是一個(gè)“雞蛋里挑骨頭”的過程，只有所有的人都認(rèn)為需求已經(jīng)沒有什么可挑剔評(píng)審才能通過。評(píng)審形式二目的：為了檢查需求的合理性和可實(shí)現(xiàn)性。 參與人員：需求評(píng)審的參與人員主要包括：  -需求提出方：產(chǎn)品經(jīng)理或者第三方  -系統(tǒng)架構(gòu)師：架構(gòu)師可以更好的把握系統(tǒng)架構(gòu)，檢查需求的可實(shí)現(xiàn)性  -開發(fā)工程師：開發(fā)工程師最了解需求實(shí)現(xiàn)難度和是否能實(shí)現(xiàn)  -測試工程師：從測試的角度評(píng)價(jià)需求合理性  -客戶服務(wù)人員：客戶和最終用戶距離最近，對(duì)一般用戶了解較多，因此客服人員可以更好的站在用戶角度考慮問題需求評(píng)審的準(zhǔn)備和進(jìn)行：需求評(píng)審之前，需求提出方最好提前把需求文檔發(fā)給需要參會(huì)的相關(guān)人員， 讓大家有時(shí)間考慮的更深入和