核心的、关键的专业名词

1. 需求工程

• 英文： Requirements Engineering

• 解释： 这是标准的核心主题。它指的是贯穿系统和软件整个生命周期的、所有与需求相关的协同过程的集合。它不仅包括编写需求文档，更涵盖了需求的获取、分析、规格说明、验证、确认和管理等一系列结构化活动。

2. 利益相关方需求

• 英文： Stakeholder Requirement

• 解释： 从用户、客户、维护人员或其他利益相关方的角度陈述的高层次需求。它描述了利益相关方需要系统“做什么”或达到“什么效果”，通常使用利益相关方领域的自然语言表述，而不涉及具体的技术实现方案。

3. 系统需求

• 英文： System Requirement

• 解释： 对系统必须提供的能力和必须遵守的约束的详细陈述，这些陈述使得系统能够满足利益相关方需求。系统需求是系统设计的直接依据，需要足够详细和精确，并且可以被验证。

4. 软件需求规格说明

• 英文： Software Requirements Specification

• 解释： 一份正式文档，它准确地规定了软件系统必须实现的功能和必须满足的条件（约束）。该文档是软件开发、测试和项目验收的基础性文件。标准中提供了该文档的推荐结构和内容模板。

5. 需求验证

• 英文： Requirements Verification

• 解释： 确认需求规格说明文档本身质量的过程。其核心问题是：“我们是否正确地把需求写下来了？” 即检查需求是否满足无歧义、可追溯、一致、完整和可验证等质量特性。

6. 需求确认

• 英文： Requirements Validation

• 解释： 确认所定义的需求能够满足利益相关方意图和业务目标的过程。其核心问题是：“我们写下来的是正确的需求吗？” 它确保我们构建的是“正确”的系统，通常需要利益相关方的深度参与。

7. 可追溯性

• 英文： Traceability

• 解释： 一种能够双向关联不同层级需求以及需求与下游工作产品（如设计、代码、测试用例）之间关系的能力。它包括“向前追溯”（从利益相关方需求到系统需求，再到设计组件）和“向后追溯”（从测试用例回溯到具体需求），对于评估变更影响、确保需求覆盖至关重要。

8. 非功能需求

• 英文： Non-Functional Requirement

• 解释： 描述系统运行时必须表现出来的质量特性或约束条件的需求，而不是具体的行为。例如：性能、安全性、可靠性、可用性、可维护性等。它通常作为功能需求的补充条件或系统的全局性约束。