透過項目談需求分析

標籤：需求   團隊   管理   

背景

            參與人事檔案管理系統將近一年了，這一年中通過這個項目發現了許多問題，不管是在軟體設計方面還是在團隊合作方面以及在與使用者交流擷取需求的過程中暴露出了許多問題，也學到了許多東西，今天主要總結一下在需求分析上的問題與收穫。

供需交流困難

   在軟體生存周期中，其它四個階段都是面向軟體技術問題，只有需求分析階段是面向使用者的。需求分析是對使用者的商務活動進行分析，明確在使用者的業務環境中軟體系統應該"做什麼"。但是在開始的時候，我們和使用者雙方都不能準確地提出系統要"做什嗎？"。而我們又不是使用者問題領域的專家，不熟悉使用者的商務活動和業務環境，又不可能在短期內搞清楚；而使用者不熟悉電腦應用的有關問題。因此雙方互相不瞭解對方的工作，又缺乏共同語言，所以在交流時存在著隔閡。 

如何擷取需求
           需求分析是軟體工程中很重要的一個環節，直接決定著項目的成敗。需求分析是一項重要的工作，也是最難的工作。需求分析的方法有很多種，如面向過程（自上向下分解）、 資訊工程（資料驅動）（資料流分析結構化分析方法）、 物件導向（對象驅動）。這些方法很實用對需求分析過程來說也很常用，但是對於我們這些完全不瞭解使用者業務的開發人員來說再好的分析方法也用不上，不瞭解業務不知道如何將業務一層層分解、不能正確的把握資料的流向，更不用談物件導向了。
    面對這樣的情況，我們只能每次接受使用者的一部分需求，然後做一個最基礎的原型出來。這種原型要比需求分析方法中的原型方法複雜一點。需求分析的原型方法只要求我們用某些軟體工具快速的建造一個原型系統，這個系統只是一個介面，然後聽取使用者的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。而現實中如果我們只做一個介面的話，一個沒有資料的一個空殼子，對於不懂如何開發軟體、不知道何為原型的使用者來說，讓他們從這樣的原型上去提建議、提需求還是有些困難的。所以我們在原型方法的基礎上將獲得的原型功能全部實現了，以此作為一個原型再去進一步擷取需求。
     談到原型方法就得必須談談原型方法的三種類型：探索型、實驗型、進化型。
     探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。
     實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。
     進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。

    我們主要以進化型為主以探索型為輔，探索使用者目標需求最終確定一種可行性。這樣迭代將每一種可行性在上一可行性的基礎上疊加，走進化型路線，逐步將原型進化成最終的系統。

客戶的需求為何總是再變

        對於需求變更是最令人頭疼的事。首先由於我們不清楚業務所以最初是使用者帶著我們走，這樣即使使用者提出的需求存在問題，我們也沒法去發現問題或者向使用者提出我們的建議，去避免這些風險從而避免後期的需求變更。站在使用者的角度來說，他們很難精確完整地提出它的功能和效能要求。一開始只能提出一個大概、模糊的功能，只有經過長時間的反覆認識才逐步明確。有時進入到設計、編程階段才能明確，更有甚者，到開發後期還在提新的要求。更何況有時候有些具體實現明明就是按需求完成的，但使用者還是會更該需求，因為最初的需求是大概的、抽象的、模糊的，一但這些需求轉變成實現再經過一段反覆的認識使用者提出一些更改也是在所難免的。面對需求變更我們要做的一是要做好準備應對需求變更，將風險降到最低，二是做好需求變更記錄。

對擷取的需求進行加工

            當我們拿到使用者的需求時，有時這樣的需求只符合軟體的局部要求，而要將這些需求實現並且跟其他模組進行融合還需要去宏觀掌控將這些需求適當改造，達到既能滿足使用者的需求還能符合系統的整體需求，這樣的需求實現才能更好的為系統提供服務。

捕獲將來一定或者可能要變的需求

             對於將來要變更的需求，我覺得緊緊做到嚴格控制需求變更的申請流程以及做好變更記錄是遠遠不夠的，因為有些需求的變更是不可避免的。我們還要在軟體開發階段將這些風險降低。在軟體開發階段可採取物件導向的設計思想，在設計之初多多應用設計模式，充分考慮將要變化的需求，預留出介面。另一方面就是將軟體的功能之間儘可能的解耦，做到靈活可配置。兩種方法有點共同之處，首先可能不應用設計模式的話我們只需要一個類幾個方法就可以滿足需求，而我們還要去抽象出介面，建立實作類別之間的聯絡。這樣有點將簡單的問題複雜話的意思，同樣軟體功能做靈活不僅僅需要我們把這個功能實現出來，還需要我們後期將這個功能進一步做成可配置、可管理，這就需要我們額外添加功能去配置去管理將要變化的功能，從而實現將功能的變化控制在一個可控的範圍內。

總結            以往做系統需求都很明確，並且還有原型系統作為參考，很少能夠凸顯出需求分析的重要性。自己提需求，然後自己開發系統，這樣明顯降低了很多要求，而開發出來的系統也只能自己用。軟體工程學了那麼多，需求分析的方法也學了很多，但與實際應用聯絡起來的實踐機會還很少，所以我們對知識的掌握還停留在理論層次上，真正碰到問題的時候還不能做到手到擒來。而這一次是第一次將需求提供與開發角色分離需，也就決定了系統開發不再全部以我們開發人員自己的意志為轉移，更多的是站在使用者的角度去思考問題、解決問題。