用 6 個思考脈絡 I.N.V.E.S.T，更好有條理地撰寫和檢視文件
前文有提到好的文件是非常重要的
這裡介紹用 I.N.V.E.S.T 這六個點來檢視一份文件的撰寫，是否涵蓋夠多的資訊
Independent 獨立
一個需求文件，當它可以越獨立時，它可以越容易被評估和執行。一個很好的檢視方式是，這些不同需求文件的順序是否是可以被調換的。一個夠獨立的需求文件，應該是可以有彈性被動態調整實作時間和順序。
Negotiable… and Negotiated 保持協調彈性並已協調
一個好的需求文件，應該是可以保持協調彈性的。在文件中詳細描述客戶／用戶對需求的描述( 專注在 What )，並保留空間給後續討論要如果達到這些需求 ( 討論 How 的空間 )
Valuable 有價值的
一個需求文件開出來，它必須是有價值的，這裡並不要求每個人都覺得有價值。它必須對客戶有價值，有時工程師會有提出必要且合理，但也應考量是否對客戶的價值也是一樣重要。
除了從客戶認為有價值來看，還可以從幾個維度來思考：
1. Strategic 有策略價值：如果不做這件事情，我們將隨著時間失去市場優勢。
2. Compliance 合規需要：如果不做這件事情，我們將有可能違反法律。
3. Revenue Generation 可產生獲利：如果不做這件事情，我們將錯失賺取市場利潤的機會。
4. Cost avoidance 避免提高未來成本：如果不做這件事情，我們未來將會付出更多錢。
5. System stability 系統穩定：如果不做這件事情，我們將會曝露在系統不穩定或無法正常提供服務的風險。
Estimatable 可估計的
一個好的文件應該是「可被估計的」，這裡不是要精準的估出幾個人做幾個禮拜，是需要可以拿來和其它需求文件比較和排序的。越大的需求文件，或是越不獨立的需求文件，都將讓估計和衡量變的很困難。
Small 夠小
好的文件應該盡量夠小。通常會用可被完成的時間來衡量，至少是一個人一週內能做完 (甚至更嚴格會是一個人幾天內能做完 )。超過這個範圍，會讓一張需求文件變的很難清楚地完成和測試。例如一個一次需要用一個月來實作的功能。
Testable 可測試的
當開始撰寫一個文件，代表一個承諾：「我非常清楚對於我想提出來的功能或改變，我知道它該被如何檢驗」
多數的團隊都認同，當我在實作之前，就知道一個功能／修改會怎麼樣被測試，團隊可以更精準的交付功能。
“可測試性” 一直以來都是最能衡量一個需求描述好與壞的關鍵。事實上，越早就規劃好如何測試，可以幫助團隊認知這個功能到底有沒有解決問題。
找到更多我的資訊可以到這 mhtsai
