『為什么需要功能需求』：    　
     因為當業(yè)務(wù)分析師理解了產(chǎn)品必須的功能后，他要用功能需求告訴開發(fā)者要構(gòu)建什么。

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

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

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

『優(yōu)質(zhì)功能需求的標志』：
     1、必須包含足夠的細節(jié)，讓開發(fā)者能夠構(gòu)造出正確的產(chǎn)品。　
     2、只需要需求分析師和利益相關(guān)者最少的澄清和解釋。

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