- 因為溝通的時間，人力和工時互換是不成立的，別用人月來衡量工作規模大小
溝通又可分為，訓練和相互交流
訓練的成本可以是線性關係，但相互交流花的時間可多了
所以為了趕上時程而增加的人力，通常不會只會讓進度更落後。
- 系統設計的時候，保有概念整體性是很重要的原則
寧可忽略掉新奇或更好的特色，來反映同一組設計理念
- 系統的目的是使用便利性，所以功能概念複雜度比才是系統設計的最終測試標準
好的設計不可以單獨偏重功能性，也不可只偏重簡單性
- 產品測試小組代表顧客，就是為了挑出產品毛病存在
隨著時間的投入，細心的產品測試人員將找出設計意圖並未正確傳達之處，也就是設計的決策沒有被正確了解或準確實作的地方
基於這個理由，測試小組絕對有必要與設計意念傳達的過程相結合，並且必須在造其跟根設計的工作一起同時進行
- 在大部分的專案中，第一次出爐的系統絕少是有用的
因此，無需考慮是否要做一個試探性的系統，然後把他丟棄，因為這是必然的問題
所以應該要預先規劃去做一個本來就要丟掉的試驗品
在規劃時程的時候，把必然的一次失敗納入正式計劃之中。
- 規劃軟體開發專案的文件
- 目標
- 產品規格
- 時程
- 預算
- 場地配置
- 組織編制圖
- 為使用程式而寫的文件
- 目的
- 環境
- 程式要在哪種機器上跑？
- 硬體和作業系統的組態該如何設定？
- 輸入值域與輸出值域
- 欲達成的功能與使用的演算法
- 輸出入格式
- 執行過程中的指示
- 包括運行正常時，或因異常而終止時，在控制台或任何輸出裝置上應該要看得到的任何提示
- 選項
- 使用者在功能上有哪些選擇彈性？
- 這些選項該如何正確的加以指定？
- 執行時間
- 對於某個工作，在某個組態所指定的空件大小限制之下，程式要花多少時間來完成？
- 輸出結果的精確度與檢驗方式
- 預期的結果必須精確到什麼程度？
- 跟這種精確度相搭配的檢驗方式為何？
- 將文件維護的負擔剪到最小
- 借助那些基於語言的要求而必須存在的語
儘可能容納更多訊息在裡頭
標籤、宣告、符號名稱都可以用來表達某些函意
- 善用留白或固定格式來增加可讀性，表現出從屬和巢狀的關係
- 以註解的形式在程式中加入一些註解
但許多程式為了這個逐行加入註解，這更會讓人感到困惑
