『為什么需要功能需求』：    　
     因為當業務分析師理解了產品必須的功能后，他要用功能需求告訴開發者要構建什么。

 『功能需求定義』：
     功能需求指明了產品必須做的事情，即產品為了滿足它存在的根本理由而必須執行一些動作。

『需求與解決方案』：
     1、需求：產品需要做什么來支持擁有者的業務
     2、解決方案：需求的技術實現
     注意：
          1）我們在描述如何編寫需求時，最重要的是要理解真正的業務需求，同時溝通這種需求，確保構建正確的產品。
          2）不要去嘗試打造技術方案，而是要指定技術解決方案必須做的事，如何實現結果是設計師的事情。

『如何發現功能需求』：
     1、將編寫好的PUC場景與利益相關者取得一致意見。 
     2、針對每一個步驟問一個問題：“為了完成這些步驟，產品必須做什么？”
     3、窮盡所有步驟后，就為這個PUC寫好了功能需求。    　
     4、經驗值，從一個步驟導出的需求數量通常要少于3～6個。多了表示要么需求粒度太細，要么用例本身很復雜。少了表示要么場景的粒度太細，要么需求粒度太大。
　      備注： 　　　
           1）PUC場景的價值在于，它讓你、利益相關者和開發者對功能有概括的理解，再針對它編寫原子需求。
           2）場景中的步驟是業務利益相關者可以識別的，因為你用利益相關者的語言編寫了這些步驟。
           3）這意味著它們程度較高，封裝了產品功能的細節。將每一步的細節當做它的功能需求，你現在的任務是通過編寫功能需求來展示這些細節。

『優質功能需求的標志』：
     1、必須包含足夠的細節，讓開發者能夠構造出正確的產品?！?br />     2、只需要需求分析師和利益相關者最少的澄清和解釋。

『優質功能需求的要素』：
     1、細節程度和粒度
          1）需求由一個單句寫成，只有一個動詞。如：產品將接收一個調度日期（如果調度日期不是今天也不是明天，產品將發出警告）。
          2）使用一致的形式來編寫需求描述（‘產品應該/必須/將......’是最常見的），并使用單獨的屬性來說明需求的優先級。         　　
     2、給需求添加‘理由’，說明需求為什么存在。好處：　
          1）不僅讓開發者有機會構建最好的解決方案，而且也告訴測試人員需要在測試這項需求上投入多少工作量。      　　　　
          2）向未來的維護者說明了需求一開始為什么會存在   　　　　
          3）有助于克服不小心寫下解決方案，而不是真正的需求。     　　
     3、收集常用的術語，在數據字典中定義術語的含義，為團隊提供共同的語言。
     4、針對每個PUC場景中的[異常/可選]步驟編寫功能需求（即確定產品完成這個步驟必做的事）。    　　
     5、針對有條件的需求（只有在特定的處理環境下才會發生）編寫功能需求
     6、避免二義性的方法：       　　　
          1）語言本身有很多一詞多義的情況。如：‘產品要顯示未來24小時的天氣預報’還是‘它必須顯示某種天氣情況并持續一天’？
          2）雖然所有東西都有可能存在二義性，但是場景為需求設定了上下文，從而減少了這種風險。
          3）在數據字典中漸進地定義術語，將在很大程度上消除二義性。
          4）消除需求中所有的代詞，用主語或賓語取代它們，指明所代稱的東西。
          5）編寫一項需求時將它大聲朗讀出來。如果可能，讓一個同事把它朗讀出來。與利益相關者確認你們都把需求理解為相同的意思。
     7、對于技術需求（純粹因為所選擇的技術而產生的）建議將它在一份單獨的規格說明書中記錄下來，要么清楚的指出它是技術需求，與業務需求記錄在一起。
     8、按用例對功能分組，好處是容易發現相關的需求組，也容易測試功能的完整性。
     備注：這里是指編寫需求的描述，真正的需求將在編寫驗收標準時展現出來，在那之前，好的描述和理由是值得的，也足夠了。
   
『描述產品功能的其他方式』：  　　
     1、利用BUC場景添加實現細節來作為規格說明  　　　
          1）針對預期的產品是常規產品，大家對業務領域非常熟悉
          2）需求分析師和開發者很有經驗，并且愿意合作。
          備注：
              1.對場景進行改寫時要讓場景中的步驟體現出產品的視角，需求分析師和開發者、測試者必須相信，他們能夠基于這種增強的場景編寫和測試該產品。
              2.如果產品構建要外包給外部供應商或組織機構中的其他部門，就不要采用這種方法。對于外包，最好通過編寫原子功能需求，減少誤解的可能性。
    2、用戶故事
          1）它是編寫功能需求的一種方式
          2）用戶故事形式‘作為[角色]，我想要[功能]，這樣就能[使用該功能的理由]’。    　　　
          3）用戶故事通常由產品擁有者（客戶的代表）寫在故事卡片上，產品擁有者是敏捷團隊的一部分，代表業務的視角。
          4）故事卡片的意圖不是要指定需求，而是作為需求的起點，或占位符。在開發過程中，通過開發者和利益相關者之間的對話，會發現這些故事。
          5）故事通常寫在卡片上，開發者會在卡片上標注他們的詳細需求，以及必要的測試用例。
     3、業務過程建模    　　　
          1）如果你創建了活動圖（或其他類型的過程模型），那么考慮它們是否可以和過程描述一起作為功能需求。和文字場景相比，利益相關者更容易適應圖。
          2）流行的技術有UML活動圖、BPMN過程模型圖、數據流模型
          3）可以把過程模型作為基礎，然后根據圖中的每個活動編寫原子需求。