课件

8.2 需求定义.pdf

需求定义

来自美国科罗拉多州立大学科全分校的 Alan M. Davis 教授给需求（Requirement）的定义是这样的：需求是对外可见的系统特征。它强调的是需求的对外可见性，以及需求关注的是系统的特征描述。

需求管理在他看来主要由三项任务组成：

  • 学习：首先，是以学习为主的需求获取过程；
  • 剪枝：其次是对获取到的需求进行优选剪枝的过程；
  • 文档化：最后是需求的文档化过程，也就是撰写需求规格说明书；

什么是需求

image.png
IEEE 610.12,1990 标准对需求的定义是，需求是人们要解决的某个问题或实现某个目标所需的能力和条件。是系统或其组成部分为满足某种书面合同规定所要具备的能力。需求将作为系统开发、测试、验收、提交的正式文档依据。从这个定义中我们可以看出，它强调的是合同相关的特性。

image.png
另一个经典的需求定位来自 Herber Simon 教授，他是诺贝尔经济学奖以及图灵奖的获得者。在他的著作《人工的科学》第五章，他给出了这样的一段描述：每一种“人造物”都是一个内部环境与外部环境的“接口”，这里内部环境是指人造物本身的设计组成，外部环境是指人造物的周遭及其作用环境，对这个接口的描述既是需求。从这个定义我们看出软件作为一种人造物，它为了很好地满足外部环境对它的要求，就必须要有一个针对内外环境接口的一个非常精确的描述，只有这样，才能够让软件系统的行为和外界的要求合理适配。

需求描述的难点与挑战

image.png
需求描述的难点和挑战就在于，它是连接应用领域现象与机器领域现象的桥梁，我们要从应用领域的固有性质和用户待解决的需求描述，转化为可以用计算机软件实现的系统行为的描述。

需求的内容

在需求中，究竟应该包含哪些内容呢？

需求是用户希望系统满足一定的目标而体现出来的行为，在需求的描述中要反映出分析师对问题领域清晰的理解，给出系统使用的上下文和场景，因此在需求的定义中，我们要试图回答以下的主要问题：

  • 我们为什么要设计这系统
  • 系统将由谁使用
  • 系统要做什么
  • 系统涉及哪些信息
  • 对解决方案是否有额外的限制
  • 如何使用该系统
  • 质量指标约束要达到何种程度

通过对这些问题的解答，我们就能够比较清楚地了解需求的核心内容。

案例

系统需求规约是由应用领域和机器领域中共享的事物组成的，以禁止学生以外的人员参与校内活动抢票这一问题的解决为例。
image.png
问题的本质是要区分非法闯入者和合法的学生用户，而这问题的解决投影到机器领域就转换了为通过对学生卡微信用户名和密码的检查，实现身份的甄别。

这里涉及到三类对象，一类是由人机共享的事物，包括学生卡号、密码、微信号、键盘输入等，它是跨应用和机器两个领域的事物。

此外，还有专属应用领域而机器领域看不到的事物，他们属于应用领域固有的事物，必须要投影到机器可以接受的输入，才能由机器识别到，具体包括学生、系统管理员、密码分配过程、学生名册、发给学生的带密码的不干胶贴等。

还有专属于机器领域的事物，这些是实现系统行为必不可少的，但是对用户来说确实不可见的，包括加密算法、微信认证、内存管理、内容缓冲、安全套接字等相关的技术实现模块。

然而，在应用领域和机器领域之间的系统边界的划分也是可以发生迁移的，如图：
image.png
如在一个电梯控制系统中，原本属于应用领域的「乘客等待」和「乘客在电梯内」这两个事物，当我们通过增加传感器、监视器等设备时，就改变了问题的边界，「乘客等待」和「乘客在电梯内」变成了机器可以观测到的状态，于是它们就进入了人机共享的区域。

系统边界的迁移意味着系统的问题性质发生了改变，从而系统的设计也随之改变。

将问题与解决方案分开

