制定軟體功能規格的關鍵考量

最近剛好在 Facebook 上看到朋友提到，軟體開發工作上竟然收到了一份規格，是做成投影片格式的，讓他大感驚訝。這件事情讓我想到，對軟體開發來說，規格是很重要的一件事情，究竟為什麼我們需要一份規格、規格應該以什麼形式呈現、以及規格中應該包括那些元素呢？這是一個值得探討的主題。

功能規格的重要性
我們可以說，所謂的規格，就是用來描述所開發出來的軟體應該具備的特質。

軟體規格依據其性質可以再做區分，例如，所謂的「功能規格」，指的就是軟體開發完成之後應該具備的樣貌，包括了它面對使用者或其他系統的介面，以及它的諸般行為。「功能規格」著重在從外界看來，軟體產品是什麼東西；而所謂的「技術規格」所涉及的，則像是軟體產品內部實作層次的規範，像是資料結構、演算法、或是運用的程式語言、程式庫、以及應用程式框架、……等等。在談軟體開發的規格時，我們所最關心的，應該還是以「功能規格」為主。

軟體開發如果不寫規格的話，會發生什麼事？在以前的文章中曾經提到過，軟體規格這些在程式碼撰寫完成之前就先行產出的開發產物，其實是代表最終所要開發出來軟體的模型。

就像蓋房子前，會先繪製的草圖或小模型一樣，我們可以在投入實際的施工之前，先讓關心最終產物究竟會長什麼模樣的利益關係人，都可以先透過一個簡單模型的建構，來明白究竟這個開發專案會做出什麼東西出來。

開發一整個軟體所需耗費的力氣，遠大於完成一份軟體規格，若是透過些許的投資，便能夠完成一份規格，並且有效讓利益關係人知道，究竟這個開發案會得到什麼產出，那麼相較於必須等待整個軟體都完成之後，才能夠知道，這些許的投資顯然是極為划算。

這邊所指的利益關係人，包括了使用者端的人，他可能是公司的老闆、產品經理，也可能是接下來要做系統設計的人、也可能是開發者，當然也有可能是測試者。

所以，一份規格最重要的作用，就是讓代表使用者端的人，可以確認這的確就是他們想要的東西，也讓開發團隊中的各種角色知道，他們應該要做出什麼樣的東西。

確認規格的有效性更重要

沒有產品規格的開發，有沒有可能？當然有，尤其是一人開發的產品最有可能，因為開發者自己「校長兼撞鐘」，自己決定自己要做的東西。不過即使是一個人開發的情境下，透過一份規格，可以在實際動工之前，先全盤思考自己究竟要做出什麼樣的東西，中途持續改變想法時，也可以省去因為需求變更所衍生的種種額外負擔。

有些人不寫規格是想省時間，但很多時候，「出來混的遲早要還」，省去撰寫規格的時間，之後只是在開發過程持續的「加倍奉還」而已。

但這並不是說你寫了規格，或者寫了堆積如山的規格，就一定可以達到它該有的作用。

我常舉一個例子，在生涯中參與的第一個救火專案，就是在離距離交期已經延遲了半年時，才決定打掉重練的一個專案。

這個專案發生了什麼事？

這個專案把開發外包到上海去，因為兩岸相隔遙遠，所以為了避免溝通產生誤差或時間差的問題，所以在臺灣訪談需求後，寫成了一份份量極重的規格書，照同事的說法是「和一個人差不多高」，接著丟到上海去開發。當上海的團隊好不容易把系統開發好了，交到臺灣建置之後，讓客戶端的使用者看了之後，他們都嚇了一跳：「這……這是我們請你們開發的東西嗎？」顯然所開發出來的產物和客戶所預期的，存在不小的差距，而這也就是之所以這個專案幾乎是要從頭歸零開始，徵召多人組成救火隊，重新追趕進度的原因。

這說明了開發時有一份規格當然很重要，但是這一份規格必須真的能夠發揮它的作用，包括了和關心最終開發產物的人確認下來。

在上面的例子中，同時也點出了一個許多人都會有的迷思，也就是規格書寫愈多愈好，最好有一個人那麼高。但是，很容易理解的，規格書的份量並不是愈多愈好，它必須有效的、並且精確的傳達需要被傳達的資訊。並不是厚重的規格、鉅細靡遺地交代一切細節，就一定是好規格，也不是寫得輕薄短小、省略若干細節，就一定是不好的規格。我認為，還是要視當時的時空環境，以及限制條件來決定。

決定規格的形式
有些人會在寫軟體規格的時候，喜歡基於一些模版來著手，不過，其實你究竟需要一份怎樣的規格書格式或體裁，往往取決於應用時的許多因素，就像前一段中所說的：當時的時空環境，以及限制條件。

舉例來說，極限編程（eXtreme Programming）的方法裡就主張簡化規格的描述，建議用所謂user story來描述規格。對一些人來說，這樣的描述可能不夠系統化，也不夠嚴謹，而且認真來挑剔，可能還會略去不少細節。但是，並不能這麼說就覺得這樣的規格不能用，因為極限編程有一些假設的應用情境及配套的方式。

就像這類的敏捷方法，總是預期要快速因應需求的變動，那麼，太重量級的規格寫作方式，就會影響到開發的步調，還有每一次的做改變時的代價。但是簡化規格並不是沒有配套，配套就是像 「user on site」，也就是決定需求的人和開發團隊的人在同一個地點，彼此之間可以很緊密合作。一旦開發團隊需要什麼資訊，都可以隨時得到。

所以說，什麼樣的形式才是一份實用的規格，其實很難有一定的標準答案，團隊採用什麼樣的開發方法、團隊的規模、團隊成員的素質、需求變動的可能性及程度、甚至像團隊成員中溝通的能力等等，都會影響到你究竟決定規格應該以什麼形式，或精細度來呈現。

從實用性來考量規格的形式

回到本文一開頭所提到的，投影片的格式能不能做為規格的文件形式呢？

或許對有些人來說，乍聽之下會覺得很不合理，起碼你也拿個 Word 格式來編一下規格吧！不過，舉例來說，如果你參考有名的 Joel Sposky 曾經寫過的一個規格範例，你會覺得，其實就算這一份規格，都放到一頁一頁的投影片裡，也都挺適合的。而且，投影片還很適合做為簡報的內容，直接跟大家做報告以利溝通和確認。

所以投影片是好的形式嗎？有些情況下，它可能會不錯。規格文件的問題很少是出在它呈現的文件形式，而是出在內容本身。

內容不對，用什麼形式來呈現都不會對，相反的，內容正確了，呈現的文件形式就有比較多的選擇性了。

就像用像 Excel 之類工具裡的試算表文件，一樣有能力表現規格。就像你可以在網路上，找到一些採用敏捷開發方法的人，利用 Excel檔案格式來記錄User Story的例子一樣。

所以說，份量不是問題，形式也不是問題，重點是，你的規格有沒有表現出一份規格該表現出的內容。在下一回中我們會繼續探討。