需求管理中數據和信息的關系及應用

                                                                                              需求管理中數據和信息的關系及應用
   

 

本文從需求管理的角度，對需求管理中數據和信息的關系進行分析，并將之結合應用到軟件的需求分析和管理活動中。本文同時還介紹了如何運用 IBM Rational RequisitePro 進行需求管理。需求術語的概覽

什么是需求？什么是需求分析？什么是需求跟蹤？什么是需求獲??？什么是需求規格？什么是需求驗證？什么是需求變更？……一堆關于需求的問題，一堆關于需求和需求管理的惱人問題，需求真的很重要嗎？那為什么如此難以把握？為什么在軟件工程中如此難以應用呢？

您作為從事項目開發，尤其是軟件項目開發的負責人，需求分析師，系統架構師，程序員，測試人員，維護人員，項目的使用者，只要您是項目開發和應用中的一位成員，您一定思考過上述的問題，或許您曾為此問題曾經與人激烈討論過，或許您已經疲于爭論已經在實際的項目中應用您的認識和體會了。

上述這些話，在 IBM 或者軟件行業協會舉辦的需求管理講座上，我以 IBM Rational 產品講師的身份曾經多次詢問過客戶和聽眾，他們每每給予我的回應除了無奈的笑之，就是帶著期許的眼光等待著我給出回答。

什么是需求

對于第一個問題：什么是需求？很多需求專家和權威機構已經給出了他們的描述，為什么是描述而不是定義呢？“因為軟件產業存在的一個問題就是缺乏統一定義的名詞術語來描述我們的工作?？蛻羲x的“需求”對于開發者似乎是一個較高層次的產品概念。而開發人員所說的“需求”對用戶來說又象是詳細設計了。實際上，軟件需求包含著多個層次，不同層次需求從不同角度與不同程度反映著細節問題：

---IEEE 軟件工程標準詞匯表（1997）中需求為：

（1）用戶解決問題或達到目標所需的條件或能力

（2）系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或能力

（3）一種反映上面（1）或（2）所描述的條件或能力的文檔說明?！?/P>

---Jones 認為“需求是用戶所需要的并能觸發一個程序或系統開發工作的說明 ----（Jones 1994）”

---Alan 認為“從系統外部能夠發現系統所具有的滿足于用戶的特點、功能及屬性等 ----（Alan Davis 1993）”

---S&S 認為“需求是指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束 ----（Sommerville and Sawyer 1997）”

所以引出上述這些描述，是因為我們仔細閱讀上述權威機構和專家的描述，可以發現，他們分別從用戶，從系統，從系統部件，從作用，從實現等不同方面對需求進行了闡述，至少通過上述的描述我們可以知道，需求基于不同的立場和角度是可以有不同的理解的，這也是為什么總是會有人針對什么是需求喋喋不休的爭論，而最終誰也無法說服誰的場景在軟件開發過程中層出不窮的原因。那么誰會對需求有不同的立場和角度呢？干系人，同項目或者系統有關的干系人（Stakeholder），前文我們提到的軟件項目開發的負責人，需求分析師，系統架構師，程序員，測試人員，維護人員，項目的使用者等等，這些都是需求的干系人，因為有干系人的存在，就會有基于不同立場和角度的需求認識，這樣就會形成不同類型的需求，因此當我們在探討什么是需求時，我建議大家不要忘了思考我們正在針對何種類型的需求在進行探討，探討的目的是什么。

至此如果我們接受了從需求分類的角度考慮什么是需求。那么什么是需求分析？什么是需求跟蹤？什么是需求獲??？什么是需求規格？什么是需求驗證？什么是需求變更？……也就是我們該如何理解并組織這些需求活動和術語呢？

需求術語的組織結構

對于第二個問題，如何理解和組織眾多需求術語和活動。本文借鑒需求管理專家 Wiegers 在《Software Requirements》一書中對于這些需求活動和概念的描述與分類，如下圖所示：

圖 1. 需求術語組織圖

