《例項化需求》閱讀筆記（2）--Roadmap素描

第二章給出了做到例項化需求的關鍵過程模式： 從目標中獲取範圍---->協作定製需求說明---->舉例說明----->提煉需求說明----->不需要修改需求說明的自動化驗證------->頻繁驗證----->演化出一個文件系統。

從目標中獲取範圍： 交付團隊不應該指望使用者直接給出範圍或者解決方案，因為客戶大部分時候並不具備提供良好需求的專業能力，且團隊擁有的專案知識可能也被浪費了。因此需要幫助使用者找出真正的目標，並通過協作共同界定專案範圍。 分工是這樣：使用者專注於傳達所需功能希望達到的目的，以及他們期望由此帶來的價值，團隊根據使用者給出的資訊提出解決方案。 評：僅第一步就很難做成，需求獲取也是門大學問，要做好這一步，首先團隊中得至少有一個能力超強的需求人員，不過見到的好的需求人員真的很少。

協作制定需求說明： 成功的團隊不會依賴於某個人獨自去收集正確的需求，而是會與商業使用者一起制定解決方案。不同背景的人擁有不同的想法，他們會憑藉自己的經驗解決問題。能夠讓每個人更大程度的參與到交付活動中去。 評：good idea！讓大家八仙過海各顯神通顯然最棒，不過構建這麼一個團隊卻非容易的事情。

舉例說明： 自然語言會有歧義，會有上下文相關內容，有些內容則需要有專業知識做背景才能懂，會造成客戶與團隊、團隊內部理解不一致，因此需要某種程式語言來描述需求。 對於成功的團隊，不會一上來實現全部需求，而是先確定出那些描述預期功能的關鍵例項。如果關鍵例項容易理解和溝通，就可以被有效用作清晰和詳細的需求。

評：英文標題是：Illustrating using examples ，感覺翻譯成用例項來描述更好一些。 譯文有一段讀著不順的地方： 在首次使用用程式語言實現需求的過程中，成功的團隊不會等待需求被精確表述，而會舉例說明需求。 原文為： Instead of waiting for speciications to be expressed precisely for the irst time in a programming language during implementation, successful teams illustrate speciications using examples.

我覺得更好的翻譯應該為： 成功的團隊不會一開始就將所有需求精確的用某種程式語言表達出來，他們會舉例來描述需求。

提煉需求說明： 提煉從集體收集到的資訊，濾去雜質。為開發和測試建立一個具體的、精確的上下文。以適量的細節來定義目標，以便實現和驗收。可以當做交付的驗收條件。只有當所有例項在系統中都可以正常工作時，開發才算完成了。

不需要修改需求說明的自動化驗證方式： 這一段列舉了需求文件和自動化指令碼不一致帶來的問題。指出好的團隊會把所有人員都可以理解、訪問的自動化例項變成可執行的需求說明。需求和自動化指令碼合一，如果需要修改，只改一處就可以了。

這一段給出了兩個工具,能輔助實現這一想法： FitNesse：http://fitnesse.org Concordin：www.concordin.org 過兩天試用一下。

評：標題原文是Automating validation without changing speciications 中文標題看著疑惑，檢視原文，感覺翻譯的有些，自己翻譯成：不需要修改說明的自動化驗證方式。說實在的，這一段中英文都拗口，作者想表達的無非就是上邊標綠的那句話！

頻繁驗證： 通過頻繁檢查所有可執行的需求說明，團隊能夠快速的發現系統和需求說明之間的任何差別。由於可執行的需求說明容易理解，團隊可以喝商業使用者討論這些改動，並決定如何處理。他們可以不斷的同步系統和可執行的需求說明。

評：這個沒設麼好說的，持續整合，每一個團隊都應該追求的目標。最難的地方其實就在指令碼的穩定性和可維護性了。

演化出一個文件系統： 不斷改進上邊這些步驟，一個活文件系統就逐漸成形了。活文件清晰明瞭，並簡單可靠 評：說白了又是一個PDCA

文章給出了一個電商的例項，讀下去很順，貌似有一定可行性，起碼是一件能做得下去的工作，不過不知道在其它種類軟體是否合適。

爭取每週寫一兩章的筆記和分析，在中途引入一個以前曾經做過的專案或者正在做的專案虛擬的實現一下，看看可行性。

by @skytraveler