需求管理

做需求的人好好學學吧！沒有經過系統的學習，弄的個個跟土八路似的！小米加步槍已經打不了天下了！

 

--------------------------------------------------------------------------------------------------------------------------------

     需求管理這個詞有兩個部分：需求和管理。先說需求，需求是什么，需求就是你要買衣服時要對售貨員說你要多大的衣服。需求很難說清楚，比你搞不清楚自己的尺碼還難，因為售貨員會看看你的身材，拿出一件衣服讓你試一下，不合適可以不給錢。但是軟件不行，你會說我先給你開發個軟件給你試一下，不好不用給錢嗎，我反正不會。需求會變，如果你胖了或是瘦了，發現原來的衣服不能穿了，你會再買一件，如果再買一件衣服需要花掉你10000塊錢，你怎么辦？而由于軟件不合適更換軟件的費用是非常驚人的。

    人類的大部分的工程都會有比較嚴格的計劃和質量保證，例如建筑。但是工程一旦落實到軟件開發上的時候，大家就會變得“大大咧咧”起來。軟件項目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根”（L effingwell 1997）。如果你對建成的橋不滿意，要求設計師把橋轉90度，他一定會認為你瘋了，但是軟件開發中經常都有發生要求開發者更換操作系統的事情，要知道，這二者對項目而言的工程量可沒有太大的差別。
所以呢，正是由于需求的難表述性和易變性，所以需求需要有科學的分析方法和管理方法，這里分析方法不是本文的重點。

需求的特點

    需求的特點剛才已經提到了，就是難以表述和易變�？墒�，為什么需求會有這種的特點呢？

    在計算機產生的早期，計算機只是少數人的“寵物”，這些人個個學富五車，才高八斗。他們可以用010101之類的語言直接操縱計算機，他們也樂此不疲，那時候計算機對人類的影響還不是很大。隨著計算機硬件越來越快，越來越小，軟件也發生了翻天覆地的變化。計算機變成了社會不可或缺的一種工具。但是，計算機的文化，計算家的理念一直都沒有變化，今天的程序員和幾十年前的程序員骨子里還是一樣的。他們喜歡操縱計算機，思考都和計算機一樣，運用邏輯思維，甚至在他的思想中只有0和1。這對于感性的普通人來說無法接受�？墒�，普通人使用的軟件正是這些擁有邏輯思維的人設計制造的。程序員的思維貫穿了軟件設計的全過程，同樣也貫穿了需求過程，而普通人沒有這方面的思維，他們覺得和程序員打交道極為困難，在程序員的眼里，世間的一切都是有清楚的界限的：0和1。需求過程中，雙方往往發現要么雙方不能達成共識，要么雙方達成共識的內容其實有相當大的出入。所以在需求過程中經常出現用戶講不清楚，講不完全需求的情況。更要命的是，在需求階段就又問題的需求，如果在軟件后期發現，那么改正的費用是非�？膳碌�。有時候，甚至會超出項目本身的費用。






    社會在賣方時代的時候，企業只需要生產出產品，保證產品的質量，就不用擔心產品的銷售了，所以生產的過程也是比較穩定的。隨著社會進入買方時代，企業必須不斷的適應市場，適應消費者才能保證不為社會所淘汰，所以企業的經營活動必須不斷的變換以保證企業具有活力。這種變化對于計算機系統來說是非�？膳碌囊患�事。計算機系統必須不斷適應企業的變化而變化，否則就會阻礙企業的發展，原先是為了加速企業發展而開發的信息系統卻成了企業發展的束縛，這不是一個極大的諷刺嗎？除了宏觀的原因外，需求的不易表達也是需求易變的一個原因，需求分析的不清晰和不完整導致了需求必將發現變化，要么就是對原先的需求進行修改，要么就增加需求。

需求的總流程

需求的總流程如下圖：





    需求分析的這個過程，我們可以稱它為需求工程，也有叫做需求過程和需求階段的。需求工程包括了需求開發和需求管理，他們所涉及到的具體工作流如上圖標明的那樣。在上一篇中，我介紹了一個我自己所經歷的需求過程的例子，這個例子就經歷了整個的需求過程，

    由于我們討論的重點是在需求管理，所以上圖左半邊的部分不再我們的討論范圍之內。

需求管理

    軟件能力成熟度模型（The Capability Maturity Model ，CMM）的第二級（可重復級）中將需求管理做為六個關鍵過程域（Key Process Areas ，KPAs）的一個：

    需求管理的目的就是在客戶和遵循客戶需求的軟件項目之間建立一種共同的理解。

需求的目標包括：

