软件需求
软件需求是对目标系统特性和功能的描述。需求传达了用户对软件产品的期望。从客户的角度来看，需求可能是明显的或隐藏的、已知的或未知的、预期的或意外的。
需求工程
从客户那里收集软件需求、分析和记录它们的过程称为需求工程。
需求工程的目标是开发和维护复杂且描述性的"系统需求规范"文档。
需求工程过程
这是一个四步过程，包括 -
- 可行性研究
- 需求收集
- 软件需求规范
- 软件需求验证
让我们简要地看一下这个过程 -
可行性研究
当客户与组织接洽以开发所需产品时，它会对软件必须执行的所有功能以及所有功能都有哪些大致的想法软件应具备哪些功能。
根据这些信息，分析师会详细研究所需系统及其功能是否可开发。
此可行性研究侧重于组织的目标。本研究分析软件产品是否可以在实施、项目对组织的贡献、成本约束以及组织的价值观和目标方面实际实现。它探讨了项目和产品的技术方面，例如可用性、可维护性、生产力和集成能力。
此阶段的输出应是一份可行性研究报告，该报告应包含足够的评论和建议，供管理层决定是否应开展该项目。
需求收集
如果可行性报告对开展项目持积极态度，则下一阶段将从收集用户需求开始。分析师和工程师与客户和最终用户沟通，了解他们对软件应提供什么以及他们希望软件包含哪些功能的想法。
软件需求规范
SRS 是系统分析师在从各个利益相关者收集需求后创建的文档。
SRS 定义了预期软件如何与硬件交互、外部接口、运行速度、系统响应时间、软件跨各种平台的可移植性、可维护性、崩溃后的恢复速度、安全性、质量、限制等。
从客户那里收到的需求是用自然语言编写的。系统分析师有责任用技术语言记录需求，以便软件开发团队能够理解和使用它们。
SRS 应具有以下特点：
- 用户需求以自然语言表达。
- 技术需求以组织内部使用的结构化语言表达。
- 设计描述应以伪代码编写。
- 表单和 GUI 屏幕打印的格式。
- DFD 等的条件和数学符号。
软件需求验证
需求规范制定后，本文档中提到的需求将得到验证。用户可能会要求非法、不切实际的解决方案，或者专家可能会错误地解释需求。如果不及时遏制，这将导致成本大幅增加。可以根据以下条件检查需求 -
- 它们是否可以实际实施
- 它们是否有效并且符合软件的功能和领域
- 是否存在任何歧义
- 它们是否完整
- 它们是否可以演示
需求获取过程
需求获取过程可以使用以下图表来描述：
- 需求收集 - 开发人员与客户和最终用户讨论并了解他们对软件的期望。
- 组织需求 - 开发人员根据重要性、紧急性和便利性对需求进行优先排序和安排。
协商和讨论 - 如果需求不明确，或者各利益相关者的需求存在冲突，则与利益相关者进行协商和讨论。然后可以对需求进行优先排序和合理妥协。
需求来自各个利益相关者。为了消除歧义和冲突，需要对需求进行讨论，以确保其清晰和正确。不切实际的需求会得到合理的妥协。
- 文档 - 所有正式和非正式、功能性和非功能性需求均会记录在案，以供下一阶段处理。
需求引出技术
需求引出是通过与客户、最终用户、系统用户和其他与软件系统开发有关的人员沟通，找出预期软件系统需求的过程。
有多种方法可以发现需求
访谈
访谈是收集需求的有效媒介。组织可以进行几种类型的访谈，例如：
- 结构化（封闭式）访谈，其中要收集的每一条信息都是事先决定的，他们严格遵循讨论的模式和内容。
- 非结构化（开放式）访谈，其中要收集的信息不是事先决定的，更灵活，偏见更少。
- 口头访谈
- 书面访谈
- 一对一访谈，在桌子对面的两个人之间进行。
- 小组访谈，在参与者小组之间进行。由于涉及许多人，它们有助于发现任何缺失的要求。
调查
组织可以通过询问他们对即将推出的系统的期望和要求来对各个利益相关者进行调查。
问卷调查
一份包含预定义客观问题和相应选项的文件将交给所有利益相关者进行回答，然后收集并汇编。
这种技术的缺点是，如果问卷中没有提到某个问题的选项，那么该问题可能会被忽略。
任务分析
工程师和开发人员团队可能会分析新系统所需的操作。如果客户已经有一些软件可以执行某些操作，则会对其进行研究并收集拟议系统的需求。
领域分析
每个软件都属于某个领域类别。该领域的专家可以为分析一般和特定需求提供很大帮助。
头脑风暴
在各个利益相关者之间进行非正式辩论，并记录他们的所有意见以进行进一步的需求分析。
原型设计
原型设计是在不添加详细功能的情况下构建用户界面，以便用户解释预期软件产品的功能。它有助于更好地了解需求。如果客户端没有安装软件供开发人员参考，并且客户不了解自己的需求，开发人员将根据最初提到的需求创建原型。原型将展示给客户，并记录反馈。客户反馈将作为需求收集的输入。
观察
专家团队访问客户的组织或工作场所。他们观察现有安装系统的实际工作情况。他们观察客户端的工作流程以及如何处理执行问题。团队本身得出一些结论，有助于形成对软件的预期需求。
软件需求特征
收集软件需求是整个软件开发项目的基础。因此，它们必须清晰、正确且定义明确。
完整的软件需求规范必须是：
- 清晰
- 正确
- 一致
- 连贯
- 易于理解
- 可修改
- 可验证
- 优先化
- 明确
- 可追溯
- 可靠来源
软件需求
我们应该尝试了解在需求获取阶段可能出现哪些类型的需求，以及软件系统需要哪些类型的需求。
广义上，软件需求应分为两类：
功能需求
与软件功能方面相关的需求属于这一类。
它们定义软件系统内部和外部的功能。
示例 -
- 为用户提供搜索选项，以便从各种发票中进行搜索。
- 用户应该能够将任何报告邮寄给管理层。
- 可以将用户分为几组，并且可以为每组赋予单独的权限。
- 应遵守业务规则和管理功能。
- 软件的开发保持向下兼容性。
非功能性需求
与软件功能方面无关的需求属于此类别。它们是软件的隐含或预期特性，用户对此作出假设。
非功能性需求包括 -
- 安全性
- 日志记录
- 存储
- 配置
- 性能
- 成本
- 互操作性
- 灵活性
- 灾难恢复
- 可访问性
需求按逻辑分类为
- 必须具备：没有这些要求，软件就不能运行。
- 应该具备：增强软件的功能。
- 可以具备：软件在满足这些要求的情况下仍能正常运行。
- 愿望清单：这些要求与软件的任何目标都不相关。
在开发软件时，"必须具备"必须实现，"应该具备"是与利益相关者辩论和否定的问题，而"可以具备"和"愿望清单"可以保留用于软件更新。
用户界面要求
UI 是任何软件、硬件或混合系统的重要组成部分。如果软件符合以下条件，它就会被广泛接受 -
- 操作简单
- 响应迅速
- 有效处理操作错误
- 提供简单而一致的用户界面
用户接受度主要取决于用户如何使用软件。UI 是用户感知系统的唯一方式。性能良好的软件系统还必须配备有吸引力、清晰、一致且响应迅速的用户界面。否则，软件系统的功能就无法方便地使用。如果系统提供了有效使用的方法，则该系统被认为是好的。用户界面要求简要如下 -
- 内容呈现
- 易于导航
- 简单的界面
- 响应式
- 一致的 UI 元素
- 反馈机制
- 默认设置
- 有目的的布局
- 策略性地使用颜色和纹理。
- 提供帮助信息
- 以用户为中心的方法
- 基于组的视图设置。
软件系统分析师
IT 组织中的系统分析师是分析拟议系统需求并确保正确构思和记录需求的人员。分析师的角色始于 SDLC 的软件分析阶段。分析师有责任确保开发的软件满足客户的要求。
系统分析师有以下职责：
- 分析和理解预期软件的需求
- 了解项目将如何为组织目标做出贡献
- 识别需求来源
- 需求验证
- 制定和实施需求管理计划
- 业务、技术、流程和产品要求的文档
- 与客户协调以确定需求的优先顺序并消除歧义
- 与客户和其他利益相关者最终确定验收标准
软件度量和测量
软件测量可以理解为量化和符号化软件各种属性和方面的过程。
软件度量为软件过程的各个方面提供测量，软件产品。
软件度量是软件工程的基本要求。它们不仅有助于控制软件开发过程，还有助于保持最终产品的质量优良。
据软件工程师 Tom DeMarco 所说，"你无法控制你无法衡量的东西。"从他的话中，可以清楚地看出软件度量的重要性。
让我们看一些软件指标：
大小指标 - LOC（代码行数），主要以交付的数千行源代码计算，表示为 KLOC。
功能点数是软件提供的功能的度量。功能点数定义了软件功能方面的大小。
- 复杂度指标 - McCabe 的圈复杂度量化了程序中独立路径数量的上限，这被视为程序或其模块的复杂性。它通过使用控制流图以图论概念的形式表示。
质量指标 - 缺陷、其类型和原因、后果、严重程度及其影响决定了产品的质量。
开发过程中发现的缺陷数量以及产品安装或交付给客户端后客户报告的缺陷数量，决定了产品的质量。
- 流程指标 - 在 SDLC 的各个阶段，使用的方法和工具、公司标准和开发绩效都是软件流程指标。
- 资源指标 - 工作量、时间和所使用的各种资源，代表资源测量的指标。
