> For the complete documentation index, see [llms.txt](https://docs.system-analyst-base.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.system-analyst-base.ru/soft-skills/trebovaniya/klassifikaciya-trebovanii/uroven-produkt/funkcionalnye-trebovaniya.md).

# Функциональные требования

{% hint style="info" %}
**Функциональные требования** (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Они определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований. Такое соотношение между тремя уровнями требований жизненно важно для успеха проекта.

Пример:

Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна»: «У пассажира должна быть возможность распечатать посадочные талоны на все рейсы, на которые он зарегистрировался» или «Если в профиле пассажира не указаны предпочтения по выбору места, система резервирования должна сама назначить ему место».

{% endhint %}

<figure><img src="/files/vfP7IIRzfGgWQs4iO7kU" alt="" width="563"><figcaption><p>Функциональные требования</p></figcaption></figure>

## Системные требования

**Системные требования** — это требования к продукту, который включает в себя несколько подсистем. Иными словами, это требования, описывающие взаимодействие этих подсистем.

Однако, в практике многих компаний термин «системные требования» часто применяется для обозначения требований третьего уровня. Большинство специалистов понимают, что такое бизнес-требования и пользовательские требования. Но когда речь идет о третьем уровне, мнения расходятся. Я предпочитаю использовать термин «требования к реализации», Вигерс же предлагает «функциональные требования». В то же время, некоторые компании используют для этого уровня термин «системные требования».

В контексте терминологии Вигерса, системные требования можно проиллюстрировать на следующем примере. Допустим, у нас есть интернет-банк, и требуется, чтобы доступ к операциям со счетом осуществлялся через единый сервер приложений. С этим сервером могут взаимодействовать различные клиентские приложения: интернет-банк в браузере пользователя, мобильное приложение или отдельное Java-приложение на компьютере пользователя. Это требование описывает систему в целом, и дает нам понимание, что есть несколько вариантов клиентской части приложения, но все они должны работать с единым сервером.

Источник: <https://www.webursitet.ru/article/vidy-trebovanii-k-programmnomu-produktu.html>