控制指定給軟件的系統需求，為軟件工程和管理應用建立基線。
保持軟件計劃、產品和活動與指定給軟件的系統需求一致。

    為了實現第一個目標，必須要控制需求基線的變動，實施需求變更控制和版本控制。為了實現第二個目標，必須要對需求進行跟蹤，管理需求和其他聯系鏈之間的聯系和依賴。

    雖然并沒有要求說軟件團體必須要實施CMM，但是CMM的思想對任何的軟件團體來說都是有益的，CMM為了實行這兩個目標，還確定了一系列的執行約定、執行能力、執行活動來達到這兩個目標。但是，CMM并沒有強制要求軟件團體必須遵循的軟件需求管理過程。

    對于產生的需求變更，必須要有變更控制的標準、規范的過程來處理，并且由基于業務和技術的原因來贊同或反對這項變更。在接受了軟件變更之后，必須要保證軟件開發計劃要和需求保持一致，并對需求的版本進行控制，避免同時出現多個需求版本的情況。在保證軟件開發計劃方面會有很多問題產生，例如進度、質量等。這時候，必須就變更和軟件項目各小組達成共識，對軟件項目計劃作出調整，其中包括人員的安排、任務的安排、用戶的溝通、成本的調整，進度的調整等。

    為了能夠實現上面所闡述的過程，必須要將需求過程文檔化，注意，是需求過程，包括了需求開發和需求管理兩個方面。使用適當的Case工具也同樣有利于管理工作的開展，按照我自己的經驗，采用Office和命名準確的目錄就已經足夠勝任此工作了，但是如果要能夠更高層次的使用Case工具，我建議使用關系數據庫來管理你的需求。至于在工具方面，是各軟件團體自身的情況而定。我相信，沒有最好的工具，只有最適合的工具。

變更控制

    記得還在大學的時候，和同學討論一道知名軟件企業的考題：如果客戶要求你幫助他修改軟件一項功能，你應該怎么做？正確的答案是要向你的項目經理報告。這里面就包含了變更控制的思想。在前面我們已經說過，易變是需求的一個特點，但是任何需求的變動都會對項目產生或多或少的影響，如推遲進度，增加人員等。如果沒有對變更的控制，那么項目就會失去控制。我就見識過一個軟件項目在經歷了無數次的因需求變更導致的延期之后，發現改變的功能已經遠遠偏離了原先的需求定義。

    研究表明，擴展需求對百分之八十的管理信息系統項目和百分之七十的軍事軟件項目造成風險（Capers Jones 1994）。擴展需求是指在軟件需求基線已經確定后又要增添新的功能或進行較大改動。問題不僅僅是需求變更本身，而是遲到的需求變更會對已進行的工作有較大的影響。具體的原因包括在軟件系統中引入新功能往往會帶來新的問題，新加入的需求和以前的需求有矛盾之處。

    由于需求的可變性，所以沒有需求變更是不可能的，并不是說你的需求分析不夠完整，業務過程、市場機會、競爭性的產品和軟件技術在開發系統期間是可以變更，管理部門也會決定對項目做出一些調整。所以你在你的項目進度安排中一定要給需求變更留下余地，微軟的開發方式中在每一個的里程碑（Milestone）間都預留了50%的時間，也是有這方面的理由。

    然而，這并不是說你要接受所有的要求，國內很多軟件公司深得“客戶就是上帝”的精髓，客戶的所有要求都予以滿足，這樣做的結果往往就是開發人員疲憊不堪，質量得不到保證，項目延期，客戶和軟件團隊雙方的利益都受損失。學會對客戶說“不”，當然，回絕必須要講技巧，并不是一句“不行”就可以解決問題的。昨天我去買東西，我問售貨員能不能便宜一點，她回答說：“不行，已經很便宜了！”。最后我就沒有買，但是她如果換句話說：“對不起，我們的商品的質量都是特別好的，如果您下次再來的話，我們將給你優惠的價格”，我相信我會買下那個商品。所以說不要講究技巧�？蛻舻囊�求應該盡量滿足，即時現階段不行，也要向客戶解釋清楚，并在下一個版本中考慮客戶的要求。

    對于需求變更的控制，保證成功的最主要的兩點是將變更應用到整個開發鏈和記錄歷史變更。你可能需求一份變更控制文檔來說明變更需求，大致需要說明的元素包括：

    概述：說明變更的大致內容，應用范圍，對開發鏈的影響，總之讓管理變更控制的人明白你的要求是什么。
    上下文：變更的需求在整體需求中的位置，如果需求是用用例表示的，指出他的父用例是什么。
    規模：根據開發進行的程度，指出實施變更需要付出的代價，這個代價是決定接受需求，通知客戶項目延期，在下個迭代周期中實現變更的決定參考。
    提交人簽字和所屬開發組：決定了提交人所處的立場。

    一般來說接受需求變更提交的組織稱為變更控制委員會（CCB 有時也稱為結構控制委員會），該委員會的組成包括各開發小組的代表，以保證需求變更實施到整個開發鏈。CCB的工作流程大致是：

    接收到一新的變更要求后評估建議的技術可行性、代價、業務需求和資源限制。執行系統影響分析、風險分析、危害分析及其它評估。這些分析確保能很好理解接受變更所帶來的潛在影響。同樣也考慮拒絕變更所帶來的對業務和技術的影響。

    CCB決定是采納或還是拒絕請要的變更。給每個采納的變更需求設定一個優先級或變更實現日期，或將它分配給指定的產品。CCB通過更新請求狀態和通知所有涉及到的小組成員來傳達變更決定。相關人員可能不得不改變工作產品，如軟件需求規格說明文檔、需求數據庫、設計模型、用戶界面部件、代碼、測試文檔、用戶文檔。修改者在必要時應更新涉及的工作產品。

    通過檢查確保更新后的軟件需求規格說明文檔、使用實例文檔、分析模型均正確反映變更的各個方面。使用跟蹤能力信息找出受變更影響的系統的各個部分，然后驗證他們實現了變更。屬于多個小組的成員可能會通過對下游工作產品測試或檢查工作來參與驗證變更工作。驗證后，修改者安裝更新后的部分工作產品并通過調試使之能與其它部分正常工作。（摘自《軟件需求》）

    最后，你需要記錄變更記錄，并建立需求變更跟蹤矩陣來確保變更的實施。

