軟件需求評審之道

摘要

本文介紹了軟件需求評審失敗的5個案例，提出對軟件需求評審的實踐具有指導意義的9個建議。

關鍵詞

需求評審，需求層次，階段評審，檢查單，評審流程

軟件需求是軟件開發的最重要的一個輸入，需求風險也常常是軟件開發過程中最大的一個風險，降低需求風險的一個重要手段就是需求評審，但是需求評審是所有的評審活動中最難的一個，也是最容易被忽視的一個評審。筆者曾經歷過以下的幾種失敗的需求評審：

案例一

某領域專家A先生就某企業的成本管理系統做用戶需求報告的評審工作，在評審會開始時間不長，就被在場的企業的一位副總B先生打斷，認為A先生提出的方案不適合本企業，A先生提出的管理改進方案在企業中無法實施。該副廠長提完意見后，與會的用戶方人員紛紛跟隨B先生的提出了他們的反對意見，致使評審會無法再進行下去，最終該報告被用戶否決。

案例二

某軟件公司內部舉行產品的需求評審會，主要是公司內部的領域專家參加，在評審會開始后不久，某領域專家就對需求報告中的某個具體問題提出了自己的不同意見，于是，與會人員紛紛就該問題發表自己的意見，大家爭執不下，結果，致使會議出現了混亂狀況，主持人無法控制局面，會議大大超出了計劃評審時間。

案例三

某軟件公司為某公司A做業務流程管理系統的需求評審會，當項目組人員在會議上宣讀多達上百頁的需求報告時，用戶明確提出聽不懂，致使會議不得不改日進行。

案例四

某軟件公司在用戶處開完物資管理系統的需求評審會后，與會人員離開會議室時，紛紛搖頭，認為本次會議沒有多少實際效果，完全是在走過場。

案例五

某軟件公司在公司內部舉行產品的需求評審會時，需求報告的執筆人與產品策劃主要策劃人員的想法差別很大，致使需求評審會沒有必要繼續進行下去。

以上的現象可以在很多項目中都可以看到。概括起來，在需求評審中常見的問題是：

◇ 需求報告很長，短時間內評審者根本就不能把需求報告讀懂，想清楚；

◇ 沒有作好前期準備工作，需求評審的效率很低；

◇ 需求評審的節奏無法控制；

◇ 找不到合格的評審員，與會的評審員無法提出深入的問題；

……

那么究竟如何做好需求評審呢？

建議一：分層次評審

我們知道用戶的需求是可以分層次的，一般而言可以分成如下的層次：

目標性需求：定義了整個系統需要達到的目標；

功能性需求：定義了整個系統必須完成的任務；

操作性需求：定義了完成每個任務的具體的人機交互；

目標性需求是企業的高層管理人員所關注的，功能性需求是企業的中層管理人員所關注的，操作性需求是企業的具體操作人員所關注的。對不同層次的需求，其描述形式是有區別的，參與評審的人員也是不同的。如果讓具體的操作人員去評審目標性需求，可能會很容易地導致“撿了芝麻，丟了西瓜”的現象，如果讓高層的管理人員也去評審那些操作性需求，無疑是一種資源的浪費或者就會出現案例三的情形。

建議二：正式評審與非正式評審結合

正式評審是指通過開評審會的形式，組織多個專家，將需求涉及到的人員集合在一起，并定義好參與評審人員的角色和職責，對需求進行正規的會議評審。而非正式的評審并沒有這種嚴格的組織形式，一般也不需要將人員集合在一起評審，而是通過電子郵件、文件匯簽甚至是網絡聊天等多種形式對需求進行評審。2種形式各有利弊，但往往非正式的評審比正式的評審效率更高，更容易發現問題。因此在評審時，應該更靈活地利用這2種方式。

建議三：分階段評審

應該在需求形成的過程中進行分階段的評審，而不是在需求最終形成后再進行評審。分階段評審可以將原本需要進行的大規模評審拆分成各個小規模的評審，降低了需求返工的風險，提高了評審的質量。比如可以在形成目標性需求后進行一次評審，在形成系統的初次概要需求后進行一次評審，當對概要需求細分成幾個部分，對每個部分進行各個評審，最終再對整體的需求進行評審。

