本書由本人編寫，於2014-09-09在百度閱讀首發，博客將轉載試讀部分的20%內容，以及非試讀章節的某些片斷。
電子版鏈接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6###
一個量化管理項目的一生
本章通過一個例子展示本書所述的量化需求分析與建模方法在項目中實際應用的情況。
注意本章所有數字均只需要兩個來源：本章中的配圖，業界的數據。配圖中的元素隱含了量化規則，只從其中某些元素的個數、樣式即可獲得量化數據。除此之外不需要任何其他額外信息，也不需要其他額外的估算或度量過程。
預防針
下面的例子中將會看到大量度量數據，對於曾經用過傳統估算、度量方法的讀者，可能會心生恐懼。
不過，全部這些數據，不是來自獨立的或者說額外的“度量和估算活動”，而是一種量化需求分析與建模方法的產物。在按照這種方法繪製完幾個簡單圖形並根據圖形元素編寫Word後，可以從Word目錄直接生成度量數據。配合本書提到的Word和Excel模板，全程只需要2分鐘就能自動計算得到規模、工作量、進度、某些類的數量、某些方法的數量、測試用例、質量……等數據，也就是本章所提到的所有數據。
第一天
產品經理興沖沖地走進會議室，高層經理昨天已經同意了包括“在已有電子商務網站上增加收發貨等子系統”的新版本提議，不過需要項目組儘量簡化功能，以逐步遞增功能的形式推進。
願景
儘管需求很不明確，但領導倒是提出了一些抽象的願景。比如其中一條是做一個“值得信賴的收發貨子系統”。一般團隊或許此時會一籌莫展，但這個使用QUML的團隊花費15分鐘討論繪製了這樣一張“角色-業務圖”：
買家在確認收貨後才，店主纔會和物流結帳，這樣就保證了物流“值得信賴”。儘管可能還有其他實現方案或者擴展功能——比如買家可以評價物流——但是團隊決定這個版本到此爲止。
實體，關係
10分鐘後，人們分析下面這張“實體-關係圖”中的數據是實現這個版本的充分必要條件：
這個實體關係圖可不是憑空來的。店主，物流，買家是願景圖裏邊的；結帳記錄來自“結帳”“收賬”兩個詞的賓語，而“發貨記錄”來自“發貨”“送貨”“確認收貨”三個詞的賓語。
規模，工作量
這個子系統中的2個業務數據（即實體，“結帳記錄”和“發貨記錄”）預示着2×平均35功能點=70功能點的規模（注：這裏不是我們口語中常說的“功能點”，而是與IFPUG和NESMA兼容的國際標準功能點，有嚴格的定義和很好的一致性、可比性），換算成人天差不多也正好是70人天左右的工作量——碰巧當前中國業界的生產率大約就是1功能點需要1人天——不過這是覆蓋從需求到上線所有活動的工作量。作爲開發團隊，他們感受到的只有一半左右，也就是35人天。
這個數據不會很準，但由於領導需要下午就要給出一個大致的工作量估計，因此團隊沒有進一步細化需求，而是轉而分析其他子系統。
整個版本
最終，團隊又用類似方法分析了所有其他這個版本的子系統（本例中未給出），最後估算出整個新版本總計需要400功能點，也就是大約400人天的工作量。不過，這是按照業界數據估算的結果，他們團隊決定按自己的生產率修正到300人天——這得益於他們已經統計和修正過自己的生產率數據——5個人工作60人天，也就是大約3個月的時間。團隊決定使用3個迭代來完成開發，最後一個迭代包括部署上線。