版本控制

    需求版本混亂造成的災害主要體現在資源的浪費上面，很多軟件團體中經常發生開發組花費時日改進了一項功能，卻發現整項功能已經取消，發生錯誤原因是因為開發組沒有拿到最新的需求。

    版本控制包括兩個方面：保正人人得到的是最新的版本，記錄需求的歷史版本。

    如果有專門的需求管理商業工具可以助您一臂之力，由于我并沒有條件試用所有的需求管理工具，能夠向大家推薦的只有瑞理公司的RequisitePro，推薦的一個重要原因是它能夠把需求和瑞理的其他工具如Rose、TeamTest等聯系起來，從而實現需求鏈。

    能夠借助工具將需求自動化固然很好，不過，工具使用不當也不會提高生產效率。需求管理的工具其實用簡單的Office和任一個關系型數據庫就可以解決，而且根據企業自身的特點，摸索出最適合企業用的工具。

    版本控制的最簡單方法是在每一個公布的需求文檔的版本應該包括一個修正版本的歷史情況，即已做變更的內容、變更日期、變更人的姓名以及變更的原因并根據標準約定手工標記軟件需求規格說明的每一次修改。

需求鏈和需求跟蹤

    如果你是一個開發人員，一天，市場部的小莉跑過來讓你修改你正在開發產品的一個小小的功能，這是應客戶的要求添加的，你覺得這個要求很簡單，再加上你對小莉有好感，可能你就答應了她的要求�？墒菍嶋H的情況是怎么樣的呢？你會發現小小的修改并沒有想象的那么簡單，對這項產品的修改導致了進程的延誤，最糟糕的是，由于這項修改沒有傳達到整個需求鏈，其他的開發人員那里由于你的修改出現了一些要命的錯誤。

    軟件工程重視的是過程能力，如果不能嚴格的確保過程的每一個環節都被不擇不扣的執行，軟件過程就會不成功，我們都學過法律常識，都知道有法可依還不夠，還必須有法必依，執法必嚴。遺憾的是，中國的軟件組織對過程的嚴格執行并不是特別重視，上面的例子在各團體中都是很普遍的，這可能和中國人的思維方式有些關系，關于這一點，魯迅先生在很早的時候已經討論過了，我們就不用在此羅嗦了。

    需求鏈的概念指的是需求能夠上傳下達，從客戶傳達到需求過程，并從需求過程傳達到需求過程的下游開發鏈。而這個傳達是可以逆向的。





    需求跟蹤提供了一個表明與合同或說明一致的方法。更進一步，需求跟蹤可以改善產品質量，降低維護成本，而且很容易實現重用（ Ramesh 1998）。

    在CMM三級中要求軟件團體必須具備需求跟蹤的能力：“在軟件工作產品之間，維護一致性。工作產品包括軟件計劃，過程描述，分配需求，軟件需求，軟件設計，代碼，測試計劃，以及測試過程�！�

    實際上，創建需求跟蹤能力是困難的，尤其是在短期之內會造成開發成本的上升，雖然從長遠來看可以減少軟件生存期的費用，軟件團體在實施這項能力的時候應循序漸進，逐步實施。

    需求跟蹤的一種通用的方法是采用需求能力跟蹤矩陣。它的前提條件是將在需求鏈中各個過程的元素加以編號，例如：需求的實例號，設計的實例號，編碼的實例號，測試的實例號。他們的關系都是一對一和一對多的關系。通過編號，你可以使用數據庫進行管理，需求的變化能夠立刻體現在整條需求鏈的變化上。

    需求跟蹤矩陣并沒有規定的實現辦法，每個團體注重的方面不同，所創建的需求跟蹤矩陣也不同，只要能夠保證需求鏈的一致性和狀態的跟蹤就達到目的了。