為了避免直接回答您的問題時，可能横生的枝節，我就單刀直入地從“什麼是軟體？”這個最基本的問題談起。

在軟體工程的書中，一開始總會說到：軟體的組成包括：演算法(程式碼)、資料與文件。只要會寫程式的人都能接受這三樣構成要素的前兩項，但是軟體工程的書對“文件”為何成為軟體的第三樣構成要素卻著墨不多。因此，很多人都不知到“文件”所以成為軟體構成要素的“所以然”。當然也就不正視其重要性，其結果就是：“開發軟體的工作”，在這些人的心中就等同於“寫程式”。是嗎？“開發軟體”就真的是等同“寫程式”嗎？

2000年8月31日天下文化出版一本書名為『數位式競爭』(譯自Secrets of Software Success)的書。該書中有句話這麼寫著：「軟體」說穿了，就是以數位形式呈現的知識。這句話很有用，也很重要。如果，我們接受這樣的看法。我們就可以進一步地演繹為：軟體開發的工作就是將原本存在於人腦或者以文字、圖形存在於書面資料中的“高度抽象化的知識”，經過一連串轉換的過程，降低它的抽象程度，直到在目標機器上能夠以數位化呈現時為止的一人或多人的心智活動。而文件就是此一過程中人類心智活動的結果，它代表著該知識(要以數位化形式呈現的知識，後文簡稱其為“目標知識”)“不同抽象程度的化身或不同面向的描述”。

目標知識的不同抽象程度的化身，就是開發活動當中產生的技術文件。如：軟體需求規格書、軟體設計說明書是也。目標知識的不同面向的描述，就是在目標機器上運用該知識的方式，如：使用者手冊、操作者手冊、維護手冊是也。

將目標知識的不同抽象程度的化身，具體以書面形式(文件)呈現出來的目的就是：“檢驗”與“溝通”。因為，可憐，只要是人都會犯錯，所以，它必須被“檢驗”以確保於轉換的過程當中沒有出差錯而“走樣”。另外，轉換的過程通常也不是一個人完成的，所以它要被書面化以便和其它人“溝通”。還有，即使它是一個人開發的，也因為這個過程不是一天就完成，又，人是健忘的，所以要將它書面化以便和未來（三十天後）的我“溝通”。

如果我們認同以上觀點的話，就會同意：軟體開發的過程不等同於“只是寫程式”。我們也會同意“寫文件的人”就是“開發軟體的人”，而不是“另外找的”寫文件的人。

有了以上的認識，現在回答您的問題如下：

小專案要轉換的目標知識的抽象程度，不會比大專案的抽象程度“低”，因此，它仍然要經過相似的轉換過程以降低它的“抽象程度”。雖然，小專案要經過與大專案類似的過程，但是，它的規模小、複雜度低，所以，小專案花在寫文件的人力、時間與成本也就小。所以，專案的規模(大小)影響的只是文件的“總頁數”，大的專案或複雜的專案要寫的文件的“總頁數”比小專案的多，如此而已。

如果，我們打算於軟體開發的過程當中維持良好有效的“溝通”，並在每一個轉換過程中進行有效地“檢驗”，以確保不會發生“走樣”的情形。那麼，“寫文件”是必要的，也是開發軟體人員每天必須執行的工作，而不是另外找人專門寫文件。還有我們也要了解，在我們“寫文件給別人看”的同時，我們也在“看別人寫的文件”。“寫文件”與“看文件”是軟體開發人員每日的工作，“寫程式”也是“寫文件”，寫給“編譯器“看的文件。軟體開發人員如果不寫文件，是無法完成其工作的。它與專案的規模、時程的長短無關，它也是客戶付錢給我們的唯一理由：把他擁有的或打算擁有的“目標知識”以不同的抽象程度(包括數位化的形式)呈現出來。

最後，我們要再了解，將目標知識由某一抽象程度轉換成較低的抽象程度，所使用的方法，會因目標知識當時所具有的抽象程度不同而不同。簡單的說就是： “將使用者需求轉換成軟體需求規格”所用的方式與“將軟體需求規格轉換成軟體設計文件”所用的方式是不同的專業技能。所以，長遠來說，把這些工作分派給不同的人員執行是較符合經濟效益的。因為，唯有專業分工才能“累積專業技能”…

到此相信您已能夠充分理解些觀點，祝您早日踏上步向成功的正途！

軟體品質協會專案管理師 周茂松 敬上