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

需求工程

从客户那里收集软件需求、分析和记录它们的过程称之为需求工程。

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

需求工程过程

这是一个四步骤的过程，其中包括：

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

让我们来看看这个过程。

可行性研究

当客户接近组织以开发所需的产品时，它会粗略地想出软件必须执行的所有功能以及软件期望的所有功能。

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

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

这一阶段的输出应该是一个可行性研究报告，其中应包含对管理层是否开展该项目的充分评论和建议。

需求收集

如果可行性报告对承接该项目是肯定的，下一阶段就从收集用户的需求开始。收集来自各利益相关方的要求后，系统分析员创建SRS文档.分析师和工程师与客户和最终客户沟通，以了解他们对软件你应该提供什么以及他们希望软件包含哪些功能的想法。

软件需求规格

SRS（Software Requirement Specification，软件需求规格）是系统分析师在从各个利益相关者那里收集需求后创建文档。

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

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

SRS应该具备以下功能:

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

软件需求验证

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

• 如果它们可以实际实施。
• 如果它们有效并且符合软件的功能和领域。
• 如果有任何的歧义。
• 如果它们是完整的。
• 如果它们可以被证明。

需求获取过程

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

• 需求收集 开发人员与客户和最终用户讨论并了解他们对软件的期望。
• 组织要求 开发人员按照重要性、紧迫性和方便性的顺序对需求进行优先级排序和安排。
• 谈判和讨论 如果需求不明确或者各个利益相关者的需求存在冲突，如果是，则与利益相关者进行协商和讨论。
  需求来自不同的利益相关者。为了消除歧义和冲突，为了清晰和正确，对它们进行了讨论。不切实际的要求被合理地妥协。
• 文档 所有正式和非正式的、功能性和非功能性的需求都被记录，并可供下一阶段的处理使用。

需求获取技术

需求获取是通过与客户、最终用户、系统用户和其他与软件系统开发有利益关系的人沟通，找出预期软件系统需求的过程。

有多种方法可以发现需求：

面试

面试时收集需求的有力媒介。组织可能会进行多种类型的面试，例如：

• 结构化（封闭式）的采访，其中每一个要收集的信息是预先决定，他们严格遵循讨论的模式和问题。
• 非结构（开放式）的采访，无需事先决定要收集的信息，更灵活且偏见更少。
• 口试。
• 笔试。
• 一对一面试，在桌子对面的两个人之间进行。
• 在参与者之间进行的小组访谈。由于涉及的人员众多，它们有助于发现任何缺失的需求。

调查

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

问卷调查

一份带有预先定义的客观问题和相应选项的文件被交给所有利益相关者回答，这些问题被收集和编译。

这种技术的一个缺点是，如果问卷中没有提到某个问题的选项，这个问题会无人注意。

任务分析

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

领域分析

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

头脑风暴

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

原型设计

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

观察

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

软件需求特点

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

一个完整的软件需求规格必须是:

• 清楚的
• 正确的
• 一致的
• 相关的
• 可理解的
• 可修改的
• 可验证的
• 优先的
• 明确的
• 可追溯的
• 可信的信息来源

软件要求

我们应该尝试了解在需求获取阶段可能会出现什么样的需求，以及从软件系统中期望什么样的需求。

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

功能需求

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

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

例子：

• 为用户提供搜索选项以从各种发票中进行搜索。
• 用户应该能够将任何报告邮寄给管理层。
• 用户可以分为组，组可以被赋予单独的权限。
• 应当遵守业务规则和行政职能.
• 软件开发保持向下兼容性完好.

非功能性需求

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

非功能性需求，包括：

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

需求按逻辑分类为：

• 必须具备 : 没有它们，软件就不能说是可操作性的。
• 应具备 : 增强软件的功能。
• 可以有 : 软件仍然可以在满足这些要求的情况下正常运行。
• 愿望清单 : 这些需求并不映射到软件的任何目标。

在开发软件，'必须拥有'必须执行，“应该有”的争论与利益相关者和否定的问题，而“可能”和“愿望清单”，可以保持软件更新.

用户界面的要求

UI（User Interface，用户界面）是任何软件、硬件或混合系统的重要组成部分。一个软件被广泛接受，那么它是：

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

用户的接受程度主要取决于用户如何使用软件。UI 是用户感知系统的唯一途径。一个性能良好的软件系统还必须配备有吸引力、清晰、一致和响应迅速的用户界面。否则软件系统的功能不能方便的使用。如果一个系统提供了有效使用它的方法，那么它就被认为是好的。下面简要提到用户界面要求：

• 内容呈现
• 轻松导航
• 简单的界面
• 响应迅速
• 一致的 UI 元素
• 反馈机制
• 默认设置
• 针对性布局
• 战略运用色彩和质感
• 提供帮助信息
• 以用户为中心的方法
• 基于组的视图设置

软件系统分析师

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

系统分析员有以下职责:

• 分析和理解意预期软件的需求。
• 了解项目将如何在组织目标作出贡献
• 确定需求来源。
• 需求验证。
• 指定和实施需求管理计划。
• 业务、技术、流程和产品要求的文档。
• 与客户协调，确定需求的优先级并消除歧义。
• 与客户和其他利益相关者最终确定验收标准。

软件指标和度量

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

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

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

据 Tom·DeMarco 的说法，“你无法控制你无法衡量的东西。”用他的话说，软件度量的重要性不言而喻。

让我们来看看一些软件指标:

• 规模：LOC（Line Of Code，代码行），多以交付的数千行源代码行计算，记为 KLOC。
  功能点计数是对软件提供的功能的度量，功能点数定义了软件功能方面的规模。
• 复杂性：McCabe 的圈复杂度量化了程序中独立路径数量的上限，这被视为程序或其规模的复杂性。
• 质量：缺陷、它们的类型和原因、后果、严重程度及其影响决定了产品的质量。
  开发过程中发现的缺陷数和产品在客户端安装或交付后客户报告的缺陷数，定义了产品的质量。
• 流程：在SDLC的各个阶段，所使用的方法和工具、公司标准和开发绩效都是软件过程指标标准。
• 资源： 工作量、时间和使用的各种资源代表了资源测量的指标。