软件需求工程的介绍。

这是一个简短的系列教程。我们会讲到:

• 软件需求工程的介绍。
• 可行性报告。
• 需求捕获和分析。
• 需求规范。
• 需求验证。

需求工程

我们之前已经讨论了需求工程的4个主要活动。

需求工程是一个收集和定义系统应该提供哪些服务的过程。

它侧重于评估系统是否对业务有用(可行性研究)，发现需求(抽取和分析)，将这些需求转换为一些标准格式(规范)，并检查需求是否定义了客户想要的系统(验证)。

在实践中，需求工程不是顺序的过程，它是一个活动交错的迭代过程。

例如，您首先迭代用户需求;抽取、规范和验证，并对系统需求重复相同的步骤。

需求工程的过程

在流程的早期，大部分工作将花费在理解高级业务和用户需求上。在这个过程的后期，将花费更多的精力来引出和理解详细的系统需求。

有些人认为需求工程是应用结构化分析方法(如面向对象分析)的过程。这包括分析系统和开发一组图形系统模型，例如用例模型，然后用作系统规范。

尽管结构化方法在需求工程过程中扮演着重要的角色，但是这些方法所涵盖的需求工程还远远不止这些。

面向对象的分析和设计将在另一系列教程中讨论。

用户和系统要求

通常，需求被分为两个详细层次;用户和系统需求，其中用户需要需求的高级声明，而系统开发人员需要更详细的系统规范。所以，用户和系统的需求只是指不同层次的细节。

拥有不同级别的详细信息是有用的，因为它可以传递关于为不同类型的读者开发的系统的信息。

因此，最终用户将不关心细节，他们需要一个通用的、抽象的书面需求。

当参与开发的人，他们需要他们的系统到底应该做什么。

如果您没有对不同层次的细节进行清晰的区分，您可能会遇到很多问题和误解。

用户需求

它描述了系统应该提供的服务以及它必须在何种条件下运行的约束。我们不期望看到任何级别的细节，或者系统将做什么，它更多的是通用的需求。

它通常用自然语言编写，并由图表提供。

在本系列的后面，我们将讨论指定需求的不同方法。

系统需求

系统需求意味着对系统服务和操作约束(如如何使用系统)以及开发约束(如编程语言)的更详细的描述。

这种级别的细节是那些参与系统开发的人所需要的，比如工程师、系统架构师、测试人员等等。

功能性和非功能性需求

软件需求分为功能性需求和非功能性需求。

功能需求

它涵盖了系统应该提供的主要功能。当表示为用户需求时，它们通常以抽象的方式描述。

但是，更具体的系统功能需求描述了系统的功能、它的输入、处理;它如何对特定的输入做出反应，以及期望输出是什么。

非功能性需求

这些是对系统所提供的功能的约束。

约束，比如系统可以处理多少进程(性能)，系统需要处理哪些(安全)问题，比如SQL注入…

故障率(可靠性)，将使用什么语言和工具(开发)，你需要遵循什么规则来确保系统在组织的法律范围内运行(立法)。

非功能性需求

非功能性需求通常比单个功能性需求更为关键。用户通常可以找到解决系统功能不能真正满足他们需求的方法。然而，未能满足非功能性需求可能意味着整个系统无法使用。

例如，如果一架飞机不能满足其可靠性要求，它就不能安全运行，或者如果嵌入式控制系统不能满足其性能要求，控制功能就不能正常运行。

非功能性需求应该是可度量的

只要有可能，我们就应该定量地编写非功能性需求，以便能够对它们进行测试。您可以在测试系统时测量它们，以检查系统是否满足其非功能需求。

非功能性需求的度量

在实践中，系统的客户经常发现很难将他们的目标转化为可度量的需求。他们不明白哪些数字定义了所需的速度或可靠性。对于某些目标，例如可维护性，没有可用的度量标准。

验证可测量的非功能性需求的成本可能非常高，客户可能认为这些成本是不合理的。

非功能性需求和功能性需求是相互依赖的

非功能性需求经常发生冲突、交互，甚至产生其他功能性或非功能性需求。

与安全有关的用户需求，例如限制对授权用户的访问，可能会生成其他功能性需求，例如需要在系统中包含用户身份验证设施。

功能性和非功能性需求之间的区别

在实践中，很难区分功能性和非功能性需求。它们的定义表明，这种区别并不明确。

区分功能性和非功能性需求

如果非功能需求与功能需求分开陈述，它们之间的关系可能难以理解。

然而，我们应该明确地强调与紧急系统属性(如性能或可靠性)明确相关的需求。

涌现属性是系统作为一个整体的属性，而不是从单个系统组件的属性衍生出来的属性。

可行性报告

在开始使用该软件之前，您需要进行研究，以确定该系统是否值得实施，是否可以在当前的预算、技术技能、时间表下实施，以及它是否对整个组织目标有贡献等等。

可行性研究的输入资料是一套初步的业务需求、系统的大纲描述，以及该系统拟如何支援业务流程。

业务需求是客户或开发组织的需求;为什么要开发软件，必须实现一个高层次的目标。

信息的来源可能是将使用该系统的部门的经理、熟悉拟议系统类型的软件工程师、技术专家、系统的最终用户等。通常情况下，我们应该尝试在两到三周内完成可行性研究。

可行性研究的结果应该是一份报告，建议是否继续进行下一个过程，否则你将根本无法实现软件。

我们已经讲过了有用的区别;用户和系统需求，功能性和非功能性需求。除了需求工程中的第一个活动之外;可行性研究。现在，让我们进入下一个。

 

原文：https://medium.com/omarelgabrys-blog/requirements-engineering-introduction-part-1-6d49001526d3

本文：http://jiagoushi.pro/node/1349

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】