Requirements Engineering

1. 了解用户和系统需求的概念，以及为什么这些需求应该以不同的方式来写。
2. 了解功能性和非功能性软件需求之间的区别。
3. 理解主要的需求工程活动：征询、分析和验证，以及这些活动之间的关系。
4. 了解为什么需求管理是必要的，以及它如何支持其他需求工程活动。

对一个系统的要求是对一个系统应该提供的服务和对其运行的限制的描述。

• 它的范围可以从服务或系统约束的高级、抽象声明到详细、正式的规范。
• 这是不可避免的，因为需求可能具有双重功能
  • 可能是合同竞标的基础 - 因此必须开放解释。
  • 可能是合同本身的基础 - 因此必须详细定义。
  • 这两种说法都可以被称为要求。

发现、分析、记录和检查这些服务和约束的过程被称为需求工程（RE）。

Types of Requirements

• 用户要求：用简洁的语言陈述，加上系统提供的服务和操作限制的图示。
• 系统要求：一个结构化的文件，详细描述了系统的功能、服务和操作限制。定义了应该实施的内容。可能是客户和承包商之间合同的一部分。
• 为了向不同类型的利益相关者传递系统的信息，需要不同类型的要求。

stakeholders

以某种方式受到系统影响的任何个人或组织.

Agile Requirements

Requirements in agile processes

• 许多敏捷方法认为，制作详细的系统需求是浪费时间，因为需求变化如此之快，以至于需求文件总是过时的。
• 敏捷方法通常使用增量的需求工程，并可能将需求表达为 "用户故事"。
• 这对业务系统来说是实用的，但对需要交付前分析的系统（如关键系统）或由几个团队开发的系统来说就有问题。

一种 "传统 "的需求观点

• 对于大多数大型系统来说，在开始实施系统之前，仍然有一个清晰可辨的需求工程阶段。
• 结果是需求文档。

Functional or NF Requirements

• Functional requirements
  • 说明系统应该提供的服务，系统对特定的输入应该如何反应，以及系统在特定情况下应该如何表现。
  • May 说明系统不应该做什么。
• Non-Functional requirements
  • 对系统所提供的服务或功能的限制。
  • 通常适用于整个系统，而不是系统的个别功能或服务。

在实践中，这两种类型的区别并不像这些简单的定义所暗示的那样明确。

• Requirements are not independent
• 系统需求应指定系统的服务或功能，以及确保有效提供服务和功能的必要功能。

Functional Requirements

描述功能或系统服务

• 取决于正在开发的软件的类型，软件的预期用户，以及组织在编写需求时采取的一般方法。
• 功能性用户需求可能是系统应该做什么的高级陈述。
• 功能性系统需求应详细描述系统服务。