---
title: "Requirements"
source: "https://systems-analysis.info/eng/Requirements"
wiki: "systems-analysis.info/eng"
article: "Requirements"
language: "en"
categories:
  - "Category:English"
  - "Category:Science"
  - "Category:Systems engineering"
  - "Category:Terms"
revision_id: 328
wiki_created_at: 2026-09-06T22:22:10Z
wiki_modified_at: 2026-09-06T22:22:10Z
downloaded_at: 2026-09-07T22:22:43Z
---

# Requirements

A **requirement** is a formalized (documented) statement that describes what a system must provide, the level of quality it must achieve, or the physical/operational properties it must possess. It is formulated in such a way that it can be unambiguously linked to an original user need and subsequently tested (verified).

## Types of Requirements

Types of requirements:

- **Functional requirements:** Define what a given system element must do.
- **Accuracy requirements:** Define the quantitative parameters of the corresponding functions performed by the system.
- **Constraint requirements:** Arise from limitations related to the operational mode, environmental conditions, safety, or regulatory compliance.
- **Verification requirements:** Ensure the level of confidence that the system possesses the specified characteristics in its real operating environment.
- **Interface requirements:** Define the functions, characteristics, tolerances, and limitations of all interfaces.
- **Operational requirements:** Define the operational capability of the system and its interaction with users.

## SMART

The acronym SMART is used as a mnemonic for the characteristics of good requirements.

- **Specific** — The requirement describes only one function or characteristic of the system, stating *what* and *how well* it must be performed, without specifying the implementation method.
- **Measurable** — The parameter is expressed objectively: as a number, range, tolerance, or another verifiable criterion that allows for unambiguous confirmation of its fulfillment.
- **Achievable** — Fulfillment is realistic given the available technology, timeline, and budget, with an acceptable level of risk.
- **Relevant** - The requirement must be appropriate for the selected system level.
- **Traceable** — The requirement has a unique identifier and a documented source; it is logically linked to higher-level requirements and the need that generated it, ensuring bidirectional traceability.

## External links

- <a href="https://en.wikipedia.org/wiki/Requirement" class="external text" rel="nofollow">Requirement — Wikipedia</a>

## See also

- [System life cycle](https://systems-analysis.info/eng/System_life_cycle "System life cycle")
- [Systems engineering standards](https://systems-analysis.info/eng/Systems_engineering_standards "Systems engineering standards")
- [Goal (systems analysis)](https://systems-analysis.info/eng/Goal_(systems_analysis) "Goal (systems analysis)")
- [Systems analysis in IT](https://systems-analysis.info/eng/Systems_analysis_in_IT "Systems analysis in IT")

## Bibliography

- 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