【IT168 專稿】1931年，中共中央代表歐陽欽在向黨中央報告說明中央蘇區情況時，具體地說明了紅一方面軍的“三大紀律八項注意”, 此后三大紀律八項正式成為了全軍和地方武裝的紀律。本文所討論的“八項注意”是對于軟件需求設計評審工作的一些情況的說明。
現在讓我們把目光聚焦到軟件需求設計評審上來, 我們已經知道如何去獲取需求,也知道了撰寫需求規格說明書�，F在的問題是，我們所撰寫的需求規格說明書是否能讓用戶接受呢? 而用戶又如何對需求說明書作出理性和客觀的評審和確認呢? 事實上，當我們撰寫需求規格說明書的時候不妨站在用戶的角度去評寫，唯其如此方能事先避免一些問題。本文探討用戶應該如何去“評審”軟件需求說明書，并因此提出了需求評審的”八項注意”，以饗同仁。
需求確認是需求開發過程的第四個階段,前三個階段按順序分別為需求獲取、需求分析、編寫需求規格說明。需求確認活動要力圖確保如下幾點:
1.需求規格說明正確描述了預期的、滿足各方涉眾需求的系統能力和特征。
2.所述之軟件需求是由系統需求、業務規格和其他來源中正確推導而來的。
3.需求是完整和高質量的。
4.需求的表示在所有地方都是一致的。
5.需求為產品設計和構造提供了基礎。
需求確認活動可以確保需求符合優秀需求陳述的特征，包括完整、正確、可行、必要、具有優先級、無二義性和可驗證, 同時亦符合好的需求規格說明的特征，即完整性、一致性、易修改和可跟蹤性。
一般而言，我們通過需求評審活動去實現需求確認的目標, 參與評審者應包括各級客戶、開發人員和測試人員, 在整個審查過程中，我們會有諸多“注意”。事實上,在實踐活動中,每個企業會根據自身的情況存在更多的檢查事項, 在此列出的八項亦屬于最基本的要素。
一、 注意對需求規格說明的正確性進行評審
需求規格說明的正確性通�？梢詮娜缦路矫娴靡泽w現：
1、是否有需求與其他需求相互沖突或者重復？
通常一份長達幾百頁的需求規格說明書都不會是一蹴而就的，它可能是 系統分析師幾個夜晚的心血之作。正是因為撰寫過程的連續性，可能導致同一份文檔中前后名詞定義不一致，前后觀點上有重疊或差異的情況出現，這需要我們在撰寫報告前首先要在思想上形成統一概念, 可使術語列表貫穿整份文檔以達提綱挈領之效。
談及此點,讓我想起在“商機管理系統”需求評審會上，火眼金睛的用戶們發現了我的需求說明書中關于系統用戶角色定義部分出現了前后不一致的情況。在該報告前文中我定義了該系統有二種角色，即“商機成員”、“商機管理成員”,但在功能需求中我的報告中居然新生出一種“商機監理”角色，導致出現尷尬局面。 事后總結其主要原因是在撰寫報告的前期和后期階段,需求分析的思路有了明顯的異動，但卻沒有把文檔前后更新一致，這個教訓是深刻的，時至今日記憶猶新。
2、是否清晰、簡潔、無二義地表達了每個需求?
“清晰”是讓人能夠讀懂；“簡潔”是讓人愿意去讀；“無二義”決定”讀”的效果,是讓大家對需求描述的理解能夠達成一致 。
需求陳述是“三重門”,這三扇門是否開啟決定了需求說明書的質量高低。
我們尤其要拒絕“二義性”的名詞術語的出現, 似是而非的概念定義是需求書應該避免的。換句話說,如果一份需求說明書沒能給人以清晰、簡潔和無二義的闡述，則需求評審是沒有進行下去的必要，同時也無法進行下去。需求評審的前提是用戶讀懂了需求說明,并且用戶的理解內容就是分析師們所描述的內容。
3、是否每個需求都通過了演示、測試、評審，分析是否得到了驗證?
需求應該是可以測試的,通常通過測試去驗證它是不是正確。比如我們完成了“銷售員客戶傭金提成規則”需求的撰寫,如果需求書未能經過原型測試通過,則需求評審是不能得到通過的。 面對相當復雜的業務需求,經過測試或演示是讓用戶信任的一個必要過程。試想一下, 如果連需求都不能很好地被確認，則開發實現階段更是沒有把握控制了。
4、是否每個需求都在項目的范圍內?
劃分項目范圍和區分系統邊界同樣是需求說明書的一個任務，不要對需求書作出超范圍的論述和延伸，要知道需求書不是分析師賣弄概念、展示時尚的場所，它是 軟件工程的一個重要環節。
5、是否每個需求都沒有內容和語法上的錯誤?
按照傳統的需求列表方式，需求像菜單一樣被一條條列出來，構成需求項的主要欄位包括：需求ID、 需求描述、優先級、來源和狀態等。 通常需求首先要經過“拼寫檢查”，保證沒有拼寫上的問題，然后通過逐行瀏覽修改那些在內容或行文上出現問題的需求。
6、在現有的 資源內, 是否能實現所有的需求?
需求規格說明要考慮可行性的問題。事實上，分析師的關注層面是價值驅動和成本驅動方面。分析師應該明白不是所有的需求都要去實現，一些看上去很明顯與涉及用戶有沖突的、費力不討好的需求應該果斷地舍棄。國內有專家提出，搞需求也要講“和諧”即是此中道理。
舉例而言，企業中的用戶可分為三種類型：決策層用戶、管理層用戶、操作層用戶。每種用戶所代表的價值取向是不同的，決策和管理層希望系統處理業務是業務安全優先的，而 操作系統用戶則是更多地考慮方便性的。國內某電子貿易公司，從自身業務安全考慮，規定了系統不允許“借貨”,意即代理商的產品直接發到客戶根本不經過本貿易公司的物流部門。如果操作層用戶提出了這樣的“借貨”需求,倒是可以方便他的日常處理,但卻違背了公司的根本利益。很顯然，這樣的需求肯定是有所不為的。
7、每一條特定的錯誤信息，是否都是唯一的和具有含義的?
不要忽視錯誤信息的定義, 它必須具有唯一性。如果過于籠統地定義錯誤信息則和沒有定義的效果是一樣的。
二、 注意對需求規格說明的實踐性進行評審
所謂實踐性是指需求本身是否來源于目前企業的相關業務規則和文件制度,而非源于分析師們經驗主義的臆測。實踐性是判斷需求規格說明是不是理論聯系實踐、密切和用戶聯系的一個關鍵性指標。如果需求規格說明和用戶實踐脫離,即使看上去寫得再天花亂墜,也會使需求說明如同無根之樹、無源之水,會大大減低用戶對需求報告本身的信任度。
有經驗的系統分析師通常會迷信自己的經驗,把從前的經驗嫁接到目前的企業需求分析中。也許由于行業性質相同,但如果不經過當前的實踐調研則給出需求，仍然會無法體現出企業自身的特征。因而不能為企業帶來真正的價值,也會造成與用戶需求的鴻溝。
筆者也曾經“輕實踐重抽象”，我認為系統分析師的工作特點是站在具體案例上的深度抽象，前提是必須獲得本企業的一手具體業務背景、流程和規則。
我們在分析比如“任務跟蹤”之類的系統時，由于系統的抽象模型是已知的(通過大量同類軟件的分析得知)，但還是需要分析師把抽象模型演繹到企業當前業務現狀。這樣的需求分析才會有“實話實說”之效,才能引發評審者的共鳴。否則，在需求評審中評審者是很難讀懂你的意圖，自然不會立即通過你的需求報告，導致需要重新返工撰寫需求報告。
這使我想到毛主席當年倡導“理論聯系實際”的深刻內涵。任何時刻,我們都要記住一個原則，即密切聯系用戶。誠然，需求分析需要方法也要理論支持,但最關鍵點仍然在于它本身是一種實踐,需求分析實踐直接來源于和用戶的直接 溝通和互動。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
