毫無疑問,這個階段是非常重要的環節。但是從這裡應該了解到，不管你採用什麼的設計
文件，都應該注意細節的問題。
因為每個公司的設計文件都不可能完全相同，所以，我們將脫離文件樣式來說說設計中
的細節問題。
case 描述。
對於專案中的每乙個case，當描述它的時候，最好也相應的使用另乙個文件來描述這個
case的資料庫操作過程：例如某個表需要查詢，某個表需要刪除。這樣的好處就是可以
保證至少資料庫操作是一定正確的。至於這個文件，最好是流程圖的樣式，用什麼工具
畫出來都可以。
為什麼我們需要額外的這樣乙個文件？繁多的文件對專案的開發和維護沒什麼好處。多
乙份文件，意味著當我們修改某乙個地方的時候，我們要相應修改的文件又多了乙個。
但是，這份文件還是非常必要的。因為在開發的時候，開發人員經常明白了case的描述，
但是卻使用了錯誤的資料庫操作--這樣的返工是多麼的糟糕！
下面我們來談談case的描述問題。在上乙個段落裡，我們已經說了最好需要額外的乙個
資料庫操作文件。其原因就是描述case的時候，很難既把業務邏輯說清楚，同時又把
資料庫操作說清楚。雖然有資料庫操作文件作為輔助，但是業務邏輯的描述同樣重要。
首先，要提高的就是文字水平--大家不要偷笑，你的文字水平未必有你想象的那麼好。
尤其是做外包專案的時候，當面對其他國家的語言的時候，你的描述水平是否有那麼好？
其次，就是條理要清晰，不要東講一些，西講一些，如果你自己都沒有清晰的條理，那麼
怎麼指望看設計的人能寫出正確而且高質量的**？
保證case描述的正確，除了通過pm，pl review 外，最好是交叉檢查case。通過交叉
檢查，可以很容易的發現的case描述的失敗的地方。
validate. 每個專案都會有validate,每個模組都會有，這個東西是如此的普遍，所以被認為很簡單－－我們只需要加乙個
檢查，來判斷條件，不符合的話就中止過程。
因為是如此的簡單，所以被很多人忽律，該如何去進行validate? 如何進行？很簡單，根據邏輯增加檢查就可以了。這是
普遍的想法。
但現實好像沒這麼簡單。
比如乙個普通的 edit 框，有的人可以先校驗輸入的字串是否符合長度要求，有的人可能先校驗是否為空－－這完全取決
於每個人的思維方式。
但是，專案卻不能允許如此的自由，乙個 edit 框，該是怎麼校驗的順序，就該怎麼的順序。所以，在專案的測試階段，我們發現了，
學多人開始按照測試用例修改校驗的方式，或者順序。
這是浪費時間而且無聊的事情，而且，修改順序或許會產生新的bug。
如何避免？或許在專案開始階段，team可以規定一些ui的校驗的標準，比如對於 edit,必須先校驗是否為空，然後校驗
是否包含特殊字元，然後校驗長度是否符合，等等。有了乙個標準，後期的rework 才不會很多。
我們可以看到，validatefactory 確定了校驗的順序，這樣，我們能保證整個team的ui的校驗過程一致。
或許還有更好的方法，不過我們要認識到，校驗－－不是一件簡單的事情。
詳細設計階段
團隊專案之詳細設計階段 1 任務描述 2 任務目的 1 任務描述 2 任務目的建立互動模型 階段報告 1.建立互動模型 建立專案平台 1.新建專案 傳入專案名稱 string 並將改名稱傳遞給業務邏輯層的定義設計模組。2.設定專案資訊 傳入專案的資訊，包括主題 日期 責任人等，將該資訊傳遞給業務邏輯...
概要設計階段 組裝測試計畫
專案名稱 組裝測試計畫 v1.0 版本號 擬 制 人 審 核 人 批 準 人 年月日 組裝測試計畫 1.引言 1.1編寫目的 說明編寫這份測試計畫目的，指出預期的讀者。1.2背景 a.待開發系統的名稱 b.列出本專案的任務提出者 開發者 使用者。1.3定義 列出本檔案中用到的專門術語的定義和外文首字...
概要設計階段 組裝測試計畫
doctype html public wcdtd xhtml stricten httpwwwworgtrxhtmldtdxhtml strictdtd 專案名稱 組裝測試計畫 v1.0 版本號 擬 制 人 審 核 人 批 準 人 年月日 組裝測試計畫 1.引言 1.1編寫目的 說明編寫這份測試計...