软件需求 – 软件工程教程

上一章软件工程教程请查看：软件项目管理

软件需求是对目标系统的特性和功能的描述，需求传达了用户对软件产品的期望。从客户的角度来看，需求可以是明显的，也可以是隐藏的；可以是已知的，也可以是未知的；可以是预期的，也可以是意外的。

需求工程

从客户端收集软件需求，分析并记录它们的过程称为需求工程。

需求工程的目标是开发和维护复杂的和描述性的“系统需求规格说明”文档。

需求工程过程

这是一个包括-的四步过程：

• 可行性研究
• 需求收集
• 软件需求规范
• 软件需求验证

让我们简单地看一下这个过程

可行性研究

当客户为了开发所需的产品而与组织接触时，它会对软件必须执行的所有功能以及软件应该提供哪些功能有一个大致的概念。

根据这些信息，分析人员将详细研究所需的系统及其功能是否可以进行开发。

本可行性研究的重点是组织的目标。本研究分析了软件产品能否在实施、项目对组织的贡献、成本约束以及组织的价值和目标等方面得到实际实现。它探索项目和产品的技术方面，如可用性、可维护性、生产力和集成能力。

这一阶段的产出应是一份可行性研究报告，其中应载有对管理当局关于是否应进行项目的充分评论和建议。

需求收集

如果可行性报告对项目的实施是积极的，那么下一阶段将从收集用户的需求开始。分析人员和工程师与客户和最终用户进行沟通，了解他们对软件应该提供什么以及希望软件包含哪些功能的想法。

软件需求规范

SRS是系统分析人员从各种涉众收集需求后创建的文档。

SRS定义了预期的软件将如何与硬件交互、外部接口、操作速度、系统响应时间、软件跨各种平台的可移植性、可维护性、崩溃后的恢复速度、安全性、质量、限制等。

从客户处收到的需求是用自然语言编写的。系统分析员的职责是用技术语言记录需求，以便软件开发团队能够理解和使用它们。

SRS应该具备以下特点：

• 用户需求用自然语言表达。
• 技术需求用组织内部使用的结构化语言表示。
• 设计描述应该用伪代码编写。
• 表单格式和GUI屏幕打印。
• DFDs的条件和数学符号等。

软件需求验证

在需求规格制定之后，本文档中提到的需求将被验证。用户可能会要求不合法、不切实际的解决方案，或者专家可能会错误地解释需求。如果不防患于未然，就会导致成本大幅增加。可以根据以下条件检查需求-

• 如果它们能够切实执行
• 如果它们是有效的，并且根据软件的功能和领域
• 如果有任何含糊之处
• 如果它们是完整的
• 如果他们能被证明

需求引出过程

需求引出过程可以用下面的图来描述：

• 需求收集—开发人员与客户和最终用户进行讨论，并了解他们对软件的期望。
• 组织需求——开发人员将需求按重要性、紧迫性和方便性进行优先级排序和安排。
• 协商和讨论——如果需求是模糊的，或者在不同的涉众的需求中存在一些冲突，如果是，则与涉众进行协商和讨论。然后，可以对需求进行优先级排序并合理地进行折衷。

需求来自不同的涉众。为了消除歧义和冲突，对它们进行了清晰和正确的讨论。不现实的需求被合理地妥协了。

• 文档化——所有正式的和非正式的，功能性的和非功能性的需求都有文档化，并可用于下一阶段的处理。

需求抽取技术

需求捕获是通过与客户端、最终用户、系统用户和其他与软件系统开发有利害关系的人进行通信，从而发现预期软件系统的需求的过程。

有多种方法可以发现需求

面试

访谈是收集需求的有力媒介。组织可进行以下几种类型的面试：

• 结构化的(封闭式的)面试，每一个需要收集的信息都是预先确定的，他们坚定地遵循讨论的模式和内容。
• 非结构化的(开放的)面试，在那里收集的信息不是预先决定的，更灵活，更少偏见。
• 口头面试
• 书面采访
• 一对一的面谈是在桌子对面的两个人之间进行的。
• 在参与者之间进行的小组访谈。它们有助于发现任何遗漏的需求，因为涉及到许多人。

调查

组织可以通过查询各种涉众对即将到来的系统的期望和需求来进行调查。

调查问卷

一份包含预先定义的一组客观问题和相应选项的文档被交给所有涉众回答，并收

集和编译。

这种方法的一个缺点是，如果某个问题的选项在问卷中没有提到，那么这个问题就可能无人关注。

任务分析

工程师和开发人员可以分析新系统所需的操作。如果客户已经有一些软件来执行某些操作，则对其进行研究，并收集拟议系统的需求。

域分析

每个软件都属于某个领域的范畴。该领域的专家可以极大地帮助分析一般和特定的需求。

头脑风暴

在不同的涉众之间进行非正式的讨论，并记录他们的所有输入，以便进行进一步的需求分析。

原型设计

