---
title: "Requirements — 需求"
source: "https://systems-analysis.info/int/Requirements_%E2%80%94_%E9%9C%80%E6%B1%82"
wiki: "systems-analysis.info/int"
article: "Requirements_—_需求"
language: "zh"
categories:
  - "Category:Chinese"
  - "Category:Systems analysis terms"
  - "Category:Systems engineering"
  - "Category:Terms"
revision_id: 6371
wiki_created_at: 2026-09-07T00:03:21Z
wiki_modified_at: 2026-09-07T00:03:21Z
downloaded_at: 2026-09-07T23:13:33Z
---

# Requirements — 需求

**需求** (*Requirement*) 是一种形式化（已记录）的陈述，描述了系统必须提供什么、应具备何种质量水平或物理/操作特性。其表述方式应能明确地与用户的原始需求相关联，并可在后续进行验证（verification）。

## 需求类型

需求类型包括：

- **功能需求：** 定义系统中的某个元素应该做什么。
- **精度需求：** 定义系统执行相应功能的量化参数。
- **约束需求：** 源于操作模式、环境条件、安全性或合规性的限制。
- **验证需求：** 确保系统在实际运行环境中具备所规定特性的可信度。
- **接口需求：** 定义所有接口的功能、特性、公差和限制。
- **运营需求：** 定义系统的可操作性及其与用户的交互。

## SMART - SMART原则

为记忆良好需求的特征，可使用缩写 SMART。

- **Specific (具体的)** — 需求应只描述系统的一个功能或特性，明确说明*什么*和*多好*必须被完成，而不指明实现方式。
- **Measurable (可衡量的)** — 参数应通过数字、范围、容差或其他可验证的标准进行客观表达，以便明确确认其完成情况。
- **Achievable (可实现的)** — 在现有技术、时间和预算条件下，需求的实现是现实的，并且风险水平可接受。
- **Relevant (相关的)** - 需求应与所选的系统层级相关。
- **Traceable (可追溯的)** — 需求应有唯一的标识符和记录在案的来源；它应与更高级别的需求及其产生的原始需求有逻辑关联，以确保双向追溯性。

## 参考文献

- ISO/IEC/IEEE 29148:2018 «Systems and Software Engineering — Requirements Engineering»
- ISO/IEC/IEEE 15288:2023 «System Life-Cycle Processes»
- PMI: Requirements Management — A Practice Guide, 2015
- INCOSE Guide to Writing Requirements, 2023