需求工程包括哪些基本活动
需求工程包括的基本活动有：1、需求获取；2、需求分析；3、需求规范；4、需求确认；5、需求管理。其中，需求获取要深入实际，在充分理解用户需求的基础上，获取足够多的问题领域的知识，积极与用户交流，捕捉、分析和修订用户对目标系统的需求。
1、需求获取
深入实际，在充分理解用户需求的基础上，获取足够多的问题领域的知识，积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合解决领域问题的用户需求。
需求获取过程中的活动
- 需求发现和理解：这是与系统的利益相关者交互以发现其需求的过程。在此活动中，还发现了利益相关者的领域需求和文档。
- 需求分类和组织：此活动采用需求的非结构化集合，将相关需求分组并将其组织成连贯的集群。
- 需求优先级和协商：不可避免地，当涉及多个利益相关者时，需求将发生冲突。该活动涉及对需求进行优先级排序，并通过协商发现和解决需求冲突。通常，利益相关者必须会面以解决分歧，并就折衷要求达成一致。
- 需求文档：将需求文档化并输入下一轮螺旋。软件需求文档的早期草案可能会在这个阶段产生，或者需求可以简单地在白板、wiki或其他共享空间上非正式地维护。
需求获取的方法
需求获取涉及与不同类型的利益相关者会面，你需要花时间了解人们是如何工作的，他们生产什么，他们如何使用其他系统，以及他们可能需要如何改变以适应新系统。有以下几种基本的需求获取方法：
- 问卷法
- 面谈法
- 数据采集法
- 用例法
- 情景实例法
- 基于目标的方法
2、需求分析
在此阶段，对已获取的需求进行分析和提炼，进行抽象描述，建立目标系统的概念模型。
评估系统可行性，并与质量保证团队确认需求是可测试的。开发人员确保需求是可实现的和可理解的。然后，您可以确定列出的需求是否相互矛盾、不完整、不清楚或不明确，并解决这些问题。
需求分析原则
1．必须能够表示和理解问题的信息域
2．必须能够定义软件将完成的功能
3．必须能够表示软件的行为(作为外部事件的结果)
4．必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节
5．分析过程应该从要素信息移向细节信息
需求分析中的目标
该阶段的目标是分解、分析和详述整个系统设计的需求。以下是良好需求的属性，可以帮助您研究和定义您的列表：
独特、必要、一致、清晰、简明、可验证、完整、技术可行、可追溯、可量化、可验证、可操作、有效
3、需求规范
由需求组成的文档称为需求规范文档，这些需求是从各种来源收集的，例如用普通语言表达的客户需求。分析师用普通语言理解客户的需求，并将其转换为开发团队可以轻松理解的技术语言。在需求的规范化过程中使用了几种模型，如实体关系图（ER图）、数据流图（DFD）、数据字典、功能分解图（FDD）等。
- 实体关系图：用于需求规范的另一个工具是实体关系图。它也称为ER图。使用实体关系图（ER图）完成组织逻辑的详细表示。它们使用三种类型的构造：关系、数据实体和与之相关的属性。
- 数据流图（DFD）：可以使用数据流图进行需求建模。通过使用数据流图，可以看到系统内的数据流。这里的系统可以是公司、组织、计算机中的硬件系统、计算机中的软件系统、一组程序或一切的组合。数据流图也称为气泡图或数据流图。
- 数据字典：使用数据流图定义的数据以称为数据字典的存储库的形式存储为信息。客户的数据项必须在需求收集阶段由数据字典定义，以确保客户和开发人员使用相同的方法和定义。
4、需求确认
在制定需求规范后，对文件中规定的需求进行验证。用户可能会提出非法或无法实现的要求，或者专家可能会误解需求。必须在以下方面进行确认。
- 有效性检查：这些检查要求是否反映了系统用户的真实需求。由于环境的变化，用户需求可能自最初引出以来发生了变化。
- 一致性检查：文件中的要求不应冲突。也就是说，同一系统功能不应该有相互矛盾的约束或不同的描述。
- 现实性检查：通过使用现有技术的知识，应检查需求，以确保它们可以在系统的拟议预算内实施。这些检查还应考虑系统开发的预算和时间表。
- 可验证性：为了减少客户和承包商之间发生争议的可能性，应始终编写系统需求，以使其可验证。这意味着您应该能够编写一组测试，以证明交付的系统满足每个指定的要求。
有几种技术用于验证需求。它们是：
- 检查或评审需求：这包括系统和手动分析需求。
- 原型设计：通过使用可执行的模型来检查模型的需求。
- 测试用例：通过开发测试来检查需求的可测试性。
- 自动的一致性分析：检查需求描述的一致性。
5、需求管理
在整个需求工程过程中，贯穿了需求管理活动。需求管理主要包括跟踪和管理需求变化，支持系统的需求演进。由于客户的需要总是不断（连续）增长的，但一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化(变化)就成为软件管理的首要问题。
敏捷开发旨在应对开发过程中发生变化的需求。在这些过程中，当用户提出需求变更时，该变更不会经过正式的变更管理过程。相反，用户必须对更改进行优先级排序，如果是高优先级的，则必须决定为下一次迭代计划的哪些系统特性应该被删除，以实现更改。
