『为什么需要功能需求』：    　
     因为当业务分析师理解了产品必须的功能后，他要用功能需求告诉开发者要构建什么。

 『功能需求定义』：
     功能需求指明了产品必须做的事情，即产品为了满足它存在的根本理由而必须执行一些动作。

『需求与解决方案』：
     1、需求：产品需要做什么来支持拥有者的业务
     2、解决方案：需求的技术实现
     注意：
          1）我们在描述如何编写需求时，最重要的是要理解真正的业务需求，同时沟通这种需求，确保构建正确的产品。
          2）不要去尝试打造技术方案，而是要指定技术解决方案必须做的事，如何实现结果是设计师的事情。

『如何发现功能需求』：
     1、将编写好的PUC场景与利益相关者取得一致意见。 
     2、针对每一个步骤问一个问题：“为了完成这些步骤，产品必须做什么？”
     3、穷尽所有步骤后，就为这个PUC写好了功能需求。    　
     4、经验值，从一个步骤导出的需求数量通常要少于3～6个。多了表示要么需求粒度太细，要么用例本身很复杂。少了表示要么场景的粒度太细，要么需求粒度太大。
　      备注： 　　　
           1）PUC场景的价值在于，它让你、利益相关者和开发者对功能有概括的理解，再针对它编写原子需求。
           2）场景中的步骤是业务利益相关者可以识别的，因为你用利益相关者的语言编写了这些步骤。
           3）这意味着它们程度较高，封装了产品功能的细节。将每一步的细节当做它的功能需求，你现在的任务是通过编写功能需求来展示这些细节。

『优质功能需求的标志』：
     1、必须包含足够的细节，让开发者能够构造出正确的产品。　
     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）可以把过程模型作为基础，然后根据图中的每个活动编写原子需求。