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

需求工程

从客户端收集软件需求，对其进行分析和记录的过程称为需求工程。

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

需求工程流程

这是一个四步过程，其中包括–

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

让我们简要地看一下过程-

可行性研究

当客户与组织联系以开发所需的产品时，会想到一个基本的想法，即软件必须执行的所有功能以及软件应具有的所有功能。

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

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

此阶段的输出应为可行性研究报告，其中应包含足够的意见和建议，以供管理层考虑是否应进行该项目。

需求收集

如果可行性报告对开展该项目有积极意义，则下一阶段从收集用户需求开始。分析师和工程师与客户和最终用户进行交流，以了解他们对软件应提供的内容以及希望软件包含哪些功能的想法。

软件需求规范

SRS是系统分析师从各个利益相关者收集需求之后创建的文档。

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

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

SRS应该具备以下功能：

• 用户要求以自然语言表示。
• 技术要求以结构化语言表示，在组织内部使用。
• 设计说明应以伪代码编写。
• 表单格式和GUI屏幕打印。
• DFD等的条件和数学符号

软件需求验证

制定需求规范后，将验证本文档中提到的需求。用户可能会寻求非法，不切实际的解决方案，或者专家可能会错误地解释需求。如果不及时采取行动，这将导致成本的巨大增加。可以根据以下条件检查需求-

• 如果可以实际实施
• 如果有效，并根据软件的功能和领域
• 如果有任何歧义
• 如果完成了
• 如果可以证明

需求启发过程

需求启发过程可以使用下面的图来描述：

• 需求收集-开发人员与客户和最终用户进行讨论，并从软件中了解他们的期望。
• 组织需求-开发人员按重要性，紧迫性和便利性的顺序对需求进行优先级安排。

• 谈判与讨论-如果需求含糊不清或各种利益相关者的需求存在某些冲突(如果存在)，则与利益相关者进行谈判和讨论。然后可以对需求进行优先排序并合理地折衷。

  要求来自各个利益相关者。为了消除歧义和冲突，为了清楚和正确起见，对它们进行了讨论。不切实际的要求被合理地折中。

• 文件编制–所有正式和非正式，功能和非功能性要求都被记录在案，并可供下一阶段处理。

需求启发技术

需求征询是通过与客户端，最终用户，系统用户以及与软件系统开发有利益关系的其他人进行沟通来找出目标软件系统的需求的过程。

有多种发现需求的方法

面试

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

• 结构化(封闭式)采访，即要事先确定要收集的每个信息，他们会严格遵循讨论的方式和问题。
• 非结构化(开放式)采访，其中收集的信息不是预先确定的，更加灵活且偏见少。
• 口头访谈
• 书面采访
• 桌子对面两个人之间进行的一对一访谈。
• 参加者小组之间进行的小组访谈。由于涉及许多人，因此它们有助于发现任何遗漏的需求。

调查

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

问卷调查

包含一组预先定义的客观问题和相应选项的文档将移交给所有利益相关者回答，并收集和整理。

此技术的缺点是，如果问卷中未提及某个问题的选项，则该问题可能会无人看管。

任务分析

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

领域分析

每个软件都属于某个领域类别。该领域的专家可以为分析一般和特定需求提供很大的帮助。

集思广益

各种利益相关者之间进行了一次非正式辩论，并记录了他们的所有投入以进行进一步的需求分析。

原型制作

原型制作是在不增加详细功能的情况下建立用户界面，以供用户解释预期软件产品的功能。它有助于更好地了解需求。如果客户端没有安装任何软件供开发人员参考，并且客户端不了解自己的要求，则开发人员将根据最初提到的要求创建原型。将原型显示给客户，并记录反馈。客户反馈充当需求收集的输入。

观察

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

软件需求特征

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

完整的软件需求规范必须为：

• 明确
• 正确
• 一致的
• 相干
• 可理解的
• 可修改的
• 可验证的
• 优先
• 明确的
• 可追溯的
• 可靠来源

软件需求

我们应该尝试了解在需求引发阶段可能会产生什么样的需求，以及软件系统会期望什么样的需求。

大致上，软件需求应分为两类：

功能要求

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

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

例子 –

• 赋予用户搜索选项的搜索选项。
• 用户应该能够将任何报告邮寄给管理层。
• 可以将用户分为几组，并且可以给各组单独的权限。
• 应遵守业务规则和行政职能。
• 开发了软件，保持了向下兼容性。

非功能需求

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

非功能性要求包括-

• 安全
• 记录中
• 存储
• 组态
• 性能
• 成本
• 互通性
• 灵活性
• 灾难恢复
• 辅助功能

需求在逻辑上分类为

• 必须具备：没有它们就不能说软件可以运行。
• 应该具有：增强软件的功能。
• 可以有：软件仍能正常使用这些函数的要求。
• 愿望清单：这些要求未映射到软件的任何目标。

在开发软件时，必须实施“必须具备”，“应该具备”是与利益相关者讨论和否定的问题，而可以保留“可能拥有”和“愿望清单”以进行软件更新。

用户界面要求

UI是任何软件，硬件或混合系统的重要组成部分。如果软件符合以下条件，则该软件被广泛接受-

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

用户的接受程度主要取决于用户如何使用该软件。 UI是用户感知系统的唯一方法。一个性能良好的软件系统还必须配备吸引人的，清晰，一致和响应迅速的用户界面。否则无法方便地使用软件系统的功能。如果系统提供了有效使用它的手段，那么它就是好的。用户界面要求简要介绍如下-

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

软件系统分析师

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

系统分析师具有以下职责：

• 分析和了解预期软件的需求
• 了解项目将如何为组织目标做出贡献
• 确定需求来源
• 确认要求
• 制定并实施需求管理计划
• 业务，技术，过程和产品要求的文档
• 与客户协调以优先考虑需求并消除歧义
• 与客户和其他利益相关者敲定验收标准

软件度量标准

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

软件度量标准提供了针对软件过程和软件产品各个方面的度量。

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

根据(软件工程师)Tom DeMarco的说法，“您无法控制无法测量的内容。”用他的话说，很清楚软件措施的重要性。

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

• 大小度量标准-LOC(代码行)，通常以数千个已交付的源代码行来计算，表示为KLOC。

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

• 复杂性指标-McCabe的Cyclomatic复杂性量化了程序中独立路径数量的上限，这被视为程序或其模块的复杂性。它通过使用控制流程图以图论的概念表示。

• 质量指标-缺陷，缺陷的类型和原因，后果，严重性的强度及其含义定义了产品的质量。

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

• 流程指标-在SDLC的各个阶段，所使用的方法和工具，公司标准和开发绩效都是软件流程指标。
• 资源度量标准-工作量，时间和所用的各种资源代表了资源度量标准。