软件开发与过程管理——需求获取

目录

一. 需求获取概述

1.1 为什么要进行需求分析

1.2 需求获取的非平凡性

1.3 需求获取的主要活动

二. 需求获取的策略

2.1 需求获取的主动性策略

2.2 需求协商

三. 需求获取的主要方法 

3.1 用户调查

3.2 文档分析

3.3 原型法 

3.4 模型驱动 

四. 软件开发及过程管理专栏

---

一. 需求获取概述

需求获取：进行需求收集的一个过程或者活动，它从人员，资料和环境中得到系统开发所需要的相关信息。

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 模型驱动 

• 指导和组织需求获取行为的开展：模型可以用于指导后续需求获取行为的开展
• 整理和归类需求获取行为得到的信息：模型是进行信息整理和归类的很好的框架依据
• 为详细信息的分析提供背景基础和上下文知识：模型驱动方法则是侧重于前期需求阶段的方法，是传统需求分析方法的一个很好的补充
• 帮助组织需求文档的结构
• 作为需求验证的知识基础：发现细节知识与模型内容的偏差和错误和指导需求验证行为的开展

---

四. 软件开发及过程管理专栏

https://blog.csdn.net/weixin_53919192/category_11798300.htmlhttps://blog.csdn.net/weixin_53919192/category_11798300.html