讲课视频在线视频

先来看看需求的定义

来自美国科罗拉多州立大学

科全分校的Alan M.Davis教授

给需求的定义是这样的

需求是对外可见的系统特征

它强调的是需求的对外可见性

以及需求关注的是

系统的特征描述

需求管理在他看来

主要由三项任务组成

首先

是以学习为主的需求获取过程

其次是对获取到的需求

进行优选剪枝的过程

最后是需求的文档化过程

也就是撰写需求规格说明书

IEEE标准对需求的定义是

需求是 人们要解决的某个问题

或实现某个目标

所需的能力和条件

是系统或其组成部分

为满足某种书面合同规定

所要具备的能力

需求将作为系统开发 测试

验收 提交的正式文档依据

从这个定义中我们可以看出

它强调的是合同相关的特性

另一个经典的需求定位来自

Herber Simon教授

他是诺贝尔经济学奖

以及图灵奖的获得者

在他的著作《人工的科学》

第五章

他给出了这样的一段描述

每一种“人造物”

都是一个内部环境与外部环境

的“接口”

这里内部环境是指人造物

本身的设计组成

外部环境是指人造物的周遭

及其作用环境

对这个接口的描述既是需求

从这个定义我们看出

软件作为一种人造物

它为了很好地满足外部环境

对它的要求

就必须要有一个针对内外环境

的接口的一个非常精确的描述

只有这样

才能够让软件系统的行为

和外界的要求合理适配

需求描述的难点和挑战就在于

它是连接应用领域现象

与机器领域现象的桥梁

我们要从应用领域的固有性质

和用户待解决的需求描述

转化为可以用计算机软件

实现的系统行为的描述

那么在需求中

究竟应该包括哪些内容

我们知道需求是用户

希望系统满足一定的目标

而体现出来的行为

在需求的描述中

要反映出分析师对问题领域的

清晰的理解

给出系统使用的上下文和场景

因此 在需求的定义中

我们要试图回答

以下的主要问题

包括我们为什么要设计这个系统

系统将由谁使用

系统要做什么

涉及哪些信息

对解决方案是否有额外的限制

如何使用该系统

质量指标约束要达到何种程度

通过对这些问题的解答

我们就能够比较清楚地

了解需求的核心内容

系统需求规约是由

应用领域和机器领域中

共享的事物组成的

以禁止学生以外的人员

参与校内活动抢票

这一问题的解决为例

问题的本质是要区分

非法闯入者和合法的学生用户

而这个问题的解决

投影到机器领域

就转换为了通过对学生卡

微信用户名和密码的检查

实现身份的甄别

这里涉及到三类对象

一类是由人机共享的事物

包括学生卡号 密码 微信号

键盘输入等

它是跨应用领域和机器

两个领域的现象

此外

还有专属于应用领域

而机器领域看不到的现象

它们属于应用领域固有的事物

必须要投影到机器

可以接受的输入

才能由机器识别到

包括学生 系统管理员

密码分配过程 学生名册

发给学生的带密码的

不干胶贴等等

还有专属于机器领域的现象

这些现象是实现系统行为

必不可少的

但是却是对用户来说不可见的

这可以包括加密算法

微信认证 内存管理

安全套接字等

相关的技术实现模块

然而 在应用领域和机器领域

之间的边界划分

也是可以发生迁移的

比如 在一个电梯控制系统中

原本属于应用领域的乘客等待

和乘客在电梯内这两个现象

当我们通过增加传感器

监视器等设备的时候

我们就改变了问题的边界

乘客等待和乘客在电梯内

变成了机器可以观测到的状态

于是它们也就进入了

二者之间共享现象的集合

系统边界的迁移

意味着系统的问题性质

发生了改变

从而系统的设计也将随之改变

在定义需求的过程中

我们要注意

将问题与解决方案分开

建立单独的问题描述文档

这样

可以深入地剖析待解决的问题

将问题描述与实现描述分开

可以使得干系人之间

可以就待解决问题的本身

进行充分地磋商和讨论

对多个候选的设计方案

进行优选

问题描述也可以作为

测试用例设计的主要信息来源

从右图我们可以看出

问题陈述和实现陈述之间

要进行模型正确性的证明

在客观世界和已经设计出来的

系统之间

要检查和验证

系统与客观世界的适用性

确保问题陈述与干系人的

需求相呼应

领域性质

是无论系统存在与否

都存在的应用领域性质

以抢票系统为例

演出票的数目

是不会系统的存在而发生改变的

因此它是应用领域固有的性质

而需求

是由于系统的存在而使能的

新的应用领域性质

因为抢票系统是通过微信平台

快速公平便捷的

完成了演出票的分配

因此 它的需求就是一种

由于抢票系统存在而带来的

新的领域的性质

抢票系统的规约描述

描述的是

抢票系统的工作流程

用户身份认证的手段

二维码扫描 验票的手段

那么它实际上是描述系统

为了满足用户的需求

而具有的行为

需求证明是为了确保两件事

首先是运行在机器上的软件

满足规约描述

其次 是针对给定的领域性质

规约符合用户需求

需求验证的手段

则是要从完备性来入手

首先是不是所有的需求

都已经找出

其次

是不是所有有关的应用领域性质

都得到了定义

假定待解决的需求是

当飞机在跑道上移动时

反推器处于工作状态

我们做出的

两条领域性质的假设是

当且仅当

轮胎转动时产生轮脉冲

当且仅当

飞机在跑道上移动时轮胎转动

由这样的两条性质

我们推导出

系统的规格说明是

当且仅当

有轮脉冲产生时反推器工作

那么这样的一组假设

是不是正确

如果我们所做的领域模型出错时

会有什么样的后果

仔细分析后 你会发现

实际上我们做出的第二条

领域性质的假设是存在问题的

当飞机在跑道上移动时

轮胎转动

并没有覆盖客观世界的真实情况

在雨天

坡道路滑的时候

飞机在跑道上移动

但是轮胎有可能没有转动

此外

当飞机在跑道以外的地方

移动的时候

轮胎也是转动的

所以这两种情况

是属于没有被我们现在的

领域性质覆盖的情况

因此 飞机的行为

是与预期不符合的

我们要注意

在需求的描述过程中

避免含糊的 错误的 不完整的

矛盾的和无法测试的需求

这样几种情况

含糊的需求

往往是在需求的描述中

用了虚指的代词

对这样的情况的处理

应该注意明确指出

所指代对象是什么

错误的需求描述

则往往是忽略了一些

明确的事实

比如

如果你说所有的系统将九月

作为财政年度的起始时间

无疑是以偏概全的一种假设

要注意需求的完整性

就要考虑到各种可能的情况

比如

错误信息显示在屏幕的第24行

那么我们在这里忽略了

出错的信息超过一行的情况

因此这个需求是无法被满足的

要注意对变量定义的

逻辑上的一致性和无矛盾性

我们不能把C首先定义

为A+B的和

稍后又把它定义为A-B的差

无法测试的需求

往往是针对非功能性需求的

比如我们总是说

系统应该具有友好的界面

但是我们没有给出明确的

判断准则

什么样的界面是友好的

什么样的界面是不友好的

那么这个需求

对我们未来系统的评价

是没有任何帮助的

是应该进一步细化的

好的需求描述是可以度量的

它给出项目成功的必要条件

在需求项目的度量指标中

针对单个需求项目的度量

主要包括准确性 正确性

明确性 可行性 可证明性

针对需求集合的质量

包括它的现实性 精确性

全面性和一致性

这些需求的质量监测标准

为我们评估

自己的需求文档的质量

给出了客观的参照依据