这是一个简短的系列教程。我们会讲到:
可行性报告。
需求捕获和分析。
需求规范。
需求验证。
需求工程
我们之前已经讨论了需求工程的4个主要活动。
需求工程是一个收集和定义系统应该提供哪些服务的过程。
它侧重于评估系统是否对业务有用(可行性研究)，发现需求(抽取和分析)，将这些需求转换为一些标准格式(规范)，并检查需求是否定义了客户想要的系统(验证)。
在实践中，需求工程不是顺序的过程，它是一个活动交错的迭代过程。
例如，您首先迭代用户需求;抽取、规范和验证，并对系统需求重复相同的步骤。
需求工程的过程
在流程的早期，大部分工作将花费在理解高级业务和用户需求上。在这个过程的后期，将花费更多的精力来引出和理解详细的系统需求。有些人认为需求工程是应用结构化分析方法(如面向对象分析)的过程。这包括分析系统和开发一组图形系统模型，例如用例模型，然后用作系统规范。尽管结构化方法在需求工程过程中扮演着重要的角色，但是这些方法所涵盖的需求工程还远远不止这些。
面向对象的分析和设计将在另一系列教程中讨论。
用户和系统要求
拥有不同级别的详细信息是有用的，因为它可以传递关于为不同类型的读者开发的系统的信息。
因此，最终用户将不关心细节，他们需要一个通用的、抽象的书面需求。
当参与开发的人，他们需要他们的系统到底应该做什么。
如果您没有对不同层次的细节进行清晰的区分，您可能会遇到很多问题和误解。
用户需求
它描述了系统应该提供的服务以及它必须在何种条件下运行的约束。我们不期望看到任何级别的细节，或者系统将做什么，它更多的是通用的需求。
它通常用自然语言编写，并由图表提供。
在本系列的后面，我们将讨论指定需求的不同方法。系统需求
系统需求意味着对系统服务和操作约束(如如何使用系统)以及开发约束(如编程语言)的更详细的描述。
这种级别的细节是那些参与系统开发的人所需要的，比如工程师、系统架构师、测试人员等等。
功能性和非功能性需求
软件需求分为功能性需求和非功能性需求。
功能需求
它涵盖了系统应该提供的主要功能。当表示为用户需求时，它们通常以抽象的方式描述。
但是，更具体的系统功能需求描述了系统的功能、它的输入、处理;它如何对特定的输入做出反应，以及期望输出是什么。
非功能性需求
这些是对系统所提供的功能的约束。
约束，比如系统可以处理多少进程(性能)，系统需要处理哪些(安全)问题，比如SQL注入…
故障率(可靠性)，将使用什么语言和工具(开发)，你需要遵循什么规则来确保系统在组织的法律范围内运行(立法)。
非功能性需求通常比单个功能性需求更为关键。用户通常可以找到解决系统功能不能真正满足他们需求的方法。然而，未能满足非功能性需求可能意味着整个系统无法使用。
例如，如果一架飞机不能满足其可靠性要求，它就不能安全运行，或者如果嵌入式控制系统不能满足其性能要求，控制功能就不能正常运行。
非功能性需求应该是可度量的
只要有可能，我们就应该定量地编写非功能性需求，以便能够对它们进行测试。您可以在测试系统时测量它们，以检查系统是否满足其非功能需求。
非功能性需求的度量
在实践中，系统的客户经常发现很难将他们的目标转化为可度量的需求。他们不明白哪些数字定义了所需的速度或可靠性。对于某些目标，例如可维护性，没有可用的度量标准。
验证可测量的非功能性需求的成本可能非常高，客户可能认为这些成本是不合理的。
非功能性需求和功能性需求是相互依赖的
非功能性需求经常发生冲突、交互，甚至产生其他功能性或非功能性需求。
功能性和非功能性需求之间的区别
在实践中，很难区分功能性和非功能性需求。它们的定义表明，这种区别并不明确。
区分功能性和非功能性需求
如果非功能需求与功能需求分开陈述，它们之间的关系可能难以理解。
涌现属性是系统作为一个整体的属性，而不是从单个系统组件的属性衍生出来的属性。
可行性报告
可行性研究的输入资料是一套初步的业务需求、系统的大纲描述，以及该系统拟如何支援业务流程。
业务需求是客户或开发组织的需求;为什么要开发软件，必须实现一个高层次的目标。
可行性研究的结果应该是一份报告，建议是否继续进行下一个过程，否则你将根本无法实现软件。
我们已经讲过了有用的区别;用户和系统需求，功能性和非功能性需求。除了需求工程中的第一个活动之外;可行性研究。现在，让我们进入下一个。
【jiagoushi_pro】50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化.