# Нефункциональные требования {% 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) * --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.system-analyst-base.ru/soft-skills/trebovaniya/klassifikaciya-trebovanii/uroven-produkt/nefunkcionalnye-trebovaniya.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.