＊＊ 本文同步發表於 FB 社團－軟體設計鮮思維 ＊＊
什麼叫做「Waterfall (瀑布式)」文件？
就是文件整理看起來很用心的樣子，經由不斷地開會與確認諸多細節，然後在某次的會議決定階段告一段落，就給予該文件一個版號 (0.1, 0.6, 0.8 .....)。
所以，一個功能模組或作業流程，經過了幾次的版號更新，最終總算得以定案，然後再交付給 PG 據此撰寫程式碼。
不管大或小的單位，稍有組織性重視文件設計 (得以保存與傳承企業資產，其實是好事)，幾乎就是採以這類 "瀑布式" 的開發模式。
如果這樣能順暢移轉至程式寫碼，那當然沒有問題。但是，需求分析其實是一種假設與期望，越是要求精確，越是不容易釐清。
那麼，為何精確度的細節非得要在文件分析階段就要求完整呢？ 為何不搭配每一個階段的文件分析告一段落甚或當下就寫成程式碼呢？
每一次版號的演進，文件與程式碼從功能框架的較大目標範圍，再逐漸地往細節 (即精確度)貼近。
簡而言之，設計文件與程式碼本來就是「一體兩面」！設計文件引導程式碼的開發；程式碼的修正更新文件原來的假設。
所以，現實上當文件的版號制訂為最終版時，那麼，程式碼應該也是接近完工了。
為何不這樣作？這樣不是輕鬆又愉快？ 其中一個很大的問題就在於，諸多實作的程式開發人員不太容易掌握所謂的「不確定性」開發態度。也就是說，如果沒有提供很精確的細節，開發人員已經不知道要如何寫出程式碼。
總之，各類角色的開發人員，對於軟體開發的最重要修煉就是要懂得先學會如何抓到「大」的主題 (topic)，再來才是往「細」的程序/邏輯/欄位 作精。