需求工程：需求開發和管理的過程。它包括了需求開發和需求管理兩個部分。

需求開發：是指從問題獲取、分析判斷到編寫規格說明文檔、評審驗證等一系列產生需求的活動。這些活動在需求開發中是相互獨立和可以反復出現的。

問題獲?。盒枨蟮氖占?、分析、細化、核實并組織的步驟，該活動包括干系人分類，篩選典型客戶代表，組建需求團隊，召開會議，判斷需求質量屬性等多項具體內容。

分析：根據需求獲取中得到的需求文檔，分析系統實現方案。具體的方法包括：魚刺圖，上下文關系圖，用例圖等分析方法。

編寫規格說明：需求開發的最終成果是客戶和開發小組對將要開發的產品達成一致協議，這一協議就是通過文檔化的需求規格說明書來體現。對于不同類型的需求可以有不同的規格說明相對應，例如所常見的用戶需求，業務需求等。

驗證：確保需求說明準確、完整，表達必要的質量特點，需求將要作為系統設計和最終驗證的依據，因此一定要保證它的正確性。需求驗證務必確保符合完整性、正確性、靈活性、必要性、無二義性、一致性、可跟蹤性及可驗證性這些良好特征。

需求管理：是計劃、組織、指導和控制需求的系統方法，也是指軟件項目開發過程中控制和維護需求約定的活動，通常包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作。

版本控制：版本控制是需求管理的一個必要方面，需求文檔的每個版本必須統一確定。以保證每個成員可以準確地得到需求的當前版本，并了解需求文檔每個版本的修改原因和結果。

需求跟蹤：是指跟蹤一個需求使用期限的全過程，需求跟蹤包括編制每個需求同系統元素之間的聯系文檔，這些元素包括其他類型的需求，體系結構，其他設計部件，源代碼模塊，測試，幫助文件等。需求跟蹤為我們提供了由需求到產品實現整個過程范圍的明確查閱的能力。

需求狀態跟蹤：不同類型的需求都有不同的需求狀態相對應作為需求優先級劃分標準的補充說明，通過需求狀態跟蹤能夠確保需求按照優先級先后實現的完整性。

變更控制：變更控制給項目風險承擔者提供了正式的建議需求變更處理機制，通過變更處理機制需求的決策人可以準確地分析需求變更所帶了的影響和波動，從而決判斷是否接受、拒絕或者延遲需求變更，最終準確控制項目開發范圍。

至此，我們了解了應如何理解和組織眾多需求術語和活動。但是也有許多人看到這里會認為這又是一篇堆砌了很多術語介紹的文章，晦澀而難以應用。其實不然，本文重點論述的就是 --- 通過數據和信息的關系理解需求管理在變更管理中的重要性。為什么有此想法和立意呢？

我在拜訪很多軟件開發企業的時候發現大多數軟件開發團隊都已經有了成熟的變更管理概念和管理基礎，已經能夠將變更管理到位了，于是他們就想進一步管理需求，但是不久就會發現從很多書本或者權威的書籍中得到的需求管理的理論，往往向我上面介紹的術語那樣大而全，但是確苦于無從下手，擔心需求管理同變更管理結合使用的學習成本太高并且風險太大，最終不了了之，很多軟件開發企業和團隊只能繼續忍耐由于需求變更所帶來的項目延期或者利潤下降的噩夢。

那么我們可以怎樣使用需求管理呢？我們首先從一個生活中的小例子介紹。

需求管理過程中的數據和信息的關系

想看小例子了？看例子之前先讓我們再了解兩個必須的術語定義 --- 數據和信息：

數據：數據是可定義為意義的實體，它涉及到事物的存在形式，是關于事件的一組離散的客觀的事實描述，是構成信息和知識的原始材料。在軟件開發過程中，所管理的很多文檔，例如：項目可行性報告、需求規格說明書、概要設計說明書等都可以看作需求管理中的數據。

