posts - 187,comments - 176,trackbacks - 0

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

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

『需求与解决方案』:
     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)可以把过程模型作为基础,然后根据图中的每个活动编写原子需求。

posted on 2014-05-10 11:06 cheng 阅读(978) 评论(0)  编辑  收藏 所属分类: 需求分析

只有注册用户登录后才能发表评论。


网站导航: