【項目管理知識】軟件需求設計評審須知的8大注意

1、軟件需求設計評審須知的 8 大注意、注意對需求規(guī)格說明的正確性進行評審需求規(guī)格說明的正確性通?？梢詮娜缦路矫娴靡泽w現(xiàn)：是否有需求與其他需求相互沖突或者重復？通常一份長達幾百頁的需求規(guī) 格說明書都不會是一蹴而就的，它可能是系統(tǒng)分析師幾個夜晚的心血之作。正 是因為撰寫過程的連續(xù)性，可能導致同一份文檔中前后名詞定義不一致，前后 觀點上有重疊或差異的情況出現(xiàn)，這需要我們在撰寫報告前首先要在思想上形 成統(tǒng)一概念，可使術語列表貫穿整份文檔以達提綱挈領之效。是否清晰、簡潔、無二義地表達了每個需求？ “清晰 ”是讓人能夠讀懂； “簡 潔”是讓人愿意去讀； “無二義 ”決定”讀”的效果，是讓大家對需求描述的理解

2、能 夠達成一致。需求陳述是 “三重門 ”，這三扇門是否開啟決定了需求說明書的質 量高低。我們尤其要拒絕 “二義性 ”的名詞術語的出現(xiàn)，似是而非的概念定義是 需求書應該避免的。換句話說，如果一份需求說明書沒能給人以清晰、簡潔和 無二義的闡述，則需求評審是沒有進行下去的必要，同時也無法進行下去。需 求評審的前提是用戶讀懂了需求說明，并且用戶的理解內容就是分析師們所描 述的內容。是否每個需求都通過了演示、測試、評審，分析是否得到了驗證？需求應 該是可以測試的，通常通過測試去驗證它是不是正確。比如我們完成了 “銷售員 客戶傭金提成規(guī)則 ”需求的撰寫，如果需求書未能經過原型測試通過，則需求評 審是不能得

3、到通過的。面對相當復雜的業(yè)務需求，經過測試或演示是讓用戶信 任的一個必要過程。試想一下，如果連需求都不能很好地被確認，則開發(fā)實現(xiàn) 階段更是沒有把握控制了。是否每個需求都在項目的范圍內？劃分項目范圍和區(qū)分系統(tǒng)邊界同樣是需 求說明書的一個任務，不要對需求書作出超范圍的論述和延伸，要知道需求書 不是分析師賣弄概念、展示時尚的場所，它是軟件工程的一個重要環(huán)節(jié)。是否每個需求都沒有內容和語法上的錯誤？按照傳統(tǒng)的需求列表方式，需求像菜單一樣被一條條列出來，構成需求項的主要欄位包括：需求ID、需求描述、優(yōu)先級、來源和狀態(tài)等。通常需求首先要經過 “拼寫檢查 ”，保證沒有拼寫 上的問題，然后通過逐行瀏覽修改那些在

4、內容或行文上出現(xiàn)問題的需求。在現(xiàn)有的資源內，是否能實現(xiàn)所有的需求？需求規(guī)格說明要考慮可行性的 問題。事實上，分析師的關注層面是價值驅動和成本驅動方面。分析師應該明白不是所有的需求都要去實現(xiàn)，一些看上去很明顯與涉及用戶有沖突的、費力 不討好的需求應該果斷地舍棄。國內有專家提出，搞需求也要講 “和諧”即是此 中道理。每一條特定的錯誤信息，是否都是一的和具有含義的？不要忽視錯誤信息 的定義，它必須具有一性。如果過于籠統(tǒng)地定義錯誤信息則和沒有定義的效果 是一樣的。二、注意對需求規(guī)格說明的實踐性進行評審所謂實踐性是指需求本身是否來源于目前企業(yè)的相關業(yè)務規(guī)則和文件制 度，而非源于分析師們經驗主義的臆測。實

5、踐性是判斷需求規(guī)格說明是不是理 論聯(lián)系實踐、密切和用戶聯(lián)系的一個關鍵性指標。如果需求規(guī)格說明和用戶實 踐脫離，即使看上去寫得再天花亂墜，也會使需求說明如同無根之樹、無源之 水，會大大減低用戶對需求報告本身的信任度。有經驗的系統(tǒng)分析師通常會迷信自己的經驗，把從前的經驗嫁接到目前的 企業(yè)需求分析中。也許由于行業(yè)性質相同，但如果不經過當前的實踐調研則給出需求，仍然會無法體現(xiàn)出企業(yè)自身的特征。因而不能為企業(yè)帶來真正的價 值，也會造成與用戶需求的鴻溝。也曾經“輕實踐重抽象 ”，我認為系統(tǒng)分析師的工作特點是站在具體案例上 的深度抽象，前提是必須獲得本企業(yè)的一手具體業(yè)務背景、流程和規(guī)則。我們在分析比如 “任

6、務跟蹤 ”之類的系統(tǒng)時，由于系統(tǒng)的抽象模型是已知的通過大量同類軟件的分析得知），但還是需要分析師把抽象模型演繹到企業(yè) 當前業(yè)務現(xiàn)狀。這樣的需求分析才會有 “實話實說 ”之效，才能引發(fā)評審者的共 鳴。否則，在需求評審中評審者是很難讀懂你的意圖，自然不會立即通過你的 需求報告，導致需要重新返工撰寫需求報告。三、注意對需求規(guī)格說明的完整性進行評審我們經常由下面的問題清單來評審需求說明書是否 “完整 ”。1 編寫的所有需求，其詳細程度是否一致和合適？2 需求是否能為設計提供足夠的基礎？3 所有對其他需求的內部引用是否正確？4 是否包含了每個需求的實現(xiàn)優(yōu)先級？5 是否定義了功能說明的內在算法？6 是否包含了所有已知的客戶需求或系統(tǒng)需求？7 是否遺漏了必要的信息？如果有遺漏的話，把他們標記為待確定的問題TBD）？8 是否對所有預期的錯誤條件所產生的系統(tǒng)行為都編制了文檔？需求說明的完整性主要體現(xiàn)在需求說明