建議四：精心挑選評審員

需求評審可能涉及的人員包括：需方的高層管理人員、中層管理人員、具體操作人員、IT主管、采購主管；供方的市場人員、需求分析人員、設計人員、測試人員、質量保證人員、實施人員、項目經理以及第三方的領域專家等等。在這些人員中由于大家所處的立場不同，對同一個問題的看法是不相同的，有些觀點是和系統的目標有關系的，有些是關系不大的，不同的觀點可能形成互補的關系。為了保證評審的質量和效率，需要精心挑選評審員。首先要保證使不同類型的人員的都要參與進來，否則很可能會漏掉了很重要的需求。其次在不同類型的人員中要選擇那些真正和系統相關的，對系統有足夠了解的人員參與進來，否則很可能使評審的效率降低或者最終不切實際的修改了系統的范圍。

建議五：對評審員進行培訓

在很多情況下，評審員是領域專家而不是進行評審活動的專家，他們沒有掌握進行評審的方法、技巧、過程等，因此需要對評審員進行，同樣對于主持評審的管理者也需要進行培訓，以便于參與評審的人員能夠緊緊圍繞評審的目標來進行，能夠控制評審活動的節奏，提高評審效率，避免發生案例一和案例二中出現的現象。對評審員的培訓也可以區分為簡單培訓與詳細培訓2種。簡單培訓可能需要十幾分鐘或者幾十分鐘，需要將在評審過程中的需要把握的基本原則，需要注意的常見問題說清楚。詳細培訓則可能要需要對評審的方法、技巧、過程進行正式的培訓，需要花費較長的時間，是一個獨立的活動。需要注意的是被評審人員也要被培訓。

建議六：充分利用需求評審檢查單

需求檢查單是很好的評審工具，需求檢查單可以分成2類：需求形式的檢查單和需求內容的檢查單。需求形式的檢查可以由QA人員負責，主要是針對需求文擋的格式是否符合質量標準來提出的，需求內容的檢查是由評審員負責的，主要是檢查需求內容是否達到了系統目標、是否有遺漏、是否有錯誤等等，這是需求評審的重點。檢查單可以幫助評審員系統全面地發現需求中的問題，檢查單也是隨著工程財富的積累逐漸豐富和優化的。

建議七：建立標準的評審流程

對正規的需求評審會需要建立正規的需求評審流程，按照流程中定義的活動進行規范的評審過程。比如在評審流程定義中可能規定評審的進入條件，評審需要提交的資料，每次評審會議的人員職責分配，評審的具體步驟，評審通過的條件等等。通過評審流程執行可能會避免出現案例五之類的問題。

建議八：做好評審后的跟蹤工作

在需求評審后，需要根據評審人員提出的問題進行評價，以確定哪些問題是必須糾正的，哪些可以不糾正，并給出充分的客觀的理由與證據。當確定需要糾正的問題后，要形成書面的需求變更的申請，進入需求變更的管理流程，并確保變更的執行，在變更完成后，要進行復審。切忌評審完畢后，沒有對問題進行跟蹤，而無法保證評審結果的落實，使前期的評審努力付之東流。

建議九：充分準備評審

評審質量的好壞很大程度上取決于在評審會議前的準備活動。常出現的問題是，需求文檔在評審會議前并沒有提前下發給參與評審會議的人員，沒有留出更多更充分的時間讓參與評審的人員閱讀需求文檔。更有甚者，沒有執行需求評審的進入條件，在評審文檔中存在大量的低級的錯誤或者沒有在評審前進行溝通，文檔中存在方向性的錯誤，從而導致評審的效率很低，質量很差。對評審的準備工作，也應當定義一個檢查單，在評審之前對照檢查單落實每項準備工作。

在實踐中細心體會、實施上述的9個建議，相信您定會受益非淺。

原文轉自：http://www.anti-gravitydesign.com