[PMP(4)]软件需求获取与验证

需求阶段的主要活动除了需求分析外,其前应有需求获取,其后至少要包括需求验证。原因在于由于系统规模和应用领域的不断扩大,需求获取的信息逐渐庞杂,需求分析人员在需求获取的过程中要面对的困难不断增加。由于需求获取不够充分、全面所造成的项目变更工作不断升级,并导致项目无法继续进展下去的现象越来越突出。

1、需求获取

需求获取要主动,表现为有计划性,要针对不同的用户层次选择不同的方法。

1.1策略

①理解业务场景很重要:用户对需求的理解主要还是从自身业务出发,他们能够提出的需求是基本需求。还需要能够深入用户工作的实际环境,感受实际场景,就可以大大减少需求变更的可能。

②需求协商:差异问题协调法则(将差异标识并展示给高层);消除变更问题协调法则(主动考虑这些差异形成背后的问题,从开发角度考虑如何消除这些差异,并提供给高层管理人员);需求协商时机法则(需求协商应该在需求获取过程中不断开展,出现就考虑消除.如果都等到冻结前,将所有矛盾集中体现对工作是非常不利的); 

1.2方法 

①文档分析:专门针对相关产品的需求说明书、客户需求文档、相关数据及流程说明等文档进行需求获取的活动。

②用户访谈(face-to-face meeting)

用户访谈的话题类型有开放式话题和封闭式话题。

用户访谈问题顺序的安排有金字塔结构(特定问题开始通用问题结束)、漏斗结构(通用问题开始特定问题结束)、菱形结构(特定问题转向通用问题再特定问题结束)

③用户调查:用户访谈的有效、有益的补充。可以先通过调查设计出通用问卷，再选取特定用户进行针对性访谈(市场调查);也可以先选取一些典型的用户访谈,整理结果后设计相关的调查问卷。通过调查来验证用户访谈的结果是否具有普遍性(需求获取)。

④原型法:软件原型是所提议的新产品的部分实现或可能的实现。

 

 

⑤模型驱动

2、需求验证

2.1目标:检验软件需求规格说明(SRS)，以减少因需求错误而带来的工作量问题;

2.2手段:需求评审(Review),这是一个迭代过程,需要多次重复去发现错误;

2.3含义:①需求验证(以正确的形式建立了需求,技术上可解决);②需求确认(确保得到语义正确的需求,符合用户原意);

2.4内容:①一致性②完整性③现实性④有效性

2.5评审过程

2.6检查方法

检查方法	描述
自由方法(Ad-hoc)	没有为检查人员提供系统化的引导
检查清单(Checklist-Based)	以通用的检查清单来引导检查过程
缺陷(Defect-Based)	用于需求文档，根据缺陷的分类来组织和检查场景
功能点(Function Point Based)	按照功能点来组织和检查场景
视角(Perspective-Based)	按照不同涉众类型的视角来组织和检查场景
场景(Scenario-Based)	对每一个场景,都利用一系列的问题或者细节要求,来引导检查过程.缺陷、功能点、视角都是场景方法的一个特例。
逐步提升(Stepwise Abstraction)	净室软件开发中的一种方法。阅读者描述一些独立代码段的功能,然后将描述的范围逐步扩大,描述的功能抽象逐步提高，直至阅读人员描述了整个评审物件