信息：信息是一種消息，通常以文字或聲音、圖象的形式來表現，是數據按有意義的關聯拓撲結構的結果。在軟件開發過程中，所管理的很多文檔中針對不同的數據條目通常附有相關的說明，這些說明起到的就是信息的作用。

也許上述晦澀的定義不易理解二者之間的關系，我們這就看看下面的小例子，然后再來解讀我們是如何潛移默化的應用二者的。

有趣的小例子 - 門牌號

生活中的場景分析

背景

話說某天 IBM 北京 Rational 部門的銷售人員小鮑告訴我第二天中午 2：00 到上海漕寶 路 99 號拜訪一位客戶，主要目的是介紹 Rational 大名鼎鼎的需求管理工具 RequisitePro，我答應了。

第二天上午坐飛機由北京飛到上海，出了機場打車直奔客戶處。上車后同司機說去漕寶路 99 號，可是司機只知道漕寶路不知道 99 號在哪里？看來只能到了漕寶路再自己找了。

剛到漕寶路上，突然接到客戶電話聲稱因其公司有重要的會議挪到 2：00 點鐘開，因此希望將我們的會面提前到 1：30 開始，問我可以嗎？

情景

不知道您會如何處理這件事情呢？

也許您會說客戶是上帝，客戶是甲方，只能同意。

也許您會說沒關系我可以等您，您先開會吧。

也許您會想：“我還不知道我在哪里呢，怎么回答客戶呀”

看到這里，也許您會想現在什么時間？離那里多遠？我需要先知道這些才能回答呀。

那么讓我來告訴您我是怎么處理的：

步驟 1:首先讓客戶掛機稍等。然后直接給我們的銷售人員小鮑，告知情況，征詢如何處理。小鮑此時有另外的事情正在忙碌，讓我自己看著辦。

步驟 2:判斷我現在在哪里。參見圖 3 ，從車窗可以看到我現在正在漕寶路 139 號和 137 號之間。

步驟 3:看表?，F在 1：10，距離客戶要求的 1：30 還有 20 分鐘。

圖 2. 門牌號圖一門牌號

圖 3. 步驟 3 之前的分析場景

圖 2顯示我腦海中的門牌號也就是目的地，圖 3 給出了路況，我們可以判斷距離客戶公司應該還有 20 個商戶，具體多遠不知道，但是應該不遠了，所以在圖 2 中給出了兩個虛線框出的 99 號來標示客戶公司大概的位置，那么經過步驟 1-3 的分析是否有讀者認為我們可以告訴客戶我們可以在 1：30 趕到客戶公司進行產品介紹了呢？

那么讓我們繼續看看我下面的步驟，參見圖 4 ：

步驟 4:繼續觀察路況，發現堵車。怎么辦？方法一：要是開飛經就好了，肯定沒問題，可惜不會開飛機，而且也沒有飛機，妄想；方法二：要是能象警察辦理緊急公務那樣可以同路人借摩托車就好了，可惜不是警察，做夢；方法三：實在不成我可以走路過去，因為不太遠，最笨但是最可控的方法。

步驟 5:繼續觀察路況，當前正中午，夏天天氣炎熱，漕寶路兩邊樹木稀少。如果步行，不僅自己被暴曬不舒服而且由于行路匆匆，很可能大汗淋淋感到客戶公司，最終雖然克服了困難拼命滿足客戶的變更要求，但很有可能被客戶投訴儀表不莊。

步驟 6:繼續觀察路況，需要穿過至少 2 個路口才有可能到達客戶公司。步行不僅天氣炎熱，而且車來車往非常危險。

步驟 7:繼續觀察，發現堵車嚴重，出租車計價器不停計價。步行雖然省錢，但是因公坐車公司負責報銷車費，成本不是大問題。

圖 4. 步驟 7 后的場景

到目前為止，通過權衡這些問題的利弊后我給客戶致電說我估計不能在中午 1：30 的時候趕到客戶公司，我可以等客戶參加公司重要的會議后再進行 Rational 產品介紹，客戶在電話中表示抱歉后掛機，問題解決完畢。

看到這里也許讀者不明白為什么我大費周折地給你們介紹這個小例子，其實我想告訴大家的是：我們不需要將軟件過程改進中關于變更管理和需求管理的過程看得過于復雜化，我們現在待改進的開發過程看似雜亂無章，其實它們是由于我們在開發活動中每個角色獲取利益并規避責任后的本能反應，這些本能的反應活動構成了無序的結果，只要細心梳理這些活動，就可以形成為各自公司所用的變更管理和需求管理過程。

下面看看我們如何在軟件開發背景中分析這個生活中的場景。

軟件開發背景中的場景分析

首先在客戶的電話來之前，我要滿足的需求如表 1 所示：

表 1. 文檔形式描述的需求點
　 需求點： 李明中午 2：00 到上海漕寶路 99 號拜訪客戶，進行 IBM Rational RequisitePro 產品的介紹。

當客戶的電話打來要求調整會議時間時，意味著開發中的需求變更登場了，那么再來看看我在上一章中每句話的含義：

“不知道您會如何處理這件事情呢？” 如何處理變更？

“也許您會說客戶是上帝，客戶是甲方，只能同意?！?無條件接受變更。

“也許您會說沒關系我可以等您，您先開會吧?！?無條件妥協。

“也許您會想：“我還不知道我在哪里呢，怎么回答客戶呀” 既 不想接受，也不知道如何妥協。

“看到這里，也許您會想現在什么時間？離那里多遠？我需要先知道這些才能回答呀?！?已經萌芽了一些分析需求變更的想法，準備分析并處理需求變更請求，很好。

那么我的每個步驟的含義又是什么：

步驟 1:首先讓客戶掛機稍等。然后直接給我們的銷售人員小鮑，告知情況，征詢如何處理。小鮑此時有另外的事情正在忙碌，讓我自己看著辦。 我提交客戶需求變更請求，小鮑分配我去審核變更。（責任劃分明確，避免不必要的責任糾紛）

如下圖所示：

圖 5. 批準需求變更的流程

拿到授權并規避完責任后，我需要判斷是應該接受還是拒絕這個需求變更請求呢？下面分析步驟 2 和 3：

步驟 2:判斷我現在在哪里。從車窗可以看到我現在正在漕寶路 139 號和 137 號之間。 從距離上分析，結論不遠。

步驟 3:看表?，F在 1：10，距離客戶要求的 1：30 還有 20 分鐘。 從時間上分析，時間充裕。

看似我們應該接受這個需求變更請求，但是從步驟 4 至 7 分析，我們又可以得出：

步驟 4:繼續觀察路況，發現堵車。怎么辦？要是開飛經就好了，肯定沒問題；要是想警車那樣管路人借摩托車就好了；實在不成走路過去吧。 從實際進度分析，進展緩慢。希望通過引入新技術提高保障，但是新技術的引入風險大。

步驟 5:繼續觀察路況，當前正中午，夏天天氣炎熱，而且漕寶路兩邊樹木非常少。如果步行，不僅自己被暴曬而且由于行路匆匆，大汗淋淋導致儀表不莊，最終還有可能被客戶投訴。 從舒適度角度分析，舒適度差，并且很有可能舍棄舒適度拼命為了滿足客戶的變更還最終受到埋怨。

步驟 6:繼續觀察路況，需要穿過至少 2 個路口才有可能到達客戶公司。步行不僅天氣炎熱，而且車來車往非常危險。 從安全性上分析，安全性差。

步驟 7:繼續觀察，發現堵車嚴重，出租車計價器不停計價。步行雖然省錢，但是因公坐車公司負責報銷車費，成本不是大問題。 從成本角度分析，成本低。

于是現在腦海中形成了這樣一個分析現象：

表 2 表格形式描述的需求點 需求點 新技術 安全性 成本 時間 距離 舒適度 李明中午 2：00 到上海漕寶路 99 號拜訪客戶，進行 IBM Rational RequisitePro 產品的介紹。 無 差 低 充裕 近 差

從時間和距離的角度看，我們會接受這個變更請求；

從安全性和舒適度的角度看，我們肯定會拒絕這個請求；

那我們到底優先關注的是哪個角度呢？我首要關心的是安全性，然后是舒適度，所以我選擇了拒絕這個變更請求。當然您也許還有別的角度更關心，這就是仁者見仁，智者見智的事情了。對于門牌號這個小例子寫了這么多，這和本文的需求數據和信息的關系有什么關系呢？我們接著看下一章。

需求管理過程信息模型的建立對于管理需求數據的意義

從表 1 和表 2 的對比有沒有注意到，我們最初的文檔變成表格了，這就是為什么軟件開發團隊的需求文檔中有大量表格出現的原因，因為我們愈來愈發現文檔的形式對于我們描述需求愈來愈不能滿足我們的要求了，什么要求？！我們要求能夠對需求進行有意義甚至拓撲結構（包括重要性，優先級等）的描述。稍等，好像這句話在前文中我們好像提到過，在哪里？讓我們再看看數據和信息的定義：

數據：數據是可定義為意義的實體，它涉及到事物的存在形式，是關于事件的一組離散的客觀的事實描述，是構成信息和知識的原始材料。在軟件開發過程中，所管理的很多文檔，例如：項目可行性報告、需求規格說明書、概要設計說明書等都可以看作需求管理中的數據。

信息：信息是一種消息，通常以文字或聲音、圖象的形式來表現， 是數據按有意義的關聯拓撲結構的結果 。在軟件開發過程中，所管理的很多文檔中針對不同的數據條目通常附有相關的說明，這些說明起到的就是信息的作用。

其實在門牌號這個例子中，漕寶路 99 號就是我們所具有的數據，而我們根據路況分析出來的距離，時間，新技術，安全性等是以屬性的形式按照一系列關聯拓撲結構描述了客觀數據，其結果（例如：安全性差，舒適度低等）給我們帶來了分析和判斷事情（也就是需求變更）的信息，這些信息的匯總最終讓我們做出準確地判斷。這些通過需求點和屬性關聯起來的拓撲結構其實已經為我們搭建起了分析需求和處理變更的需求管理過程信息模型。

也有客戶曾就這個例子時候同我分析說，其實表 2 中的若干屬性對于項目開發來說，就是對于需求進行波動分析和變更控制的經驗值的積累，在需求管理過程中這些經驗值或者屬性的積累對于軟件開發團隊確保項目開發范圍的控制是非常有益的。

因此，上述的論述中我們可以看到通過對需求數據和信息關心的描述，我們可以得出需求管理過程信息模型的建立對于管理需求數據的 3 點意義：

意義 1：通過基于需求數據和信息關系的分析，可以助力需求管理在變更管理過程中的應用。

意義 2：需求管理中需求的信息模型的搭建，可以幫助開發團隊積累有價值的分析需求變更和控制項目范圍的經驗。

意義 3：需求管理中不僅注重抽取或捕獲準確的數據，還要能搭建可以服務于企業的標準信息模型，這樣在信息模型的架構下才能更高效地發揮需求管理的作用，保證開發的成功。

那么現在我們也許能夠理解下圖所示的需求管理和變更管理的關系了。

圖 6. 需求管理和變更管理的應用

作為 IBM Rational 產品家族的需求管理產品 RequisitePro 是怎樣支持數據和信息的呢？換句話說，RequisitePro 是如何管理需求和需求屬性的呢？在下一章，我們專門針對這一點進行介紹。

產品 Rational RequisitePro 的介紹

讓我們看看在 IBM Rational SDP（軟件交付平臺）上 IBM Rational 需求管理產品 RequisitePro 是如何同變更管理產品 ClearQuest 完成上述這個小例子的：

第一：在 IBM Rational SDP 中創建集成項目“門牌號小例子”，如圖所示：

圖 7. 在 IBM Rational SDP 中創建項目

