posts - 188,comments - 176,trackbacks - 0

『定义』:
     需求评审已测试并接受了单项需求,它们被允许进入规格说明,现在需要评估规格说明是否完整。这种复查可以迭代,最好每次针对一个产品用例(PUC)的需求。

『关于需求完整性审查』:
    一种相当有效的规格说明复查方式,它是一个正式的过程:  
    1、指派一名协调人(可能是业务分析师),负责安排审查和分发资料。
  2、建立最容易犯的错误的检查清单,你会在后续的审查中扩充这份清单。
  3、给审查者一些时间来阅读文档,准备审查。
  4、将审查限制在2小时以内,审查一天不超过2次。
  5、审查人数为3~8人

『需求完整性复查包含以下几个方面』:
    1、确定是否遗漏了需求   
    2、排列需求优先级,这样构建者能理解需求的重要性和紧急性。
    3、检查需求之间的冲突,这会阻碍一项或多项其他需求的实现。
    4、预估构建的成本(管理层执行的任务)
    5、评估项目所面临的风险(管理层执行的任务)

『确定是否遗漏了需求』:
    1、定义上下文范围  
    2、识别业务事件和‘无事件’,无事件指如果基本事件没有发生所引起的事件。如:基本事件‘卡车处理了一条道路’,但如果卡车没有处理那条道路,会发生什么情况?工作必须做些事情,它就是无事件(它发生是因为另一个事件没有发生),如‘到了监控道路除冰的时间’。工作对这个无事件进行响应,将检查道路是否按照指令进行了处理,如果没有处理,将‘对未处理的道路进行提醒’。
    3、为BUC建模,利用你的模型展示BUC的功能,通过这些信息,你可以决定功能要用到的存储数据。  
    4、定义业务数据,构建正研究的工作所需要的存储数据的模型(类图、实体关系模型、关系模型或其他)。
    5、CRUD检查(每个数据类都必须被创建Created并被引用Referenced),有些也被更新Update或被删除Delete。创建一个CRUD表,以显示是否每个类都有相应的动作。这些动作是业务用例(BUC)执行的,所以这一步能揭示遗漏的事件。   
 注意:如果发现了遗漏事件,你必须重新访问利益相关者,找到关于这些事件的更多知识。如果你确定了这些事件,更新上下文范围图,将它们加入事件列表,更新CRUD表,继续该过程。
    6、保管人过程检查,分为基本过程和保管人过程   
        1)基本过程是指那些与系统存在的理由有联系的过程,如:你递上信用卡来完成支付,信用卡公司将记录支持的金额和其他细节。
        2)保管人过程是为了维护(保管)存储数据,这些过程对数据进行更改,原因只是为了保持数据最新,它们不属于基本过程。如:你搬了新家、通知信用卡公司变更地址,公司相应地更新记录。
        3)检查保管人过程,就要查看类模型和CRUD表,确保有足够的业务事件和相应的过程来维护工作存储的所有数据。如果类包含可更改的属性,那就可能有一个保管人业务事件来修改这些属性。  
    7、重复直到完成,将第1~6步骤做迭代(确定业务事件、对业务用例建模、加入类模型、检查类被创建、引用、更新和删除)。

『排列需求优先级』:
    1、影响优先级的因素
        1)实现的成本
        2)对顾客或客户的价值
        3)实现产品所需的时间
        4)技术实现的容易程度
        5)业务或组织机构实现的容易程度
        6)对业务的好处
        7)遵守法律的要求
    2、何时确定优先级          
        1)让需求知识变得越可视,就越有机会不盲目的选择。
        2)强烈建议在启动会议上对每个BUC指定优先级附上顾客满意度和不满意度评分。
        3)编写原子需求时,应该不断考虑是否排列它们的优先级。原因是期望值管理,如果你一直在不断的排列优先级,人们就能够接受这种这种,而不会感觉被欺骗。让利益相关者准备好接受一个事实,即你不能实现所有的需求。
    3、需求优先等级
        1)必须有Must 
        2)应该有Should
        3)可以有Could
        4)不会有Won't
    4、优先级电子表格  
        1)把影响因子的个数限制在4个以内(如:1.对顾客的价值、2.对业务的价值、3.煎炒实现成本、4.易于实现)
        2)每个因子分配适用权重百分比
        3)累加需求的权重评分,得到该项需求的优先级评分。

『检查需求之间的冲突』:
    1、需求冲突的情况
        1)使用相同数据的需求(按照使用的术语进行匹配查找)
        2)相同类型的需求(按照需求类型匹配查找)
        3)使用相同度量尺度的需求(查找那些验收标准使用相同度量尺度的需求)
    2、需求分析师的冲突解决责任:    
        1)在解决冲突的过程中扮演领导的角色
        2)将冲突的需求隔离出来,单独与每个利益相关者接触,重新对满意度和不满意度评分。
        3)如果作为调节人不能获得满意的解决方案,建议你确定现有冲突需求的成本、评估风险,召集当事人会议达成折中。

『评估项目的风险』:
    1、业务分析师在风险评估中的角色,是考虑需求是否包含某种风险,可能影响项目成功。
    2、不必进行风险分析,这项任务更有可能是由项目经理执行。
  3、风险评估不是真正的需求问题,是项目问题。
  4、具体要素:
        1)项目驱动
     1.项目的目标
     2.客户、顾客和其他利益相关者
     3.产品的用户
        2)项目限制条件
     1.强制的限制条件
     2.相关事实和假定
        3)功能需求
     1.工作的范围
     2.业务数据模型和数据字典
     3.产品的范围

『度量所需的工作量』:
    1、我们建议在完整性复查中包括某种规模度量活动
    2、常识告诉你,不能不清楚要构建的产品的规模以及所需的工作量就继续开发。
    3、在需求收集过程中完成的工作,为度量过程提供了输入信息。
    4、你的上下文模型是工作规模的权威指南,你可以简单数一下写下的需求数目,所有的这些都是度量,都比猜测工作量和盲目接受最后期限要强得多。

posted on 2014-05-16 22:16 cheng 阅读(1452) 评论(0)  编辑  收藏 所属分类: 需求分析

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


网站导航: