如何创建软件需求规范并改进您的软件开发过程

据 Spiceworks 报道，全球软件市场收入预计将在 2021 年达到5072 亿美元大关。 44% 的公司计划在 2020 年增加技术支出。

软件产品是一项极具竞争力的业务，通常需要大量投资。

因此，它们需要仔细规划。 建议采取所有预防措施并遵循软件需求规范等流程。

在本文中，我们将讨论任何企业为概述其软件开发需求而应采取的五个必要步骤。

我们还将探索：

• 定义软件开发要求的原因以及如何帮助最终产品达到高标准的质量
• 什么是软件需求规范文档
• 在定义软件需求之前你需要知道的事情
• 软件开发中的功能性和非功能性需求是什么
• 具有未记录的软件需求的风险是什么

让我们开始吧！

在寻找开发合作伙伴之前定义软件开发要求的 5 个理由

软件开发需求规定了软件产品应该具有哪些特性以及产品的目标是什么。

您如何处理这些要求会对开发过程产生重大影响，最终也会对最终产品产生影响。

明确定义软件开发需求很重要，因为这可以：

• 确保项目一致性：定义特定的软件需求是软件开发过程的开始，也是后期阶段一致性的保证。 经过长时间的开发，利益相关者可能会对软件应该做什么感到困惑。 定义明确、清晰且可衡量的需求与业务需求相关，并为整个项目和涉及的每个人提供清晰度和重点。
• 节省时间和金钱：当您定义和构建您的软件需求时，就为开发实际产品做好了准备。 尽可能多地提前了解软件需要做什么以及它应该具有哪些功能将更快地产生积极的结果，并且花费更少。
• 提供协作基础：从事软件开发的团队通常由具有非常特殊和特定知识的成员组成。 这尤其适用于使用敏捷开发方法的团队。 定义软件开发需求有助于使它们保持在同一页面上。 需求通过描述产品的所有方面为项目提供了真实的来源和一般指南。 这使每个人都可以更轻松地了解他们在更大范围内的角色。
• 在发生意外变化时提供稳定性：每个开发过程都容易出现突然和意外的变化：设计缺陷、测试失败、管理变更、功能目标改变等。 变更管理很重要，因为它可以控制项目成本的上升，并确保产品的交付不会延迟。 您的软件开发需求应该协调和预测这些可能的变化，以确定可能产生的影响。
• 确保整个软件项目不会失败：未确定优先级、不清楚、不完整或不一致的定义不明确或未定义的软件需求会危及整个软件开发项目。

什么是软件需求规范文档？

软件需求规范 (SRS) 文档概述了未来软件产品的功能和目的、它将做什么以及它将如何执行。

它是软件开发项目的支柱，因为它奠定了项目所有参与方应遵循的基础和指导方针。

软件需求规范文档描述了产品必须具备的功能才能满足其未来用户的期望。

该文件应始终包括：

• 总体描述
• 产品的目的
• 软件的具体要求

除此之外，SRS 文档还需要确定软件如何与硬件集成或与其他软件系统连接。

概述 SRS 文档可以提供有价值的见解，例如：

• 如何最大限度地减少开发时间和成本
• 如何以及何时对软件产品的生命周期做出决定

本文件向各个部门提供有关开发项目的基本信息，使它们保持一致。 这些部门包括：

• 设计
• 发展
• 质量保证测试
• 操作
• 维护

尽管术语“软件”和“系统”有时可以互换使用，但软件需求规范和系统需求规范之间还是有区别的。

软件需求规范描述了将要开发的软件，而系统需求规范文档则收集有关系统需求的信息。

定义软件需求之前需要了解的内容

在规范文档中实际定义软件需求之前，您应该首先建立和理解几件事。

1. 了解软件开发过程

软件开发过程的类型取决于需要完成的项目和开发它的团队。

该过程概述了软件开发生命周期的步骤，每一步都创建了周期下一阶段所需的产品。

软件开发过程包括以下六个基本阶段：

• 软件需求收集和项目分析
• 产品设计
• 实现/编码
• 测试
• 部署
• 维护

每个后续步骤都依赖于前一个步骤并创建一个工作流。 收集到的需求为产品布局和设计奠定了基础。 开发阶段——实现和编码——取决于设计。

检查是否满足要求的测试过程批准或拒绝开发阶段产生的产品。

如果产品满足要求，产品就可以部署到市场上，后续的维护流程也在排队等候。

2. 为您的软件解决方案定义业务需求

每个软件产品都是为了响应特定的业务需求而创建的。 定义和分析软件需求的过程与特定的业务目标相关。

定义软件业务需求的过程可以帮助您的业务确定项目的范围。

这反过来又有助于估计完成所需的资源和时间框架。

了解软件解决方案的业务需求可以更好地理解可以分解为特定细节的业务需求。

如果问题存在并且在分析阶段被发现，那么在当时和那里修复它比在产品发布时修复它要便宜得多。

按照以下步骤定义软件解决方案的业务需求：

• 确定将从软件产品中受益的利益相关者和群体：其中包括项目发起人和客户，他们对项目的范围包括什么有最终决定权。 这些也是需要满足其需求的软件解决方案的最终用户。
• 捕捉他们的需求：上述团队对这个软件解决方案有什么期望？ 他们对产品有什么要求？ 了解每个利益相关者群体的不同观点有助于全面了解项目应该实现的目标。
• 对他们的需求进行分类：将需求分为几个类别，如下所示，使您的分析过程更容易。
  • 功能要求
  • 操作要求
  • 技术要求
  • 过渡要求
• 解释他们的需求：一旦他们的需求和期望被收集和分类，确定哪些是可以实现的以及你的产品如何交付它们是很重要的。 你应该：
  • 优先考虑某些期望
  • 确保它们措辞清晰、足够详细、与业务需求相关且不含糊
  • 解决冲突问题
  • 分析可行性

3. 定义您首选的技术堆栈和开发方法（如果有）

根据您的软件产品的目标、开发团队的规模和其他因素，您可能需要考虑几种能够在给定情况下带来最佳结果的开发方法。

这些是您在开发软件时可以选择的最广泛使用的开发方法。

• 功能驱动开发：这种方法的目标是频繁地交付工作软件并且以客户为中心。 它非常适合较小的开发团队，并且是敏捷和精益方法的先驱。
• Waterfall : 传统的软件开发方式，这是一种计划驱动的方式，需要提前准备大量刚性结构和文档。 在第一阶段，它需要充分了解项目的需求。 适用于不偏离原始想法的大型计划驱动团队。
• 敏捷：与瀑布相反，敏捷方法是灵活的，可以适应开发过程中发生变化的可能性。 它重视单个团队成员及其互动以及客户协作。 非常适合大量协作的团队。
• Scrum ：这种方法采用敏捷的概念，即团队成员应该密切协作并以迭代方法开发软件。 开发人员将最终目标分解为更小的目标，并使用冲刺来构建软件。 对于纪律严明的小型团队来说，这是一种有用的方法。
• 精益：这种方法的基本原则是优化整体、消除浪费、创造知识、快速交付和推迟承诺。 它结合了制造实践并采用敏捷方法在整个组织中扩展它们并将它们应用于开发工作之外。

如何在 5 个步骤中定义和记录软件开发需求

一旦您了解了软件开发过程并定义了业务需求和开发方法，您就可以准备好记录软件开发需求了。

按照以下五个步骤为您要构建的产品创建高质量的软件需求规范文档。

1. 制定软件需求规格说明大纲

定义文档软件开发要求的第一步是为 SRS 创建大纲。

该大纲应包括以下章节：

• 产品用途
  • 观众
  • 用
  • 产品范围
• 产品概览
  • 用户需求
  • 假设和依赖
• 系统要求和功能
  • 系统特点
  • 市场需求
  • 业务需求
  • 用户界面要求
  • 功能要求
  • 非功能性需求

在您的软件需求规范大纲中定义这些项目中的每一个并填写它们意味着您已准备好进入下一步。

2. 定义产品的目的和期望

SRS 文档中的第一章涉及产品的用途。 它为您正在构建的软件解决方案设定了期望。

• 受众和使用：在此部分中，您需要概述整个项目中可以访问文档的人员以及他们应该如何使用它。 他们可以是开发人员、项目经理、测试人员、销售和营销人员或其他部门的利益相关者。
• 产品范围：此部分用于定义您指定的产品。 它应该概述软件解决方案的目标及其好处。

