2.2 需求获取在线视频

大家好

我们下面开始软件理论与工程

第二章第二节

需求获取

我是这一章的主讲老师高广宇

那我们在上一章的时候呢

我们讲了需求工程过程

我们知道

对于一个需求分析的过程来说

我们按照系统工程的思路

它可以被划分为

需求获取 需求分析 规格说明和需求验证

四个阶段

当然还包括外围的需求管理

而其中刚才说的前面那四个过程

共同构成的需求开发

那我们后面的几节内容呢

重点针对不同的一个工程过程

进行一些更加深入的一些讲解

我们今天先开始第一个需求获取

那什么是需求获取呢

直接呢

咱们其实可以从这个字面意义上去理解一下

获取

需求

对吧

那实际上呢

需求获取

简单来说就是我们要从人

文档和环境中

去获取和提炼需求的这么一个过程

那在我们进行需求获取的过程中呢

我们知道整个需求工程

它对应的这个人员

我们可以称之为需求工程师

那需求工程师呢

要实现需求获取

它通常呢

必须利用各种方法

和技术来发现需求

需求获取当然和后面的需求分析呢

是交织在一起的

就是我们需求获取完了之后

我们其实是顺带的进行一些分析 建模

以一些模型或者文档的方式

对我们的一个需求进行一些形式化的

文档化的一些表达

对吧

那我们今天呢

先讲一下

这个需求获取相关的一些细节的内容

那这里重点提到了 就是说

从人

文档或环境中去获取需求的一个过程

大家稍微的记住一下这三个词

人 文档或者环境

那需求获取

作为一个需求工程的一个过程

它其实又可以分成若干的这个子活动

比如呢

我们PPT上列了五类这个子活动

第一个呢

比如说

搜集背景资料对吧

其实这些其实也是大家

平时在日常生活中我们在

做一些工作

尤其是做一些研究 做一些工程过程

必备的一些这个工作

收集背景资料就相当于咱们平时做的一些调研

那在整个需求工程中呢

其实它整个的这个过程

是大致差不多的

但是呢 我们是按照系统工程的这个思路

把中间所有的环节

全部 需要去给它流程化

模型化

把它的产出

也要模型化 文档化

所以第一个呢 是收集这个背景资料

那第二个呢

我们要去定义项目的前景和范围

当然最后它其实也会形成一个

所谓的项目前景和范围文档

就是前面提到的

同样做一个事

当然 在需求工程里面

我们需要把每一个不同的过程

都需要去模型化和文档化

第三个呢 是选择信息的一个来源

就前面提到的

人 资料和环境

第四个呢

我们要选取不同的一些获取方法

去执行需求获取的这么一个过程

最后呢

我们要把整个需求结果要记录下来

甚至在这个过程中前面提到的

我们会去进行一些需求的一些分析

对它进行一些需求建模等等

这是需求获取的

五个子活动

那对于这个结合这五个子活动

我们

下面呢 从它的一些基本步骤

还有获取技术

还有几个主要的内容方面的

再进行一些这个深入的讲解

我们首先把前面提到的这个子活动

细化成若干的基本步骤

比如第一个

我们前面提到了

我们要去获取它的一些这个

背景知识

或者像前面我提到的

类似于去做一些调研一样

实际上就对应到我们这里的第一步

我们要去了解相关背景和领域行业的知识

这个是非常重要的

因为呢

我们对于一个软件的需求工程师

或者是系统工程师

或者开发人员来说

我们要开发的这个软件

它所应用的领域

和应用背景

和行业

可能是千差万别的

所以呢

我们开发的这个软件

必须要具有一定的领域特点

或者行业的这个特点或者知识

那这就有赖于说呢

我们必须

提前去了解一下整个外围

它所处的环境

背景和领域的一些知识

这样才能够指导我们去开发

一些针对性非常强的

这个软件产品或者需求分析的一些结果

这是第一个部分

第二个部分呢

我们自己在了解的相关的一些背景

和领域知识之后

我们需要去

真正的跟我们的用户

或者客户去接触

那第一个呢

我们当然是要跟这个客户企业或者组织的

一些高层人员去进行一些接触

包括这个交谈

我们要去了解

它整个高层的一个

目标或者期望是什么

这样呢

逐步按照金字塔模型的一个结构

去细化成用户需求

和我们的这个系统需求

那我们去跟这个高层人员去进行接触的时候

我们梳理出来的就是我们比较

