今天我閱讀了《例項化需求》的1-3章。
第一章主要是講例項化需求的好處。例項化需求說明是一組過程模式，他幫助團隊構建正確的產品。
使用例項化需求說明，團隊編寫的文件恰到好處，在短迭代或基於流的開發中可以有效地協助變更。
《例項化需求》這本書不是以理論的方式來構建乙個案例來闡述例項化需求說明的好處，而是來自
於那些來自於那些大大受益於例項化需求說明的團隊。
例項化需求可以更有效地實施變更，主要是通過活文件。活文件是系統功能的乙個資訊源，與程式
**一樣可靠，但更容易使用和理解。他幫助團隊共同分析變更所帶來的影響並討論潛在的方案。
長此以往，可以使需求說明和實施變更更有效。
例項化需求說明可以改善互動團隊成員之間的協作，促進商戶更好的的參與，並為之交付提供清晰
客觀的目標--大幅提高產品的質量。
例項化需求說明還可以減少返工和團隊的更好協作。例項化需求說明能幫助乙個團隊建立乙個協作
制定需求的過程，這可以減少迭代中期的問題。然後《例項化需求》這本書中的實踐讓團隊清晰地
定義乙個可以普遍理解和客觀衡量的目標。
讀完這一章，我知道的例項化需求說明在實際專案開發裡面的重要性和意義。
第二章主要講的是例項化需求說明的關鍵過程模式。例項化需求說明是一種模式，它可以協助軟體產
品的變更，確保正確的產品能夠有效的交付。其主要內容是先從業務目標中獲取範圍，協作制定需求說
明並舉例說明。提取關鍵例項的需求說明，然後進行自動化驗證不修改需求說明並頻繁驗證。最後演進
出乙個文件系統(活文件）。
讀完了這一章，我們在實際開發過程要採用適合自己開發的實踐來實施過程模式。
第三章主要介紹文件模型及其好處。例項化需求說明的過程和工件有兩種流行的模型:以驗收測試為中
心的模型(通常稱為atdd或a–tdd)和以系統行為規範為主導的模型(通常稱為bdd)。其中以文件為中
心的模型可以幫助團隊避免長期維護可執行需求說明時最常見的問題，隨著時間的推移這種文件可以促
進軟體的革新，並避免由於缺乏共享知識而造成的維護問題。將活文件看作單獨的工件，與交付系統同等
重要。團隊還可以避免對它投資過度。他們可以事先討論準備花多少時間去構建活文件系統，以免掉入這
樣乙個陷井:對測試進行鍍金，卻犧牲了主要的產品。
讀完這一章，我們在例項化需說明中，要重視活文件的構建，並且要將它作為交付過程中的重要工件。
例項化需求 概念
最近一段時間在關注一種新的敏捷模式，當然這裡說新，是由於目前很少看到有專案在應用，其實這種模式很早就已經誕生了。乙個偶爾的機會，在苦尋敏捷測試的過程中，無意中看一本書，關於如何提高敏捷過程中需求 開發和驗收的測試效率，讓我很是感興趣，這本書名 例項化需求 團隊如何交付正確的軟體 可能是由於翻譯的原因...
c primer閱讀筆記 13章 1
1 複製建構函式 賦值操作符和析構函式總稱為複製控制。編譯器自動實現這些操作，但類也可以定義自己的版本。2 複製建構函式是一種特殊建構函式，具有單個形參，該形參 常用 const 修飾 是對該類型別的引用。當定義乙個新物件並用乙個同型別的物件對它進行初始化時，將顯式使用複製建構函式。當將該型別的物件...
閱讀第13至17章
第十三章 軟體各種測試方法的價值所在之處？除了書本上的所列舉的測試之外，還有什麼測試是適合於團隊開發的？第十四章 測試人員對質量保障起決定性因素嗎？第十五章 主要講的是軟體的發布，在發布之前要做檢測，如何能把所有都檢測的徹底？第十六章 it行業的創新 我們從g number這個遊戲可以領悟到3點 1...