> For the complete documentation index, see [llms.txt](https://sallyit.gitbook.io/akademiait/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sallyit.gitbook.io/akademiait/soft-skills/trebovaniya/klassifikaciya-trebovanii/uroven-produkt/nefunkcionalnye-trebovaniya.md).

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

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

качественные характеристики (как?)

**Нефункциональные требования**: содержит подробную информацию о том, как должна работать система. Например, производительность, возможности, масштабируемость, безопасность и т. д. Нефункциональные требования говорят о качественных характеристиках и атрибутах систем.

Нефункциональные требования складываются из трех частей:

### Атрибуты качества <a href="#atributy-kachestva" id="atributy-kachestva"></a>

**Атрибуты качества (quality attributes)** представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков.

Например, к таким характеристикам относятся:

* легкость и простота использования (usability)
* производительность (performance)
* удобство эксплуатации и технического обслуживания (maintainability)
* надежность и устойчивость к сбоям (reliability)
* взаимодействия системы с внешним миром (interfaces)
* расширяемость/масштабируемость (scalability)

<details>

<summary>📎 FRUPS</summary>

К требованиям атрибутов качества ПО относят требования FURPS или FURPS+. Эта модель требований представлена Грейди и Касуэлл, работающими в тот момент времени в компании Hewlett-Packard.

FURPS это пять тезисов:

* **Функциональность** (Functionality). Какие функции должны быть в системе.
* **Устойчивость к отказам** (Reliability). Устойчивость к отказам.
* **Удобство использования** (Usability). Удобство работы пользователей.
* **Производительность** (Performance). Скорость, эффективность, потребление ресурсов, пропускная способность, время отклика.
* **Сопровождаемость** (Supportability). Все вместе: Тестируемость, расширяемость, адаптируемость, ремонтопригодность, совместимость, настраиваемость, удобство обслуживания, локализуемость, портативность.

</details>

#### Примеры <a href="#primery" id="primery"></a>

* Время загрузки главной страницы и карточки товара не должно превышать 3 секунды при нагрузке до 20 посетителей в минуту
* База данных сайта должна устанавливаться на сервера MySQL, MS SQL Server или Oracle без необходимости внемения изменений в установочные скрипты
* Сайт должен быть адаптирован для мобильных устройств

### Ограничения <a href="#ogranicheniya" id="ogranicheniya"></a>

**Ограничения (constraints)** касаются выбора возможности разработки внешнего вида и структуры продукта.

Ограничения - это формулировка условия, которое модифицирует требование или набор требований сужая выбор возможных решений.

#### Примеры <a href="#primery-1" id="primery-1"></a>

Например, "Требуется ограничить загрузку файлов размером более 20мб", "Ограничить работу приложения только на IOS" или только в браузере Chrome и т.д.

Возьмем в качестве примера следующее ограничение: сервер приложений сайта должен разрабатываться на языке Java. Почему такое требование может быть предъявлено? Возможно, потому что у заказчика имеется большое количество специалистов, способных сопровождать работу системы, написанной на этом языке, а все остальные серверы приложений заказчика также функционируют в этой среде.

Другой похожий пример: сайт должен устанавливаться на определенную версию операционной системы.

Приведенные случаи представляют собой наиболее простые виды ограничений. Однако встречаются и более сложные. Эти ограничения мы должны учитывать еще до начала разработки системы, поскольку они сужают область возможных решений в процессе ее создания.

### Внешний интерфейс <a href="#vneshnii-interfeis" id="vneshnii-interfeis"></a>

**Внешние интерфейсы** - описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.

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

Обычно внешние интерфейсы с другими системами уже описаны в виде спецификаций, которым нужно следовать при разработке продукта.

#### Примеры <a href="#primery-2" id="primery-2"></a>

Вот несколько примеров внешних интерфейсов:

1. API социальных сетей для автоматического репоста публикаций с сайта на страничку компании в Facebook. Таким образом, нет необходимости вручную копировать новости, специальное приложение сделает это автоматически.
2. Спецификация взаимодействия с платежным агрегатором для обработки онлайн-платежей на сайте интернет-магазина. Это описание внешнего интерфейса представляет собой определенную спецификацию передачи данных.
3. Протоколы взаимодействия с серверами транспортных компаний для резервирования и оплаты билетов. Например, единый сервис для сравнения и покупки авиабилетов разных авиакомпаний требует наличия внешних интерфейсов для взаимодействия с различными сервисами резервирования и оплаты билетов.

Источники: