摘要:需求開發的質量嚴重影響著軟件產品的質量。而許多組織的需求質量較大程度依賴于需求開發人員的經驗和能力,缺少對需求調研方法的指導。文章描述了需求調研準備以及需求篩選的方法,為需求開發人員提供了參考。
關鍵詞:需求開發;鍍金需求;需求質量
一、前言
軟件企業日益關注到產品質量對項目成本及時間等方面的巨大影響,逐漸強調軟件開發過程中的質量管理體系的建立。戴明的質量觀點是“質量必須從客戶的觀點出發加以考慮”以及“質量是從客戶的觀點出發加強到產品上的東西”;Crosby認為質量是“與需求的一致性”。根據兩者的觀點,對于軟件產品而言,質量就是對客戶需求的滿足情況。
然而客戶需求不等同于“客戶認為他們需要的”。Young對于需求的定義是“為了使系統能為用戶提供實用價值而對其必須的屬性、能力及特征的定義”。在現實中,需求分析人員經常遇到的挑戰之一就是客戶對于真正的需求并不了解,無法清晰描述真正的需求,進而導致了需求人員對用戶真正意圖的誤解以及加入了“鍍金需求”,最終造成了項目的范圍頻繁變更,成本及工期急劇增加。
本文的目的在于探索提高軟件需求開發質量的方法,針對如何進行調研準備及篩選需求提出相關看法,為需求分析人員提供參考。
二、確定項目背景范圍
既然軟件質量關注產品與客戶需求的一致性,在深入了解客戶需求之前,需求分析人員應該明確“誰是客戶”以及與客戶有關的人員。在確定了客戶及相關人員后,需要嘗試了解其目的及偏好,為項目具體的需求平衡取舍提供決策基礎。最后,確定最終產品的范圍并在整個項目期間進行正式的管理。
(一)涉眾(Stakeholder)
所謂客戶,既有責任驗收產品或支付費用的一群人(個人、項目或組織)。需求分析人員總是以“客戶”稱呼所有服務對象,從而容易忽略了客戶內部的關系。實際上在許多組織(特別是大型組織),存在著組織內部由于相互獨立,不能實現協同化管理,互相競爭,另外縱向和橫向溝通渠道不暢,資源和信息不流通等問題。需求人員可以首先了解組織架構,并且根據以往的經驗判斷客戶內部的矛盾及聯系,之后再通過進一步調研了解客戶個人的習慣、喜好及性格。客戶通常由于不了解相關技術及其需求,在需求調研時隨意地提出各種需求,而在產品開發階段也可能隨時變更需求,這對產品的穩定性以及項目成本常常造成嚴重的影響。因此,了解客戶內部關系及個人特征,有利于需求分析人員在隨后的需求調研中正確了解客戶需求并做出正確地需求決策。
除了管理客戶以外,需求分析人員還需要關注與項目及產品相關的組織及個人。通常我們將受到一項任務所造成結果影響,或需要從某種程度上對其負責的個人或團體成為涉眾(Stakeholder)。我們可以借助以下的層次劃分了解產品相關的涉眾:
1、操作/運營領域。該領域的涉眾是直接經常使用產品的內部人員,例如網站管理系統的維護人員。在需求調研時需要關注其能力及操作習慣,例如文化水平以及是否有相似系統的操作經歷等。
2、業務領域。通常情況下,業務領域的涉眾為系統提供了高層次的業務需求,是系統的功能受益人。需求調研時應該關注涉眾的目的以及對產品投資回報率的期望。
3、外部環境。許多產品的服務對象不只是組織內部,可能涉及外部的使用者,例如銀行ATM。由于外部使用者的不確定性,在需求調研時需要對外部人員進行恰當地分類,以獲得有效的需求。
(二)目標(Goal)
確定了涉眾后,我們需要確定他們的目標。可以將目標理解為涉眾為什么需要這個產品、希望從這個產品獲得何好處、期望產品以什么方式運行等。由于涉眾對于目標的理解各不相同,并且以不同的方式表達,所以需求分析人員可以通過統一的方法記錄各涉眾的目的。
James Robertson將其成為PAM方法,即P(Purpose):對于系統的目的或高層需求。A(Advantage):系統對于組織或個人的好處。M(Measurement):盡可能地量化產品的效果。
例如1個電話客服管理系統的PAM可能是:P——通過系統管理客服人員的工作情況;A——降低客戶投訴率;M——使客戶投訴率降低20%。
對于涉眾目標的準確理解同時有助于我們對需求的平衡及取舍。
(三)范圍(Scope)
對于軟件開發而言,范圍是應該注意的最重要的變量。產品范圍實際上包含兩層意思,即產品的功能范圍及產品與外部的界限。
1、產品功能范圍。產品的功能范圍可以看作高層次的功能性需求。對于功能性的需求,通常的做法是通過建立高層次的產品分解結構(Product Breakdown Structure),與涉眾就產品范圍達成共識。但是由于僅限定了產品需要完成的工作范圍,未能阻止需求的逐漸蔓延,容易造成涉眾在產品開發的階段不斷增加新的特性,導致鍍金需求的產生。所以,準確說明產品不完成哪些功能與需要完成哪些功能同樣重要,為需求的穩定提供了一定保障。產品功能范圍實際對于項目范圍有巨大的影響。而項目的范圍、成本、進度以及質量是緊密相聯的變量,確定其中的3個變量后,第4個變量的區間也隨之確定。同時產品范圍也是一個變化很大的變量,特別是在客戶不成熟以及產品規模較大的情況下。因此,當產品范圍難以確定時,可以考慮與涉眾限定產品開發的成本、進度以及質量,而令范圍成為在開發過程中根據實際情況“活動”的變量。
2、產品與外部界限。產品一般通過接口與外部系統進行交互。使一個系統與另外一個系統配合是一項耗時而且不可預測的工程。開發人員可能不知道實現一個特定的接口將有多么的困難,直到他們真正開始著手去做。如果我們在使用別人定義的接口,它可能不能準確地完成我們的目標,或者不像我們所想象的;如果我們自己設計接口,我們依賴其他系統正確地實現它。因此,我們需要確定每一個接口是完全屬于內部的還是外部的,或者還未明確所屬的。
在接口所有權選擇上,我們通常面臨著一次權衡。自己定義接口時,能夠確保接口能夠滿足內部的需要,并且能夠以最好的方式支持系統的工作,但是需要負責完成所有困難的接口定義工作,并且要向外部人員解釋使用方法。而把定義接口工作交由外部完成時,可能不得不使用質量低下的接口,并且面臨沒有文檔和對接口熟悉的技術人員的困境。更重要的是,當外部提供的接口發生變更時,內部系統不得不隨之調整,而且外部對內部提出的接口變更請求反應遲緩。
(四)SGS循環
實際工作中,很難一次性準確地發現所有的涉眾,獲得所有涉眾的目標并確定產品范圍。更多的情況是,在確定一部分涉眾后,通過了解其目標及對產品范圍的理解,發現更多的涉眾,進而獲得更多的目標及產品范圍。另外,在目標及范圍定義時,可能遇到各涉眾理解不一致,產生矛盾的情況,這時需要需求開發人員在涉眾間進行協調與溝通,這個階段投入的工作是有價值的,避免系統開發后期,由于頻繁變更引起更大的成本投入。
三、需求篩選
通過各種方式了解客戶需求后,需求人員會整理相關信息形成涉眾的原始需求。但是原始需求不等同于產品開發的目標需求,并不是涉眾提出的所有需求都要滿足,因為可能各需求間存在矛盾,某些需求并不是涉眾真正需要的。CMMI for Development Version 1.2模型中的需求開發過程域中,SP 3.3分析需求中強調了“確保需求的必要性”。某些組織使用需求優先級的方法實現需求篩選。根據需求開發人員以及(或者)涉眾對需求優先級的判斷,將所有需求根據需求優先級進行排序。這種方法主觀性較大,并且可能由于需求開發人員及涉眾考慮問題的角度不同,導致對優先級無法達到一致。
我們可以使用客戶價值的方法對需求進行篩選。即對于每一個需求,分析兩個參數:實現該需求后客戶的滿意程度以及不實現該需求后客戶的不滿意程度。這種方法降低了主觀性對判斷的影響,并且促使需求開發人員及涉眾對需求必要性的思考,避免了鍍金需求在最終需求出現的可能性。
四、結論
越來越多的組織認識到了需求質量對軟件產品質量的影響,嘗試通過需求評審等方法提高質量。但是在需求的源頭——需求開發方面沒有提供有效的方法,更多地依賴個人的能力及經驗。本文建議在需求調研前期使用SGS循環的方法明確產品的涉眾、目標及范圍,確保需求人員對產品的總體情況獲得清晰的了解,為具體的需求調研提供決策所需的重要信息。另外,還建議組織采用客戶價值的方法對涉眾的原始需求進行分析,確保所有的需求對于涉眾都是有價值和必要的,避免開發團隊為不必要的功能花費成本。
(作者單位:廣州賽寶認證中心)