软件需求

---

---

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

需求工程

从客户那里收集软件需求，分析并记录这些需求的过程称为需求工程。

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

需求工程流程

这是一个四步流程，包括：

• 可行性研究
• 需求收集
• 软件需求规格说明
• 软件需求验证

让我们简要了解一下这个过程：

可行性研究

当客户联系组织以开发所需产品时，他们会提出一个关于软件必须执行的所有功能以及期望软件具有的所有特性的粗略想法。

参考这些信息，分析人员会详细研究所需系统及其功能是否可行。

此可行性研究侧重于组织的目标。本研究分析软件产品是否可以在实施方面、项目对组织的贡献、成本限制以及根据组织的价值观和目标方面具体实现。它探讨了项目的技术方面和产品，例如可用性、可维护性、生产力和集成能力。

此阶段的输出应为一份可行性研究报告，其中应包含充分的意见和建议，供管理层参考，说明是否应开展该项目。

需求收集

如果可行性报告对开展项目持肯定态度，则下一阶段将从收集用户的需求开始。分析人员和工程师与客户和最终用户沟通，了解他们对软件应该提供的功能以及他们希望软件包含哪些功能的想法。

软件需求规格说明

SRS是由系统分析师在收集完来自各个利益相关者的需求后创建的文档。

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

从客户那里收到的需求是用自然语言书写的。系统分析师有责任以技术语言记录需求，以便软件开发团队能够理解和使用。

SRS应具备以下特点：

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

软件需求验证

在开发需求规格说明后，将验证此文档中提到的需求。用户可能会要求非法的、不切实际的解决方案，或者专家可能会错误地解释需求。如果在萌芽状态时没有解决，这会导致成本大幅增加。需求可以根据以下条件进行检查：

• 如果它们可以在实践中实现
• 如果它们有效，并且符合软件的功能和领域
• 是否存在任何歧义
• 如果它们是完整的
• 如果它们可以被证明

需求获取流程

可以使用以下图表描述需求获取流程

• 需求收集 - 开发人员与客户和最终用户讨论，了解他们对软件的期望。
• 整理需求 - 开发人员根据重要性、紧迫性和便利性对需求进行优先级排序和排列。

• 协商与讨论 - 如果需求不明确或各个利益相关者的需求之间存在冲突，则需要与利益相关者进行协商和讨论。然后可以对需求进行优先级排序并进行合理妥协。

  需求来自各个利益相关者。为了消除歧义和冲突，需要对其进行讨论以确保清晰度和正确性。不切实际的需求会得到合理的妥协。

• 文档化 - 所有正式和非正式、功能性和非功能性需求都将被记录下来，并提供给下一阶段处理。

需求获取技术

需求获取是指通过与客户、最终用户、系统用户以及其他对软件系统开发有利益关系的人员沟通，找出目标软件系统的需求的过程。

有各种方法可以发现需求

访谈

访谈是收集需求的有效媒介。组织可以进行多种类型的访谈，例如

• 结构化（封闭式）访谈，其中要收集的每个信息都事先决定，它们遵循模式并严格遵守讨论事项。
• 非结构化（开放式）访谈，其中要收集的信息没有事先决定，更灵活，偏差更小。
• 口头访谈
• 书面访谈
• 一对一访谈，在两人之间进行。
• 小组访谈，在参与者之间进行。由于涉及众多人员，因此有助于发现任何遗漏的需求。

调查

组织可以通过询问各个利益相关者对即将推出的系统的期望和需求，在他们之间进行调查。

问卷调查

将一份包含预定义的一组客观问题和相应选项的文档分发给所有利益相关者进行答复，然后收集和整理这些答复。

此技术的缺点是，如果问卷中没有提到某个问题的选项，则该问题可能会被忽略。

任务分析

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

领域分析

每个软件都属于某个领域类别。该领域的专家可以极大地帮助分析一般和具体的需求。

头脑风暴

在各个利益相关者之间进行非正式的辩论，并将他们的所有意见记录下来以供进一步的需求分析。

原型设计

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

观察

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

软件需求特征

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

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

• 清晰
• 正确
• 一致
• 连贯
• 易于理解
• 可修改
• 可验证
• 优先级
• 明确
• 可追溯
• 可靠来源

软件需求

我们应该尝试了解在需求获取阶段可能出现哪些类型的需求，以及软件系统期望哪些类型的需求。

从广义上讲，软件需求应分为两类：

功能需求

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

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

例如：

• 提供给用户用于搜索各种发票的搜索选项。
• 用户应该能够将任何报告发送给管理层。
• 用户可以被分成组，并且可以为组分配不同的权限。
• 应遵守业务规则和管理功能。
• 开发软件时，保持向下的兼容性。

非功能需求

与软件功能方面无关的需求属于此类。它们是软件的隐式或期望特性，用户会对此做出假设。

非功能需求包括：

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

需求在逻辑上被分类为

• 必须有：没有它们，软件就不能说是可操作的。
• 应该有：增强软件的功能。
• 可以有：即使有这些需求，软件仍然可以正常运行。
• 愿望清单：这些需求与软件的任何目标都不匹配。

在开发软件时，必须实现“必须有”，而“应该有”则需要与利益相关者进行讨论和协商，而“可以有”和“愿望清单”可以保留用于软件更新。

用户界面需求

UI是任何软件或硬件或混合系统的关键部分。如果软件：

• 易于操作
• 响应迅速
• 有效处理操作错误
• 提供简单而一致的用户界面

用户接受度很大程度上取决于用户如何使用软件。UI 是用户感知系统的唯一途径。一个性能良好的软件系统也必须配备有吸引力、清晰、一致且响应迅速的用户界面。否则，软件系统的功能将无法以方便的方式使用。如果一个系统提供了有效使用它的方法，则称其为好的系统。用户界面需求简述如下：

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

软件系统分析师

IT 组织中的系统分析师是一个人，他分析拟议系统的需求，并确保需求被正确地构思和记录。分析师的角色从 SDLC 的软件分析阶段开始。分析师有责任确保开发的软件满足客户的需求。

系统分析师拥有以下职责

• 分析和理解预期软件的需求
• 理解项目将如何为组织目标做出贡献
• 识别需求来源
• 需求验证
• 开发和实施需求管理计划
• 业务、技术、流程和产品需求的文档化
• 与客户协调，对需求进行优先级排序并消除歧义
• 与客户和其他利益相关者最终确定验收标准

软件度量和衡量

软件度量可以理解为量化和象征软件各种属性和方面的过程。

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

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

根据汤姆·德马科（一位软件工程师）的说法，“你无法控制你无法衡量的东西。”从他的话中可以清楚地看出软件度量的重要性。

让我们来看一些软件度量

• 规模度量 - LOC（代码行数），大多以交付的源代码行数千计计算，表示为 KLOC。

  功能点计数是软件提供的功能的度量。功能点计数定义了软件功能方面的规模。

• 复杂度度量 - 麦凯布环复杂度量化了程序中独立路径数量的上限，这被认为是程序或其模块的复杂度。它通过使用控制流图以图论的概念表示。

• 质量度量 - 缺陷、其类型和原因、后果、严重程度的强度及其影响定义了产品的质量。

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

• 过程度量 - 在 SDLC 的各个阶段，使用的办法和工具、公司标准以及开发的性能都是软件过程度量。
• 资源度量 - 投入、时间和使用的各种资源，代表了资源测量的度量。