高层次的一些这个需求描述

也就是我们上一节我们讲到的业务需求

那有了业务需求之后呢

业务需求作为一个指导性的一个内容

我们再往下去细化

在这个过程中

我们就需要去跟

这个客户的

项目组的一些经理

一些人员

或者我们一些用户去进行交流

我们呢

结合前面提的高层次的业务需求

去理解普通的用户

它具体的一些用户类的

用户需求是什么

当然在这个过程中呢

我们需要去整理需求的这个纪要

形成一些粗略的一些文档

或者一些各种类型的一些描述

我们要去发现一些新的问题

甚至呢

我们要去重复的跟

不同层次的一些客户人员去进行

反复的交流

那第五步来说呢

是需求分类和组织

这个是

我们可能就是说

自己回到这个我们自己的工作环境之后

需要去做的一些这个操作

我们对前期所整理的一些文档

一些资料 一些内容

分类组织

我们去提炼

不同层次的需求

包括业务需求

用户需求 系统需求对吧

以及包括非功能需求 约束条件等等

第六步呢

我们根据前面的这一些组织

和获取的内容

我们去对它做一个优先排序

或者冲突的解决

当然

最后呢

通过一些文档

通过一些需求的获取的一些方法

一些模型

形成一个

这个需求的一个清单

再跟客户呢

去进行反复的一个确认

最后呢

让客户可以去签字确认

确定我们在第一个环节是

这个完备的

正确的

无二异性的 对吧

这是我们整个需求获取的一个

基本的一个步骤

那这个图呢

是对于刚才我讲的这几个不同的步骤

它的一个图示 对吧

大家从这个上面能看出来

我们整个呢

是包括这个业务需求

和用户需求

还有呢

后面提到的这个功能需求和一些非功能需求

当然 前面大家能看出来

就是说整个业务需求和用户需求

是通过跟

我们的一些客户或者用户

各个不同层面的 对吧

各个不同的层面的用户

和这个高层管理人员直接接触之后

就能直接会得到的一些 这个

需求

那实际上你看我们的这个

功能需求和非功能需求 对吧

还包括其它约束条件

这个呢 其实都是在事后

我们搜集大量的这个需求纪要和文档

进行整理之后呢

所形成的

当然还有外围的一些 包括前面提到的一些

怎么去对它梳理优先级

还有去做一些冲突的消解

包括在这个过程中我们还需要去跟客户

和用户再进行反复的一些这个接洽

对吧

这是我们一个图示化的一个表述

当然这个的话呢

是我们更好的去从这个逻辑模型的角度

我们更好的去细化整个这个基本的步骤

比如第一个行业知识的学习

也对应到我们前面提到的

我们要去了解一些背景

或者领域的一些知识

虚线框框出的这个区域呢

底下有一个小字写的

这个叫多次反复的过程

其实这个过程呢

是跟用户在整个

不断的接洽的过程中

要反复去执行去确定的

而这个左下角的这一部分呢

其实是我们这个有的时候

需要去离线 去做的一些操作

是为了去

帮助这个用户有时候去按照我们比较

这个逻辑性比较强的一些这个表述

形式化表述

去阐述

或者说去

构建整个需求的一个

基本的一个结构或者模型 对吧

那我们这是我们整个需求

获取的一个这个基本的步骤

那我们在整个基本步骤里我们知道

中间

这个有一个跟不同的客户或者用户去接洽

和交流的一些过程

其实这个里面就是体现出

我们需要用不同的这个需求获取的技术

对吧

比如说

这个最传统的

像什么呀

面对面的交谈

现场的观察

问卷的调查

这些都是大家这个比较直观理解的

大家有的同学就觉得说

这个好像

怎么跟这个需求获取有关系

实际上

这是传统的一种

非常经典的一个需求获取的过程

只是在这个过程中

当然我们不能进行一些

无意义的这个交谈和这个问卷调查

所有的这些交谈

调查和观察

都是有提前的这种规划和记录

在整个这个交流

或者获取之前和获取之后

我们都是会有一些

文档化的描述

会有一些纪要

而这些纪要

或者是些材料是最后我们要去抽取不同的需求

去形成需求

这个清单

或者列表率非常重要的数据来源

第二大类呢

是集体获取的一些方法

比如说

比较经典的

我们通常

会组织我们的客户的不同的一些人员

包括高层人员

项目经理

普通用户

甚至是其它的一些 这个

