目录
一. 需求获取概述
需求获取:进行需求收集的一个过程或者活动,它从人员,资料和环境中得到系统开发所需要的相关信息。
1.1 为什么要进行需求分析
- 传统上:开发不重视需求获取,将需求分析放在首位。
- 实践表明:需求分析,其前应有需求获取,其后至少要包括需求验证。
- 原因:系统规模和应用领域的不断扩大,需求获取的信息逐渐庞杂,需求分析人员在需求获取的过程中要面对的困难不断增加。
- 由于需求获取不够充分、全面所造成的项目变更工作不断升级,并导致项目无法继续进展的现象突出。
1.2 需求获取的非平凡性
- 普通用户缺乏概括性、综合性的表述能力;
- 专家用户的知识结构因渊博而具有概括性和广泛性 ;
- 开发人员在与用户接触前,先确定获取的内容主题,然后设计具体的应用环境和场景条件,由用户根据细节业务的执行来描述问题、表达期望。
1.3 需求获取的主要活动
- 研究应用背景,建立初始的知识框架;
- 根据获取的需要,采用必要的获取方法和技巧;
- 先行确定获取的内容和主题,设定场景;
- 分析用户的高(深)层目标,理解用户的意图;
- 进行涉众分析,针对涉众的特点开展工作。
二. 需求获取的策略
2.1 需求获取的主动性策略
- “获取”强调需求分析人员在整个过程中应该充分发挥主动性。
- 主动性取决两点:对用户和系统的理解(对业务的理解),掌握相关的获取技巧。
- 如果没有对业务系统的知识了解,难以组织和发挥技巧的作用。
- 对业务系统的知识理解,是需求获取的基础。
总而言之:需求获取要主动,表现为有计划性, 要针对不同的用户层次选择不同的方法。
2.2 需求协商
在需求获取的过程中,往往会遇到需要协商的问题。需要需求开发人员具有一定的技巧和沟通能力。
- 差异问题协调法则
不同的业务层面(有时即使是相同业务层面)的用户对同样的概念或者流程有不同的认识和理解,会出现一些差异,在需求整理时应该将这些差异明确标识出来,并展示给用户高层管理人员,由他们来确定如何消除这些差异,并将这些情况记录。
- 消除变更问题协调法则
上面法则提到的问题,从消除变更的角度考虑仍然存在问题。仅仅将差异标识并展示给高层并不能消除变更的可能,应该考虑这些差异形成背后的问题,应该从开发角度考虑如何消除这些差异,并提供给高层管理人员。要有主动性。
- 需求协商时机法则
不要在需求冻结前开展需求协商工作。需求协商应该在需求获取过程中不断开展,出现就考虑消除。如果都等到冻结前,将所有矛盾集中体现对工作是非常不利的。
三. 需求获取的主要方法
一般主要的需求获取的方法有如下几种:
3.1 用户调查
- 用户调查技术实际上是与用户访谈相关的一组技术和方法。在市场调查领域应用非常广泛。
- 主要优点在于调查面比较宽,用户反馈多。这恰好能够成为用户访谈的有效补充,能够克服用户访谈的片面性。
- 而其缺点主要是大家都认识到的往往不易深入,而这恰好是用户访谈所能避免的。 用户调查是用户访谈的有效、有益的补充。
3.2 文档分析
- 文档分析又称文档考古或者文档审查,是一种专门针对文档进行需求获取的活动。其主要获取对象包括相关产品的需求说明书、客户需求文档、相关数据及流程说明等。
- 其主要优点是能够详细、直观地对数据流细节进行了解和分析。缺点也比较明显,企业机构中,文档量通常非常大,由此容易使需求获取人员陷入文山书海中不能自拔,甚至引起误导。
3.3 原型法
- “原型是一个系统,它内化了(capture)一个更迟系统(later system)的本质特征。原型系统通常被构造为不完整的系统,以在将来进行改进、补充或者替代。”
- 如果在最终的物件(final artifact)产生之前,一个中间物件(mediate artifact)被用来在一定广度和深度范围内表现这个最终物件,那么这个中间物件就被认为是最终物件在该广度和深度上的原型。
1)原型的类别——按照开发方式分类
2)原型的类别——按照开发方式分类
- 探索式和实验式方法产生的原型产品又被称为抛弃式原型
- 花费最小的代价,争取最快的速度
- 可能会使用简易的开发工具和不成熟的构造技术
- 可能会忽略或简化处理原型目的不相关的功能特征
- 要坚决的抛弃
- 演化式原型方法产生的原型产品被称为演化式原型(evolutionary prototype)
- 质量要从一开始就能达到最终系统的要求
- 要易于进行扩展和频繁改进,因此开发者必须重视演化式原型的设计
- 仅应该被用于处理清晰的需求、规格说明和技术方案
3)原型方法的过程
3.4 模型驱动
- 指导和组织需求获取行为的开展:模型可以用于指导后续需求获取行为的开展
- 整理和归类需求获取行为得到的信息:模型是进行信息整理和归类的很好的框架依据
- 为详细信息的分析提供背景基础和上下文知识:模型驱动方法则是侧重于前期需求阶段的方法,是传统需求分析方法的一个很好的补充
- 帮助组织需求文档的结构
- 作为需求验证的知识基础:发现细节知识与模型内容的偏差和错误和指导需求验证行为的开展