探索需求，如臨大敵

剛接觸軟體開發這個工作時，相信不少人都和我一樣，單純地以為軟體開發的過程中，最重要的階段就是程式撰寫的階段，畢竟，真正能運行的程式碼是在這個階段中實際產出的。

傳統的瀑布模型，是將軟體開發的模型區分為需求分析、設計、實作、測試、整合、以及維護等階段，而各階段依序被一一執行。這些階段基本上描述了軟體開發時的主要工作。雖然說，一開始接觸軟體開發時，你可能會覺得實作最重要，但後來你終會開始發現，其它的每一個環節都很重要。

其中，需求分析的重要性時常被忽略。什麼是需求分析呢？需求分析的工作目標便是在開發軟體時，確定所要開發系統的範圍及需要完成的所有工作。而這邊指的範圍最重要的就是需要被完成的所有功能以及它們的內容。這當然是整個軟體開發工作的根本工作，只有將需求精準的確認下來，才能開發出滿足真正需求的軟體，也才能解決真正希望被解決的問題。

但事實上，有很長的一段時間，需求分析的工作並不是那麼的受到人們的重視。甚至有時候被認為是一項很簡單的工作。相信許多人都有類似的經驗，在開發軟體的時候，曾經聽到別人說了類似的話──「那就把規格開一開，接著就可以開始接著做了」。

「把規格開一開」，這麼說當然是輕描淡寫了。理論上，客戶，也就是告訴開發團隊究竟要開發出些什麼的那個（群）人，理應對於自己想要的東西是瞭若指掌。只要他們能清楚、精準的描述出他們想要的軟體長相，那麼開發團隊自然就能夠據以做出滿足他們需要的軟體。

可是這件事情難就難在，實務上，即使是主導需求規格的客戶，他們在需求分析的過程中，都時常遭遇到兩類型的困難：（1）無法精確、完備的描述出真正的需求（2）甚至連他們自己也不知道真正的需求究竟是什麼。

當然，需求分析這項工作的難處不僅止於此，我們在稍後還會再提及。正因為客戶在提供需求的時候會遭遇到諸般的難處，所以，在需求分析的階段，軟體開發團隊應該為客戶提供更多的協助，才能夠更順利地收集到最接近客戶實際需求的資訊。

需求分析沒做好的後果
倘若需求分析階段所收集到的資訊不正確或是不完備，開發團隊卻據以做為開發的基礎，那麼投入相當的人力及時間去開發，在開發中或甚至到最後才發現做出一個不能滿足客戶真正需求的軟體系統，那麼肯定會形成一場災難。
我相信，有不少人都有類似的
經驗，在開發過程甚至到了測試、驗收階段，團隊或客戶才發現做出來的軟體和預期的有所落差，接著衍生出眾多的變更需求，不僅讓開發團隊疲於奔命，不僅投入的成本攀升、在時程上也會有所延遲。

軟體需求或規格的變更，是軟體開發時所面臨的強大敵人，而如果能夠在源頭，也就是在需求分析的階段，盡可能找出接近客戶真正需要的需求，那麼，便能夠降低事後遭遇需求變更的機會，自然而然，可以減少因此而額外造成的人力及時間耗費。

以前曾經參與過一個專案，這個專案在臺灣做需求分析的工作，之後的開發則移到上海做後續的設計、實作及測試。分析的規格文件可以說是十分的詳盡，厚厚的一大疊，兼之以運用當時最流行的UML塑模技術。可是，即使如此，當上海開發團隊依據規格文件開發完成系統、交付回臺灣之後，準備開始進行使用者接受度測試時，客戶端的使用者才發現，做出來的東西和他們想像的不太一樣。而且，因為已經到了開發週期的尾端，這個時候才來開始修改系統，需要付出的代價更為沉重。

這一個例子不僅說明了需求分析的重要性，而且也說明了掌握客戶真實需求的難度。並不是你寫下足夠多的文件、用了最先進的塑模技術，圍繞在需求的種種問題就能夠迎刃而解。

有一些開發方法論，尤其是敏捷開發的方法，更是一開始就在站需求不容易掌握、容易改變的本質基礎上而設計的。有一部份原因也是因為要得到真正的需求，並且精準地加以描述，事實上是如此之難，所以，才會改以敏捷的方式來加以因應。當你知道想要獲得真正的需求是如此之難後，你才會以如臨大敵的態度來加以面對，因為所取得需求資訊不夠逼近真實所造成的傷害，也才能盡量消解。

檢視需求分析進行的流程
讓我們先來看看，一般需求分析的工作是如何進行的。

首先，軟體開發團隊會有專門的需求分析人員，安排對客戶端人員的訪談。當然，訪談的對象必須適當的選擇。該如何決定訪談的對象呢？一般來說，開發團隊會需要訪談（1）了解重要需求資訊的人（2）有權利及責任決定需求規格為何的人。

例如，當我們要開發一個薪資系統的時候，了解重要資訊的人，多半就包括那些在人事部門裡負責薪資計算工作的人員，因為他們最了解薪資計算的規則，以及薪資發放的方法。有時候，我們打算開發出一個前所未有的產品，那麼，真正了解重要資訊的人，就是那些注入各種新想法、規畫出這個產品的人。

在需求訪談的時候，有些對象可能是擁有需求資訊的人、有些則可能是即將成為未來系統使用者的人，此外，也有一些對象是能決定並且負責決定要做出什麼的人。

需求分析人員除了盡量從擁有資訊的人身上收集到各種資訊之外，也必須透過和能決定需求規格的人的訪談，來做最後需求規格的確認。總之，在訪談之前必須決定即將訪談的對象、同時安排訪談的計畫。當然，也可能在訪談過程中因為收集到更充足的資訊，因而決定針對對象及計畫做調整。

而開發團隊中負責需求分析工作的人員，則是責任重大。最理想的情況，是將這工作交付給經驗豐富、對技術層面知識有普遍性了解、在領域知識上也有一定基礎、而且擅長溝通技巧的成員來負責。

有了豐富的開發經驗，才能在客戶所提出的功能性需求之外，建議客戶所容易忽略的需求面向。例如，客戶可能只會關心薪資究竟如何計算，卻不會在意系統運作時是否有足夠的日誌記錄檔，允許日後檢視系統運行時的相關系統記錄。

同樣的，做過的系統夠多，自然就知道客戶在此刻所提出的需求還有什麼不足，日後還會衍生出什麼樣的需求。與其到了日後等待客戶的需求變更，不如在一開始協助客戶找出需求的全貌。

而若需求分析人員對技術層面知識有普遍性了解，自然能夠在第一時間判斷客戶所提出的需求在技術上的可行性及難度。必要時，可建議客戶採納變通的方式。而對領域知識的了解，更大大有助於和客戶之間的溝通。能說「行話」的需求分析人員，自然更容易了解客戶所遭遇的問題，也自然更容易建議適當的技術方案。

執行需求分析的人員能力是關鍵
從以上簡短的描述，就不難明白，需求分析工作不僅僅只是被動的收集需求，而更要主動協助客戶探索出真正的需求。因此，人際間的溝通技巧，不論是言語、文字、圖示層面上的，都是在需求分析過程中十分重要的。

需求分析是軟體開發中的關鍵階段，而負責需求分析的人員最好是經驗老道、技術知識廣泛、擅長溝通技巧的老手。意識到需求分析的困難、重視需求分析，就能踏出成功開發軟體的第一步。