> For the complete documentation index, see [llms.txt](https://akrisanov.gitbook.io/team-playbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://akrisanov.gitbook.io/team-playbook/delivery/nefunkcionalnye-trebovaniya.md).

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

*Функциональные требования* описываются ввод и вывод системы. Иногда их можно представить в виде спецификации API-методов.

**Нефункциональные требования** включают приведенные ниже свойства.

Заявленные заказчиком требования почти всегда будут неполными, неверными, а иногда и избыточными. Без уточнения требований реализовать оптимальное решение (см. Простота в поддержке) не получится.

> Любое обсуждение системного дизайна следует начинать с обсуждения и уточнения как функциональных, так и нефункциональных требований.

Нефункциональные требования обычно противопоставляются друг другу.

### Масштабируемость

*Scalability* – способность системы регулировать использование аппаратных ресурсов (железа), чтобы экономически эффективно поддерживать нагрузку.

### Доступность

*Availability* – процент времени, в рамках которого система может принимать запросы и возвращать желаемые ответы.

### Производительность

*Performance* / *время ожидания* (latency) / P99 и *пропускная способность* (throughput) – время, необходимое для того, чтобы запрос пользователя к системе получил ответ.

Максимальная частота запросов, которую может обработать система – это ее *пропускная способность* (bandwidth). Также *bandwidth* — это объем информации, который способен пропустить канал за определенный временной промежуток.

*Пропускная способность* (throughput/bandwidth) – значение, обратное времени ожидания или задержки (latency).

### Отказоустойчивость

*Fault-tolerance* – способность системы продолжать работу при отказе некоторых ее компонентов и предотвращение необратимого ущерба (например, потери данных) в случае падения.

### Безопасность

*Security* – предотвращение неавторизованного доступа к системе.

### Приватность

*Privacy* – контроль доступа к персональной информации (PII), которая может быть использована для идентификации пользователя.

### Точность

*Accuracy* – данные системы необязательно должны быть идеально точными, поэтому часто уместно обсуждать компромисс между точностью и стоимостью или сложностью.

### Согласованность

*Consistency* – совпадают ли данные во всех узлах/машинах.

### Стоимость

*Cost* – расходы на разработку и поддержку системы, отдельных ее компонент и любых комплексных изменений.

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

### Простота в поддержке

Все приведенные свойства связаны друг с другом и определяют насколько сложно построить систему и поддерживать ее в будущем:

* *Complexity* – сложность
* *Maintainability* – удобство в поддержке
* *Debuggability* – удобство отладки
* *Testability* – возможность тестирования