具体的一些使用者 对吧

去进行一些专题讨论

从多个不同的角度去听取大家对于整个

这个项目或者工程

它的一些这个需求

它的一些这个要求 对吧

还有 包括

有一些可能就是说 目前

这个想不到的一些内容

大家通过一些头脑风暴对吧

去构思

当然我们对于这个需求工程师

或者是系统工程师

我们在参与这个东西的过程中

我们也需要去引导说

去排除掉一些这个不可能实现的

或者说是目前的技术没法去实现的 对吧

所以说 整个需求获取的过程

既是去获取用户的这个需求的一个过程

也是为了

需求工程师和系统开发人在后期开发过程中

去针对一些

没法实现的一些功能

或者说这个系统设计

去做一些这个梳理的一个过程

第三种方法来说呢

原型系统

原型 其实在整个系统工程过程中

都是一个非常传统

但是非常管用的方式

尤其

在这个需求获取过程中

它适合什么样的这个场景呢

适合对于这个需求

用户自己都不是很清楚

他说不太清楚

非常的模糊

那对于这个需求工程师

或者我们的系统工程师来说

根本就没法去很清晰的

通过这个会议纪要或者一些文档的方式

或者模型的方式去描述用户的这个需求

在这种情况下呢

最好的这种方式就通过原型系统的方式

也就是说

根据

需求工程师和系统工程师的理解

我们去开发一个

基本的原型系统

然后交给这个用户

用户根据这个原型系统去反馈说

这个功能是我要的

这个功能不是我要的

然后在这个过程大家不断的去交互迭代

慢慢的呢

形成一个依靠原型系统

依靠相应的一些具体化的文档来表述的一个

比较清晰的一个需求过程 对吧

这是一个

那第四类呢

是这个模型驱动的方法

那这个的话呢

其实就更加的这个

面向或者更加的具体

或者更加的这个

靠近需求分析这一端了

它是通过模型驱动的方式

通过一些

这个建模的一些方式

比如说用例表示方法 对吧

我们通过用例图等等这些方式去

把用户的一些这个需求

通过图示

通过建模的方式来表述

当然 这个结果其实在某种意义上

就已经融入了需求分析的一些过程

需求建模的一些过程了对吧

那还有一个呢

这个基于上下文的一些方法

如果说前面的几类方法

都是比较直接跟用户去打交道的

那么最后一类呢

可以说是从外围

就也包括向前面提到的

用户有的时候呢

他也说不清楚他到底需要什么 那些需求

那这个时候我们可以结合

用户它所在的一个行业背景

它所这个

期待的一些这个功能等等

从外围它

已有的一些系统等等

这些上下文的一些 这个背景

来分析

来梳理 来总结说

用户他可能需要什么样的一些需求

那这时呢

我们需求获取的五类不同的一些技术

那我们有了这么一些需求获取的技术

我们跟用户不断去打交道

我们形成不同一些文档

我们到底最后需要获取到什么呢

对吧

也就是说需求获取 到底要获取什么

通常来说

我们知道需求获取的下一个环节是什么

是需求分析 需求建模

最后我们要形成需求规格文档

从我们前面对于需求工程过程

和软件需求的定义

我们知道整个需求包括

这个业务需求

用户需求和系统需求

所以呢

从这两个层面我们来理解 我们知道

实际上我们整个这个需求获取

首先我们肯定要去

至少能够直接的去获取到我们的

业务需求

还有呢

我们的一些用户需求

那当然对于系统需求

或者功能需求等等这些的话

可能是我们需要在需求分析阶段

通过各种需求建模去再细化的

对吧

当然在这个里面呢

我们还需要通过

这个不断的这个需求获取的一些这个方式

和技术去知道呢

它的一些这个什么

约束

也就是说一些非功能需求

对吧

这是我们在这个阶段

在需求获取阶段需要去明确的

对于这个前面提到的比较细化的用户需求

和系统需求可能是需要去进行更多的

这个分析 建模的一些过程

才可能得到一些比较细化的一些结果 对吧

那当然 我们需求获取的主要内容

我们稍微具体化罗列一下 就

如这一列PPT里面列的这个 对吧

这个也是

基本上跟我刚才说的差不多

大家可以自己再去深入的理解一下

好 那我们今天这一节呢

我们就讲到这里

然后我们下一节呢

我们会继续

就需求分析和建模呢

去进行讲解

谢谢大家