为什么需求在软件工程中很重要？

在本文中，我们将讨论需求在软件开发中的重要性以及为什么在构建应用程序时忽略需求阶段不是一个明智的想法的原因。

“工作软件优于综合文档。 ”这是敏捷宣言的一部分。

从表面上看，这种说法似乎暗示需求无关紧要，不值得花时间。 一些开发人员和他们的客户放弃了适当的文档。 但这是一个错误。

让我们先来稍微解释一下软件开发方面的需求。

APP开发有什么要求？

当应用于软件开发时，需求的定义不会发生显着变化。 需求只是指定产品应该包括哪些功能以及这些功能应该如何工作。 你如何接近他们很重要。

收集和分析需求是敏捷和瀑布方法中软件开发过程的初始阶段之一。 在想法验证阶段的需求阶段，客户和开发人员之间必须就最终产品应该做什么以及如何做达成一致。 应用程序开发中的要求通常非常详细。

如何定义软件需求

在软件开发中可以有多种类型的需求。

业务需求

为什么客户需要这个应用程序？ 乍一看，这些信息可能看起来是不必要的，甚至是多余的。 毕竟，您有一个客户想要付钱给您来构建应用程序。 你为什么要关心他们的理由？

好吧，如果您为自己所做的事情感到自豪并努力打造优质产品，那么您应该像关心什么和如何做一样关心为什么。

业务需求的重要性在于它们提供了最终目标的愿景。 有了目标，开发人员可以设置优先级。 他们还可以运用他们的专业知识来提供更好的解决方案来实现这些目标。 大多数公司将业务分析包含在开发过程中是有原因的。

如果没有明确的业务需求，就可能做出错误的决策。 会减慢开发速度、扰乱最后期限并导致额外开发阶段的决策。

软件要求

有两种类型的需求：功能性需求和非功能性需求。 简单来说，区别如下：

功能需求是什么需求——这个系统的设计目的是什么？ 顾名思义，它们描述了软件的功能。

非功能性需求是如何需求——这个系统将如何做它设计要做的事情？ 这些要求描述了每个功能在什么条件下应该如何表现，应该有什么限制等等。

两者齐头并进。 非功能性需求补充并定义了功能性需求。 例如，假设我们正在制作一个消息应用程序。

在这种情况下，主要的功能要求是：

1. 该应用程序必须能够发送消息。
2. 该应用程序必须支持文件和媒体传输。
3. 等等。

这些非常简单，很容易理解为什么功能需求很重要：它们概述了功能。 在这个例子中， 非功能性需求可能如下：

1. 该服务必须在所有主要浏览器中提供完整功能：Microsoft Edge、Google Chrome（最新两个版本）、Mozilla Firefox（最新两个版本）、Opera、Safari（最新版本）。
2. 必须支持移动布局。
3. 等等。

如你看到的， 功能需求基本上是必须包含在系统中的功能列表. 另一方面，非功能性需求是特定的。 它们是定义开发和测试条件所必需的。

确实，迭代敏捷过程需要在开发的任何阶段引入更改的可能性，但这并不意味着完全取消要求。 你只需要让它们变得灵活。

如果没有指定精确的参数，就不可能理解一个功能是否完全按照它应该的方式设计。

必须彻底分析和记录需求。 为什么？ 因为如果不这样做，很多事情都会出错。

未记录要求的达摩克利斯之剑

质量保证专家最了解软件需求的重要性。 当项目需求没有正确布置时，QA 会受到最大的打击。 想象一下，在没有明确指导方针应该做什么以及应该如何做的情况下，试图确定软件是否被正确实施。 这完全是疯了。

然而，这个问题不仅影响测试人员。 没有官方规格意味着以下内容：

• 对于成品甚至功能的构成没有明确的理解。
• 客户不知道在开发结束时会发生什么，也不知道他们付出了什么。
• 开发人员束手无策，不得不根据所说的内容以及他们自己的理解来弄清楚功能的细节。
• 错误。 他们无处不在。

未记录的要求会导致各方沟通不畅。 客户和开发人员对相同术语的不同理解并不罕见。 尤其是当我们谈论一家对客户的业务并不熟悉的外包开发公司时。

反过来，沟通不畅会为不断的返工、更改和错误修复铺平道路。 有可能一切都会按计划进行而没有记录的要求，但这很渺茫。 通常，这条链条以中断的截止日期和成本结束。

为了确保项目开发顺利进行，每个团队成员都必须以相同的方式理解产品的所有部分及其开发过程。 为确保开发人员能够像客户一样看到产品的每个功能，制定了软件需求规范 (SRS)。

细节决定成败：什么才是好的软件需求规范？

现在，实际的软件需求规范可能非常详细，也可能只是功能的概述。 详细程度取决于许多因素。

参与项目的每个人都很容易理解高质量的需求。 这包括客户，他们可能精通也可能不精通技术方面。 一些公司需要一份非常技术性和细节丰富的要求清单，而另一些公司则更喜欢外行的要求。

无论您的文档技术含量如何，都有管理软件需求的一般规则。 甚至还有一个官方标准：IEEE Std 830-1998，“软件需求规范的推荐做法”。 根据标准，这是一个好的 SRS 应该是什么：

• 正确。 这个很容易。 SRS 的正确性由客户和开发人员根据他们达成的协议进行验证。 SRS 应符合技术规范和所有其他管理项目文件。

• 明确的。 SRS 的主要目的之一是消除误传。 这就是为什么每个需求规范都必须写成只有一种可能的解释。 SRS 包含词汇表并不罕见。

• 完成。 应用程序越复杂，SRS 就需要越详细。 完整的 SRS 涵盖从性能要求到功能的方方面面。 它还对设计设置了某些限制。 但是，它从未指定确切的设计。 它只提供参数。

• 一致。 内部一致性意味着 SRS 中的任何语句都不会与同一 SRS 中的其他语句相矛盾。 这是包含词汇表的另一个原因——以便文档中的任何对象、过程和规范都用精确的术语指定。

• 排名重要性和/或稳定性。 在大多数情况下，有必须的要求和想要的要求。 软件需求规范清楚地标记这两种类型很重要。 这将有助于开发人员和项目经理为项目制定分步计划。

• 可验证。 必须有一种方法来测试您包含在 SRS 中的每个要求。 要被认为是可验证的，需求必须包含可衡量的和具体的概念。

• 可修改。 这是指SRS结构。 为了在需要实施变更时不打乱项目工作流程，SRS 需要明确且易于变更，并且不应重复要求。

• 可追溯。 应该很容易识别 SRS 中规定的每个要求的来源。

这些是建议。 实际上，公司可以根据项目、客户和团队的不同，放弃其中的一些要点。 但是有一些指导总是好的。

无论您是专攻 iOS 和 Android 应用程序开发还是 Web 开发，要求都很方便。 它们是通用文档。 它们的外观通常取决于开发人员及其客户。

由于SRS应该对所有相关方都易于理解，因此设计它们的最佳方式也存在争议。 有些人喜欢表格，有些人喜欢列表。 有些开发人员更喜欢他们的规范作为数据流图和图表的可视化形式。 没有单一的正确方法来制作需求规范文档。

结论

以下是当软件需求派上用场时最常见的几点：

• 了解目标
• 估算开发成本
• 制定全面的时间表
• 设定优先事项

是否记录需求是每个开发人员自己决定的事情。 需求的价值取决于项目的规模。 在 Mind Studios，我们更喜欢有条不紊，因此我们记录了所有需求。 如果您对我们的工作方式感兴趣或对一般要求的价值有疑问，请通过我们的联系表格联系我们。