3. 创建已完成软件产品的概述

SRS 产品部分的概述或描述应概述您正在构建的软件。

为了让项目中的每个人都知道他们正在构建什么，您应该提前回答以下问题：

• 该产品是一种新型的解决方案吗？
• 它是对现有产品的更新还是采用？
• 它是已创建产品的附加组件吗？

回答上述问题有助于定义以下内容：

• 用户需求：您的目标受众 - 将使用您的软件解决方案的人 - 属于这一部分。 定义需要您正在构建的软件产品的用户至关重要：有主要和次要用户将定期使用该解决方案，并且可能有单独的购买者，您也需要定义他们的需求。
• 假设和相关性：这一特定部分应概述可能影响满足 SRS 要求的因素。 它还应该包括 STS 所做的假设，这可能是错误的。 此外，请记下软件开发项目所依赖的任何外部因素。

4. 对您的要求非常具体

开发团队将充分利用这一特定部分，因为您需要在此处详细说明构建软件解决方案的具体要求。

它们由功能性和非功能性需求组成，我们将在本文后面深入介绍。 还有：

• 业务需求：构建软件解决方案的业务的高级业务目标。
• 市场要求：概述市场和目标受众需求的要求。
• 外部接口需求：概述产品如何与其他软件集成的功能需求类型。
• 用户界面要求：概述 UI 外观和感觉的规范。 这决定了产品的用户体验。
• 系统功能要求：这些概述了产品运行所需的功能。

5. 让利益相关者批准软件开发要求

在 SRS 文档中定义并记录软件开发需求后，剩下的最后一步就是将其发送给利益相关者进行修订和批准。

每个人都应该查看本文档的最终版本——参与其中的开发和设计团队、委托它的业务或公司、资助它的赞助商以及目标受众样本，以查看其功能和特性。

这是在开始生成解决方案之前确保每个人都在同一页面上的最后一步。

这是 SRS 审核员可以在最后一刻提交改进流程和成品的建议、投诉和想法的时候。

软件开发中的非功能性需求是什么？

在软件开发中，有两种类型的需求：功能性需求和非功能性需求。

• 功能需求：这些是开发团队将要设计、编码和测试的产品功能。 他们定义了有助于解决用户痛点的软件产品的功能。 这些要求由“什么”问题定义，例如：
  • 软件系统应该做什么？
  • 产品将支持哪些功能或功能？
  • 它将管理哪些信息或数据？
• 非功能性需求：这些描述了每个功能在特定条件下的行为方式以及它们应该有哪些限制。 它们描述了对利益相关者很重要的功能。 这些要求由“如何”问题定义，例如：“系统将如何完成其​​设计目的？” 他们制定标准
  • 安全
  • 设计
  • 无障碍
  • 表现
  • 可靠性

非功能性需求补充功能性需求。 前者是特定功能的列表，而后者是软件功能的概述。

举例来说，功能需求可能是软件解决方案发送消息或传输文件的能力。

非功能性需求是在所有主要浏览器和操作系统中提供这些功能性需求，或在移动设备布局中支持它们。

拥有未记录的软件需求的 7 个风险

如果没有指定和记录的软件参数，就不可能知道软件产品及其功能是否被正确开发。

如果没有彻底分析和记录软件需求，很多事情都会出错。

没有正式的软件需求规范可能会导致以下几种情况：

1. 系统中的错误和错误升级
2. 开发人员需要根据语音指令以及他们如何理解它们来辨别特定功能
3. 关于最终产品的制作方法没有正式的、记录在案的协议
4. 客户不知道期望什么最终产品
5. 整个项目及其所有部门都发生了沟通不畅的情况
6. 由于沟通不畅和开发不良，需要修复错误和返工
7. 成本上升，而且很难在最后期限前完成

软件需求规范的要点

在概述和定义软件产品的需求时，最重要的是：

• 了解产品的用途和开发过程
• 定义业务需求
• 确定开发方法
• 定义功能性和非功能性需求
• 制定全面的时间表
• 设定优先级
• 让利益相关者审查软件需求文档