查這個詞的人，有的是在準備考試或報告，需要知道每個階段的定義；有的是實際要主持一個專案，想弄懂順序怎麼排、每一段該產出什麼才算完成。教科書上的方塊圖不難背，難的是知道方塊與方塊之間交出去的是什麼、由誰確認、確認不了會發生什麼事。這篇按實際專案的走法，把各階段的產出、負責的人、以及最常在哪裡翻車寫清楚，最後再談常見的幾種模型差在哪，以及該怎麼選。
它是一場責任接力，不是牆上的流程圖
每個階段的意義，在於交出一份下一棒的人可以直接使用的東西。需求階段交出的是可以被驗證的描述，設計階段交出的是可以照著做的結構，開發階段交出的是可以被測的成品，測試階段交出的是可以決定上不上線的判斷依據。
如果某一棒交出的東西下一棒看不懂或不敢用，問題不會停在原地，而是被往後推，到了測試或上線才爆開。實務上多數的延誤，追根究柹都是前面某一段交接不完整，而不是後面的人做得慢。
需求階段：把「想要」翻成可以驗收的描述
這個階段要問出來的不是功能清單，而是使用情境：誰在什麼時候、為了完成什麼事、會來使用這個系統，過程中會遇到哪些例外。功能是情境的結果，不是起點。
產出通常包含角色定義、主要流程、功能範圍、明確排除的項目，以及每一項的驗收條件。最常見的錯誤有兩個：一是只訪談了主管而沒問實際操作的人，做出來的東西沒人用得順；二是只描述順利的流程，忽略取消、退回、重複送出、資料錯誤這些例外，等到開發中期才逐一補，時程自然失控。
設計階段：先定資料與流程，再談畫面
設計要處理的有三塊：資料怎麼存、系統怎麼分工、使用者怎麼操作。順序很重要，資料結構沒定就先畫畫面，經常會做出資料放不進去的介面。
這個階段還要決定跨系統的界線：哪些事自己做、哪些呼叫外部服務、資料在哪一邊為準。這些決定越晚做，改動的成本越高。常見的地雷是把設計等同於視覺稿，只討論顏色與版面，卻沒有人確認權限怎麼分、資料量大了會怎樣、對外介接失敗時畫面要顯示什麼。
開發與測試怎麼交錯進行
把開發全部做完才開始測，是風險最高的排法。比較穩的做法是按功能區塊分批完成，每完成一塊就先自行驗證，再交給測試。這樣問題會分散在整段期間被發現，而不是集中在尾聲。
進度的呈現方式也要注意。用百分比回報很容易失真，長期停在接近完成卻遲遲不能交付。改用「哪些功能已經可以實際操作」來描述進度，會誠實得多。這個階段最常出錯的地方，是每個人在自己的環境上都正常，合起來卻不能運作，原因通常是環境設定與版本沒有統一管理。
上線切換那一天要有一份計畫
上線不是把程式放上去而已，它是一次有時間壓力的作業。事前該寫下來的包括：切換的時間點與影響範圍、舊資料怎麼轉入與怎麼驗證正確、要不要停機、通知誰、當天誰在線上待命、出狀況時退回舊系統的條件與步驟。
最容易被跳過的是退場方案。沒有事先想好怎麼退回去，真的出問題時會在壓力下做出更糟的決定。另外，資料轉換一定要先在測試環境完整跑過一次，並且對筆數與關鍵金額做核對，不能等到當天才第一次執行。
上線之後才開始的維運與退場
系統上線是維運的起點。這個階段要有的機制包括：問題回報的窗口與分級、錯誤紀錄的保存與查閱方式、定期備份與還原演練、相依元件的更新計畫。備份沒有做過還原測試，等同於沒有備份。
生命週期的最後一段是退場。當系統被取代或不再需要時，要處理資料保存與銷毀、帳號停用、對外介接的關閉、以及仍需查閱的歷史資料要怎麼留存。這一段在規劃初期就該想過，尤其是資料保存年限與個資處理的要求。
瀑布、疊代與持續交付的差別
- 瀑布式：階段依序進行，前一段確認後才進下一段。適合需求穩定、驗收依據明確、有合約與稽核要求的專案。缺點是需求誤解要到很後面才會被發現。
- 疊代式：把系統切成多個小批次，每一批都走完設計到測試，並在過程中依回饋調整。適合需求還在成形的情況，代價是需要使用者持續參與，若沒有人能定期做決定，反而更亂。
- 持續交付：在疊代的基礎上，把建置、測試與部署自動化，讓小幅改動能頻繁上線。適合長期演進的系統，前期要投入建立自動化與監控的成本。
選擇的關鍵不在哪個比較先進，而在需求的穩定度、使用者能不能持續參與、以及外部是否有固定的驗收與合約節點。多數專案實際採用的是混合做法：需求與設計走得紮實一些，開發與測試以小批次疊代進行。
常見問題
小型專案也要走完整個流程嗎？
階段不能省，但產出的形式可以簡化。再小的專案都需要有人確認需求範圍、想過資料結構、驗證過功能、規劃過上線與備份。差別在於文件可以從厚厚一本變成幾頁重點，甚至一份共同編輯的清單。真正危險的不是文件薄，而是根本沒有人回答過那些問題。
需求文件要寫到多細才夠？
判斷標準是：一位沒有參與討論的工程師看完，能不能開始做，而且做出來的結果符合預期；驗收的人看完，能不能逐條檢查。達到這兩點就夠了。過細的文件在需求變動時反而成為負擔，重點應該放在流程、例外情況與驗收條件，而不是逐字描述畫面上的每個字。
測試一定要找開發以外的人做嗎？
開發者的自行驗證不能取代測試，因為他會不自覺地照著自己設計的路徑操作。至少要有一位理解業務流程的使用者參與，用真實情境去試，特別是輸入錯誤資料、中途離開、重複送出這類狀況。規模較大或風險較高的系統，才需要專職的測試角色與較完整的測試計畫。
採用疊代的做法就不用寫文件了嗎？
不是。改變的是文件的時機與形式，不是有沒有文件。疊代做法仍然需要記錄下決定了什麼、為什麼這樣決定、驗收條件是什麼，只是這些內容通常隨每個批次逐步累積，而不是一次寫完。完全沒有紀錄的專案，換人接手時會付出很高的代價。
專案延誤時，該砍功能還是延後時間？
先回頭看需求階段列出的優先順序。如果當初有分出「沒有它就不能上線」與「可以之後再做」，決定會容易得多：保留前者、延後後者，讓系統先進入實際使用。若兩者都沒分過，那麼延誤本身就是在告訴你，需求階段的優先排序沒有做完，這時應該先補上這件事再談時程。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
相關主題
下一步
如果你正在評估「系統開發生命週期」相關的規劃，可以參考我們的系統開發需求討論，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。
