【項目管理知識】軟件需求設(shè)計評審八項要點需注意

1、軟件需求設(shè)計評審八項要點需注意1931 年，中共中央代表歐陽欽在向黨中央報告說明中央蘇區(qū)情況時，具體 地說明了紅一方面軍的 “三大紀律八項注意 ”此,后三大紀律八項正式成為了全軍 和地方武裝的紀律。本文所討論的 “八項注意 ”是對于軟件需求設(shè)計評審工作的 一些情況的說明?，F(xiàn)在讓我們把目光聚焦到軟件需求設(shè)計評審上來 ,我們已經(jīng)知道如何去獲取 需求,也知道了撰寫需求規(guī)格說明書?，F(xiàn)在的問題是，我們所撰寫的需求規(guī)格說 明書是否能讓用戶接受呢 ?而用戶又如何對需求說明書作出理性和客觀的評審和 確認呢 ?事實上，當(dāng)我們撰寫需求規(guī)格說明書的時候不妨站在用戶的角度去評 寫，其如此方能事先避免一些問題。本文探討

2、用戶應(yīng)該如何去 “評審 ”軟件需求 說明書，并因此提出了需求評審的 ”八項注意 ”，以饗同仁。需求確認是需求開發(fā)過程的第四個階段 ,前三個階段按順序分別為需求獲 取、需求分析、編寫需求規(guī)格說明。需求確認活動要力圖確保如下幾點1. 需求規(guī)格說明正確描述了預(yù)期的、滿足各方涉眾需求的系統(tǒng)能力和特征。2. 所述之軟件需求是由系統(tǒng)需求、業(yè)務(wù)規(guī)格和其他來源中正確推導(dǎo)而來的。3. 需求是完整和高質(zhì)量的。4.需求的表示在所有地方都是一致的。5.需求為產(chǎn)品設(shè)計和構(gòu)造提供了基礎(chǔ)。需求確認活動可以確保需求符合需求陳述的特征，包括完整、正確、可 行、必要、具有優(yōu)先級、無二義性和可驗證 ,同時亦符合好的需求規(guī)格說明的特

3、 征，即完整性、一致性、易修改和可跟蹤性。般而言，我們通過需求評審活動去實現(xiàn)需求確認的目標 ,參與評審者應(yīng)包括各級客戶、開發(fā)人員和測試人員 ,在整個審查過程中，我們會有諸多 “注意 ”。 事實上 ,在實踐活動中 ,每個企業(yè)會根據(jù)自身的情況存在更多的檢查事項 ,在此列出 的八項亦屬于基本的要素。一、注意對需求規(guī)格說明的正確性進行評審需求規(guī)格說明的正確性通?？梢詮娜缦路矫娴靡泽w現(xiàn)：1 是否有需求與其他需求相互沖突或者重復(fù)？通常一份長達幾百頁的需求規(guī)格說明書都不會是一蹴而就的，它可能是系 統(tǒng)分析師幾個夜晚的心血之作。正是因為撰寫過程的連續(xù)性，可能導(dǎo)致同一份 文檔中前后名詞定義不一致，前后觀點上有重疊

4、或差異的情況出現(xiàn)，這需要我 們在撰寫報告前首先要在思想上形成統(tǒng)一概念 ,可使術(shù)語列表貫穿整份文檔以達 提綱挈領(lǐng)之效。談及此點 ,讓我想起在 “商機管理系統(tǒng) ”需求評審會上，火眼金睛的用戶們發(fā) 現(xiàn)了我的需求說明書中關(guān)于系統(tǒng)用戶角色定義部分出現(xiàn)了前后不一致的情況。在該報告前文中我定義了該系統(tǒng)有二種角色，即 “商機成員”、“商機管理成員 ” 但在功能需求中我的報告中居然新生出一種 “商機監(jiān)理 ”角色，導(dǎo)致出現(xiàn)尷尬局 面。事后總結(jié)其主要原因是在撰寫報告的前期和后期階段 ,需求分析的思路有了 明顯的異動，但卻沒有把文檔前后更新一致，這個教訓(xùn)是深刻的，時至今日記 憶猶新。2 是否清晰、簡潔、無二義地表達了

5、每個需求 ?“清晰”是讓人能夠讀懂； “簡潔”是讓人愿意去讀； “無二義”決定”讀”的效果 , 是讓大家對需求描述的理解能夠達成一致。需求陳述是 “三重門 ”這,三扇門是否開啟決定了需求說明書的質(zhì)量高低。我們尤其要拒絕 “二義性 ”的名詞術(shù)語的出現(xiàn) ,似是而非的概念定義是需求書應(yīng)該避免的。換句話說 ,如果一份需求說明書沒能給人以清晰、簡潔和無二義的闡述，則需求評審是沒有進行下去的必要，同時也無法進行下去。需求評審的前提是用戶讀懂了需求說明 ,并且用戶的理解內(nèi)容就是分析師們所描述的內(nèi)容。3 是否每個需求都通過了演示、測試、評審，分析是否得到了驗證需求應(yīng)該是可以測試的 ,通常通過測試去驗證它是不是

6、正確。比如我們完成了“銷售員客戶傭金提成規(guī)則 ”需求的撰寫 ,如果需求書未能經(jīng)過原型測試通過 ,則需求評審是不能得到通過的。面對相當(dāng)復(fù)雜的業(yè)務(wù)需求 ,經(jīng)過測試或演示是讓用戶信任的一個必要過程。試想一下 ,如果連需求都不能很好地被確認，則開發(fā)實現(xiàn)階段更是沒有把握控制了。4 是否每個需求都在項目的范圍內(nèi) ?劃分項目范圍和區(qū)分系統(tǒng)邊界同樣是需求說明書的一個任務(wù)，不要對需求書作出超范圍的論述和延伸，要知道需求書不是分析師賣弄概念、展示時尚的場所，它是軟件工程的一個重要環(huán)節(jié)。5 是否每個需求都沒有內(nèi)容和語法上的錯誤 ?按照傳統(tǒng)的需求列表方式，需求像菜單一樣被一條條列出來，構(gòu)成需求項的主要欄位包括：需求I

7、D、需求描述、優(yōu)先級、來源和狀態(tài)等。通常需求首先要經(jīng)過 “拼寫檢查 ”，保證沒有拼寫上的問題，然后通過逐行瀏覽修改那些在內(nèi)容或行文上出現(xiàn)問題的需求。6 在現(xiàn)有的資源內(nèi) , 是否能實現(xiàn)所有的需求 ?需求規(guī)格說明要考慮可行性的問題。事實上，分析師的關(guān)注層面是價值驅(qū) 動和成本驅(qū)動方面。分析師應(yīng)該明白不是所有的需求都要去實現(xiàn)，一些看上去很明顯與涉及用戶有沖突的、費力不討好的需求應(yīng)該果斷地舍棄。國內(nèi)有專家 提出，搞需求也要講 “和諧 ”即是此中道理。舉例而言，企業(yè)中的用戶可分為三種類型：決策層用戶、管理層用戶、操 作層用戶。每種用戶所代表的價值取向是不同的，決策和管理層希望系統(tǒng)處理 業(yè)務(wù)是業(yè)務(wù)安全優(yōu)先的，而操作系統(tǒng)用戶則是更多地考慮方便性的。國內(nèi)某電 子貿(mào)易公司，從自身業(yè)務(wù)安全考慮，規(guī)定了系統(tǒng)不允許 “借貨 ”意,即代理商的產(chǎn) 品直接