第二：創建完集成項目“門牌號小例子”后，、再創建 RequisitePro 所管理的需求工程“門牌號的小例子”，所有需求數據（需求項，或者需求點），需求屬性交由 RequisitePro 管理；然后為再創建 ClearQuest 的變更管理數據庫，所有變更條目，變更狀態等數據交由 ClearQuest 管理（創建 ClearQuest 變更數據庫的操作不屬于本文重點，所以不贅述了），如下圖所示：

在 RequisitePro 中創建不同的需求類型，如本生活情景中我們有業務需求：

圖 8. 在 RequisitePro 中創建需求類型

第三：創建完需求類型后，成熟的需求管理在需求管理計劃中會針對不同的需求類型定義不同的需求屬性，例如本生活情景中分析信息所用到的屬性有：安全性，成本，距離，舒適度等，其中不同的屬性的類型不一，例如：安全性屬性屬于枚舉類型，成本屬于數值類型，距離屬于文本類型等，這些屬性類型，甚至默認值都可以在 RequisitePro 中定義，如下圖所示：安全性屬性的創建過程

圖 9. 在 RequisitePro 中基于不同的需求類型創建屬性

第四：到此為止，我們可以說按照需求管理計劃的要求在 RequisitePro 中創建了一個名為“門牌號的小例子”需求工程，然后我們再去創建 ClearQuest 的變更數據庫以及流程（前面說過，ClearQuest 不是本文重點，所以這里不在具體制作關于 ClearQuest 流程定制和數據庫創建的過程），默認我們已經創建完 ClearQuest 中的變更管理的數據庫和流程，我們直接進入 RequisitePro 和 ClearQuest 在 SDP 中的集成配置過程，如下圖所示：

圖 10. 在 IBM Rational SDP 中配置 RequisitePro 和 ClearQuest

第五：配置好 RequisitePro 同 ClearQuest 集成后，在 RequisitePro 輸入需求點的具體內容，如下圖所示：

圖 11. 在 RequisitePro 中增加需求

RequisitePro 中需求點的詳細描述：

圖 12. 詳細的需求點

第六：假設此時客戶變更出現，可以在 ClearQuest 中提交變更請求，如圖所示：在 ClearQuest 中提交 SAMPL00000042

圖 13. 在 ClearQuest(CQTM) 中創建需求變更

然后可以直接在 SAMPL00000042 號變更單中的“需求”Tab 頁中選擇“門牌號的小例子”需求工程，同相關聯的需求點進行關聯，如下圖所示：

圖 14. 創建需求變更時，將變更同需求點關聯


圖 15. 關聯 RequisitePro 中的需求點

第七：關聯好后，進入 RequisitePro 后可以直接看到剛才的變更請求同需求點關聯的視圖，在視圖中可以看到需求點旁邊有許多有用的屬性，這就是 RequisitePro 所管理的需求屬性矩陣，這個矩陣可以幫助我們基于已有的數據分析出有用的信息，如下圖所示：

圖 16. 在 RequisitePro 中分析矩陣

正如上文例子中所分析的原因，最終我們決定拒絕 SAMPL00000042 號變更請求。

總結

本文為了讀者便于理解，將生活中的小例子刻意從軟件工程的角度進行解決。但是通過上面的介紹，讀者可以感受到，在軟件開發過程中其實我們已經有了許多項目數據了，可是這些項目數據只是被幾個項目的專家和骨干掌握，只有他們才能做出有效而準確地決定，為什么？正是因為他們有項目經驗，而需求管理中的屬性矩陣可以很好地將這些專家或者骨干頭腦中的經驗挖掘出來并固化到平臺上面，這樣對于其他人員是非常有益的，可以很快提高團隊的戰斗力，從這一方面，也在此強調了需求管理中的需求數據和信息的分析對于產品的質量是有很大保證的。只要我們掌握了數據和信息的本質聯系，是可以在項目的需求管理中活學活用的。

原文轉自：http://www.kjueaiud.com