> 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/nefunkcionalnye-trebovaniya.md).
# Нефункциональные требования
{% hint style="info" %}
**Нефункциональные требования**: содержит подробную информацию о том, как должна работать система. Например, производительность, возможности, масштабируемость, безопасность и т. д. Нефункциональные требования говорят о качественных характеристиках и атрибутах систем.
{% endhint %}
Нефункциональные требования складываются из трех частей:
Нефункциональные требования
## Атрибуты качества
**Атрибуты качества (quality attributes)** представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков.
Например, к таким характеристикам относятся:
* легкость и простота использования (usability)
* производительность (performance)
* удобство эксплуатации и технического обслуживания (maintainability)
* надежность и устойчивость к сбоям (reliability)
* взаимодействия системы с внешним миром (interfaces)
* расширяемость/масштабируемость (scalability)
📎 FRUPS
К требованиям атрибутов качества ПО относят требования FURPS или FURPS+. Эта модель требований представлена Грейди и Касуэлл, работающими в тот момент времени в компании Hewlett-Packard.
FURPS это пять тезисов:
* **Функциональность** (Functionality). Какие функции должны быть в системе.
* **Устойчивость к отказам** (Reliability). Устойчивость к отказам.
* **Удобство использования** (Usability). Удобство работы пользователей.
* **Производительность** (Performance). Скорость, эффективность, потребление ресурсов, пропускная способность, время отклика.
* **Сопровождаемость** (Supportability). Все вместе: Тестируемость, расширяемость, адаптируемость, ремонтопригодность, совместимость, настраиваемость, удобство обслуживания, локализуемость, портативность.
### Примеры
* Время загрузки главной страницы и карточки товара не должно превышать 3 секунды при нагрузке до 20 посетителей в минуту
* База данных сайта должна устанавливаться на сервера MySQL, MS SQL Server или Oracle без необходимости внемения изменений в установочные скрипты
* Сайт должен быть адаптирован для мобильных устройств
## Ограничения
**Ограничения (constraints)** касаются выбора возможности разработки внешнего вида и структуры продукта.
Ограничения - это формулировка условия, которое модифицирует требование или набор требований сужая выбор возможных решений.
### Примеры
Например, "Требуется ограничить загрузку файлов размером более 20мб", "Ограничить работу приложения только на IOS" или только в браузере Chrome и т.д.
Возьмем в качестве примера следующее ограничение: сервер приложений сайта должен разрабатываться на языке Java. Почему такое требование может быть предъявлено? Возможно, потому что у заказчика имеется большое количество специалистов, способных сопровождать работу системы, написанной на этом языке, а все остальные серверы приложений заказчика также функционируют в этой среде.
Другой похожий пример: сайт должен устанавливаться на определенную версию операционной системы.
Приведенные случаи представляют собой наиболее простые виды ограничений. Однако встречаются и более сложные. Эти ограничения мы должны учитывать еще до начала разработки системы, поскольку они сужают область возможных решений в процессе ее создания.
## Внешний интерфейс
**Внешние интерфейсы** - описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.
Сегодня внешние интерфейсы играют все более важную роль в разработке систем. В эпоху интернета, когда приложения все чаще взаимодействуют друг с другом и создают единую среду, внешние интерфейсы начинают замещать и даже вытеснять пользовательские требования. Хотя большинство систем по-прежнему разрабатывается для людей, все больше систем создается с целью обеспечения взаимодействия между машинами.
Обычно внешние интерфейсы с другими системами уже описаны в виде спецификаций, которым нужно следовать при разработке продукта.
### Примеры
Вот несколько примеров внешних интерфейсов:
1. API социальных сетей для автоматического репоста публикаций с сайта на страничку компании в Facebook. Таким образом, нет необходимости вручную копировать новости, специальное приложение сделает это автоматически.
2. Спецификация взаимодействия с платежным агрегатором для обработки онлайн-платежей на сайте интернет-магазина. Это описание внешнего интерфейса представляет собой определенную спецификацию передачи данных.
3. Протоколы взаимодействия с серверами транспортных компаний для резервирования и оплаты билетов. Например, единый сервис для сравнения и покупки авиабилетов разных авиакомпаний требует наличия внешних интерфейсов для взаимодействия с различными сервисами резервирования и оплаты билетов.
Источники:
*
* [https://analytics.infozone.pro/requirements-analysis/analysis-of-requirements-wiegers-2004](https://analytics.infozone.pro/requirements-analysis/analysis-of-requirements-wiegers-2004/)
*
* [pikabu.ru/story/karera\_v\_it\_sistemnyiy\_analitik\_chast\_1\_vidyi\_i\_kachestva\_trebovaniy\_9945259](https://pikabu.ru/story/karera_v_it_sistemnyiy_analitik_chast_1_vidyi_i_kachestva_trebovaniy_9945259)
*