原型设计是在不添加细节功能的情况下构建用户界面，以便用户解释预期软件产品的特性。它有助于更好地了解需求。如果在客户端没有安装供开发人员参考的软件，并且客户端不知道自己的需求，开发人员将根据最初提到的需求创建原型。将原型显示给客户，并记录反馈。客户反馈是需求收集的输入。

观察

专家团队访问客户的组织或工作场所。他们观察现有安装系统的实际工作情况。他们观察客户端的工作流程以及执行问题是如何处理的。团队本身得出了一些结论，这些结论有助于形成对软件的期望需求。

软件需求特点

收集软件需求是整个软件开发项目的基础。因此，它们必须是清晰、正确和定义明确的。

完整的软件需求规格必须是：

• 清晰的
• 正确
• 一致的
• 连贯的
• 可理解的
• 可修改的
• 可验证的
• 优先
• 明确的
• 可追踪的
• 可靠的来源

软件需求

我们应该试着理解在需求捕获阶段可能会出现什么样的需求，以及软件系统应该有什么样的需求。

一般来说，软件需求应该分为两类：

功能需求

与软件功能方面相关的需求就属于这一类。

它们定义了软件系统内部和外部的功能。

例子,

• 搜索选项给用户搜索从各种发票。
• 用户应该能够邮寄任何报告给管理层。
• 用户可以被分成组，组可以被赋予单独的权限。
• 应遵守业务规则和管理功能。
• 软件的开发保持了向下的兼容性。

非功能性需求

与软件功能方面无关的需求就属于这一类，它们是用户假定的软件的隐含或预期的特性。

非功能性需求包括-

• 安全
• 日志记录
• 存储
• 配置
• 性能
• 成本
• 互操作性
• 灵活性
• 灾难恢复
• 可访问性

需求在逻辑上被归类为

• 必须具备：没有它们，软件就不能说是可操作的。
• 应该具备：增强软件的功能。
• 可能有：软件仍然可以正常运行这些需求。
• 愿望列表：这些需求并不映射到软件的任何目标。

在开发软件时，“必须有”必须实现，“应该有”是与利益相关者进行辩论和否定的问题，而“可以有”和“愿望列表”可以用于软件更新。

用户界面需求

用户界面是任何软件、硬件或混合系统的重要组成部分。一个软件被广泛接受，如果它是-

• 操作方便
• 快速的反应
• 有效处理操作错误
• 提供简单但一致的用户界面

用户的接受程度主要取决于用户如何使用软件。用户界面是用户感知系统的唯一方式。一个性能良好的软件系统还必须具有吸引人的、清晰的、一致的和响应性强的用户界面。否则，软件系统的功能就不能被方便地利用。如果一个系统提供了有效使用它的方法，那么这个系统就是好的。用户界面要求简述如下-

• 内容表示
• 简单的导航
• 简单的界面
• 响应
• 一致的用户界面元素
• 反馈机制
• 默认设置
• 有目的的布局
• 有策略地使用颜色和纹理。
• 提供帮助的信息
• 以用户为中心的方法
• 基于组的视图设置。

软件系统分析师

IT组织中的系统分析员是这样一个人，他分析所提议的系统的需求，并确保需求被正确地构思和记录下来。分析员的角色在SDLC的软件分析阶段开始。分析员的职责是确保所开发的软件符合客户的要求。

系统分析员的职责如下：

• 分析和理解预期软件的需求
• 了解项目如何对组织目标做出贡献
• 确定需求来源
• 验证要求
• 制定和实施需求管理计划
• 业务、技术、流程和产品需求的文档
• 与客户协调，确定需求的优先级，消除和模糊
• 与客户和其他利益相关者一起确定验收标准

软件度量

软件度量可以理解为对软件的各种属性和方面进行量化和符号化的过程。

软件度量为软件过程和软件产品的各个方面提供度量。

软件度量是软件工程的基本要求。它们不仅有助于控制软件开发过程，而且有助于保持最终产品的优秀质量。

根据Tom DeMarco(软件工程师)的说法，“你不能控制你不能测量的东西。按照他的说法，软件度量的重要性是非常明显的。

让我们看看一些软件指标：

• 大小度量——LOC(代码行)，主要以数千个交付的源代码行计算，表示为KLOC。

功能点计数是对软件提供的功能的度量。功能点计数定义了软件功能方面的大小。

• 复杂度指标——McCabe的圈复杂度量化了程序中独立路径数量的上限，即程序或其模块的复杂度。通过控制流图，用图论概念来表示。
• 质量度量——缺陷、缺陷的类型和原因、后果、严重程度及其影响定义了产品的质量。

在开发过程中发现的缺陷数量和客户端安装或交付产品后报告的缺陷数量，定义产品质量。

• 过程度量——在SDLC的各个阶段，使用的方法和工具、公司标准和开发的性能是软件过程度量。
• 资源度量——所使用的工作、时间和各种资源，表示用于资源度量的度量。