確立需求，才不會在開發過程中迷航

需求是軟體開發的發動端，所有軟體開發的動作，皆始自於需求的發生。當你既是提出者，也是實作者時，意念的傳達既準確又迅速。在這個過程中，需求的變更及提出，往往是樂趣的來源。這樣子敲敲打打地打造出喜歡的玩具，是能樂在其中的。

當然，在如此簡單的個人化開發模式中，程式人也決定別人是否可以提出需求，或者自己是否要接受需求。最後，實作的結果是否滿足需求，也是由程式人自己確認。這樣的模式是大多數程式人都最喜愛的模式：自己就是一手建立的世界裡的上帝。

群體戰的年代，軟體需要專職的需求制定者
不過，現代軟體的開發，已經從單打獨鬥的個人年代，轉變成為集團作戰。一旦涉及群體的開發，自然有角色分工，從需求到實現的這一條道路，由不同的角色各職其司。

前些日子，我在網路上讀到一篇標題為「程式設計師的格言」的文章，整理了許多在程式人圈子裡流傳的所謂「格言」。說是「格言」，卻是道盡了許多程式人不為人知的甘苦。

有趣的是，從那篇文章裡，可以找到許多關於需求及軟體規格的「格言」，最為網友們稱道的，莫過於「要殺一個程式設計師不需要刀，改三次規格就好」這一句話。

這句話，一針見血地道出程式人對於需求變更的恐懼，但也指出了許多軟體專案對於需求變更缺乏實際或有效管理的現象。事實上，當軟體專案的需求變更管理出了問題，受傷最重的，除了專案本身之外，就是程式人了。這也無怪多數程式人們視規格變更如洪水猛獸。

不過，除了需求變更之外，在整個開發的過程中，還有許多環節會讓程式人受到傷害，當然，這也會重傷軟體專案本身，但這些問題，始終充斥在許多人的開發生活中。

第一個常見的問題是：沒有專職的角色，負責需求的提出或規格的制定。這種情況有時發生在一群程式人一起開發的情況，每個人的角色既是程式人，也是需求的制定者。

每個人決定自己想做什麼，最後再試著把各自完成的部份一一組裝起來。此外，也有一些需求的誕生是在會議之中，參與者在你一言我一語之下各抒己志，但最後也沒有人負責將規格確定下來，沒有人扮演那一個「我說了算」的關鍵角色，所以需求呈現十分零亂又不確定的情況。
沒有需求規格，等於航海少了地圖
沒有專職的需求確定者（通常我們會說這樣的人是使用者或使用者的代表），通常就會衍生出第二個問題：沒有需求規格。

這是許多開發團隊的問題，他們根本不撰寫需求規格，所以整個開發專案，根本沒有規格可言。我相信為數不少的程式人在這種情況下，天天過著聽使用者口述需求的日子。甚至還有人把這種開發方式，自顧自地稱為「eXtreme Programming」，實在是大大誤解XP的精神。

不論你所用的開發方法論，是多麼的敏捷、輕量級，但需求總是必須確定下來，而且明確地記錄，讓專案的每個人都可以接觸到。不論記錄、表達需求規格的方式是簡單或複雜，它總是必須明確地記錄並表達。

需求規格就像是軟體開發時的航海圖，少了這張圖，「程式設計師就必須憑自己的力量在海上找到大陸」。少了一個確切的方向，每個人不見得都往同一個方向前進，這要如何確保大家會相會呢？

想要省略需求規格的主要動機，往往是想省去撰寫規格的時間，以提高開發的速度。有些人將「撰寫文件」視為浪費時間的無用舉動。但是，倘若需求不能準確地從需求提供者傳遞給程式人，結果實作出不能滿足需求的產物，最後來來回回地更正及修改，只會耗去更多時間。

需求的更動，不僅將耗費人力及時間，也會導致品質下降
也有一些開發團隊，把需求規格的格式設計的過於繁瑣，導致制定規格者必須耗費大量的時間於文書工作，事實上，太多的細節描述，有時無助於程式人更深刻了解需求，不僅可能造成反效果，更是為了繁文縟節而浪費時間。

此外，需求沒有獲得技術人員的承諾，也是常見的問題。提出需求的人員，天馬行空地想像了許多的功能，但在制定規格的過程中，並沒有技術人員參與、了解，並認可其中的可行性。於是，當需求規格完成後，片面交付開發人員實作。幸運的話，在短時間可以重新再修改規格（也浪費不少時間），運氣差的話，到了後段才被發現需求不可行，那麼所造成的衝擊更是驚人。

需求規格的變更幾乎是所有程式人的惡夢。江湖上流傳的格言說：「需求規格在程式寫完後才會敲定」、「基本規格要客戶看到成品後才會決定」、「詳細規格要使用者用過後才會確定」。

太多握有需求控制權的人們，對於需求的變更，幾乎已經到了一種肆無忌憚的境界。有的甚至幾乎每天對於系統應該具備的功能，都有新的想法。無怪乎程式人會說「品質的劣化程度，依規格改變的次數與規模而定」。

需求的變更，對於系統的傷害是很大的。因為軟體高複雜度的特性，牽一髮動全身，更動一條需求規格，有時程式人將因此大幅度修改。而且，對測試工作而言，除非全面徹底地重新再測試，否則很難保證單靠迴歸測試，就可以找到修改所造成的副作用。需求規格的更動，除了意謂著得投入更多的人力及時間外，通常更會造成品質下降。

不論採用何種方法論，CMMI的需求管理實踐準則都是基本要求
為什麼需求制定者仍然肆無忌憚地頻繁變更需求？因為他們沒有因此付出代價，或者說，他們沒有意識到整個專案會付出沉重的代價。最直接受害的，幾乎都是吞下需求變更所種下苦果的程式人。
因為，雖然需求規格改變，但開發的期限通常不會改變。開發時程的延遲，矛頭幾乎都指向在接力賽中負責實質最後一棒的程式人，但問題其實並不出在這裡。

即使能有效控制需求變更的次數，但仍是無法避免的情況。當需求變更時，許多人無法評估對開發過程所造成的影響。這是因為他們並不能掌握某一個特定的需求，究竟是由那些開發中的產出所完成。

更有不少專案，到了進入測試階段，才發現他們所實作的系統與規格之間，竟然不相符。這是因為，他們並沒有在開發的過程中，將所開發的功能與需求規格比對，也沒有檢查是否每一項需求規格都已經實現。

對於需求管理的問題，有名的CMMI提出了很好的實踐準則，無論你對CMMI的印象如何，我都建議研讀相關的資訊。因為在CMMI ML 2的需求管理（REQM）流程領域中，都已針對需求管理提出了幾個實踐準則，包括「瞭解需求」、「取得需求承諾」、「管理需求變更」、「維護需求的雙向追溯性」，及「界定專案工作與需求間的差異」等，不論你所採用的開發方法論是重量級或輕量級，對於任何一個軟體開發專案而言，它們其實都是需求管理的基本要求。

作者簡介：
王建興
清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。