在定义需求的过程中，要注意将问题与解决方案分开，建立单独的问题描述文档，这样：

  • 可以深入地剖析待解决的问题
  • 将问题描述与实现描述分开，可以使得干系人之间可以就待解决问题的本身进行充分地磋商和讨论
  • 对多个候选的设计方案进行优选
  • 问题描述也可以作为测试用例设计的主要信息来源

image.png
从上图可以看出，问题陈述和实现陈述之间要进行模型正确性的证明，在客观世界和已经设计出来的系统之间，要检查和验证系统与客观世界的适用性，确保问题陈述与干系人的需求相呼应

案例二

image.png

  • 领域性质：是无论系统存在与否都存在的应用领域性质，以抢票系统为例，演出票的数目是不会系统的存在而发生改变的，因此它是应用领域固有的性质。
  • 需求：是由于系统的存在而使能的新的应用领域性质，因为抢票系统是通过微信平台快速公平便捷的完成演出票的分配，因此它的需求就是一种由于抢票系统存在而带来的新的领域的性质。
  • 规约描述：抢票系统的规约描述，描述的是抢票系统的工作流程、用户身份认证的手段、二维码扫描验票的手段，那么它实际上是描述系统为了满足用户的需求而应具有的行为。
  • 需求证明的标准：为了确保两件事，首先是运行在机器上的软件满足规约描述，其次是针对给定的领域性质规约符合用户需求。
  • 需求验证的标准：需求验证的手段则是要从完备性来入手，首先，是不是所有的需求都已经我出，其次，是不是所有有关的应用领域性质都得到了定义。

image.png
假定待解决的需求是当飞机在跑道上移动时，反推器应处于工作状态。我们做出的两条领域性质的假设是：

  • 当且仅当轮胎转动时产生轮脉冲。
  • 当且仅当飞机在跑道上移动时，轮胎转动。

由这样的两条性质推导出系统规格说明是当且仅当有轮脉冲产生时，反推器工作。

这样的一组假设是否正确？如果我们所做的领域模型出错时会有什么样的后果？仔细分析后发现，做的第二条领域性质假设存在问题，当飞机在跑道上移动时，轮胎转动并没有覆盖客观世界的真实情况，在雨天跑道路滑时，飞机在跑道上移动但轮胎有可能没转动，另外，当飞机在跑道外的地方移动时，轮胎也是转动的，因此这两种情况是属于没有被我们现在领域性质覆盖的情况，所以飞机的行为是不符合预期的。

存在问题的需求描述实例

在需求的描述过程中，避免需求出现下面的情况：含糊的、错误的、不完整的、矛盾的和无法测试的。
image.png

  • 含糊的需求：往往在需求描述中用了虚指的代词，处理办法是明确指出所指代对象是什么；
  • 错误的需求：描述往往是忽略了一些明显的事实，比如“你说所有的系统将九月作为财政年度的起始时间”无疑是以偏概全的一种假设；
  • 需求的完整性：要考虑到各种可能的情况，比如“出错信息显示在屏幕的第 24 行”，这里忽略了出错的信息超过一行的情况
  • 矛盾或不一致的需求描述：注意对变量定义的辑上的一致性和无矛盾性
  • 无法测试的需求：住往是针对非功能性需求，如我们常说的“系统应具有友好的界面”，但没有给出明确的判断准则，怎样才算友好，怎样才算不友好

需求规约

image.png
好的需求描述是可以度量的，它给出项目成功的必要条件，在需求项目的度量指标中：

  • 针对单个需求项目的度量主要包括：
    • 准确性（Concise）
    • 正确性（Correct）
    • 明确性（Non-ambiguous）
    • 可行性（Feasible）
    • 可证明性（ Verifiable)
  • 整个需求集合的质量，包括：
    • 现实性（Realistic）
    • 精确性（Concise）
    • 全面性（Complete）
    • 一致性（Consistent）

这些需求的质量监测标准为我们评估自己的需求文档的质量给出了客观的参照依据。