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

Классы нефункциональных требований

• Атрибуты качества. Это описание различных характеристик продукта, таких как производительность, доступность, совместимость, надёжность и прочих.
  Пример атрибута качества: «Система должна быть доступна ежедневно с 06:00 до 20:00 GMT+3».
• Требования к внешним интерфейсам. Включают в себя описание аспектов того, как пользователь взаимодействует с системой и как система взаимодействует с другой системой.
  Пример требования к внешним интерфейсам: «Авторизация во внешней системе Б должна выполняться по типу Basic Auth».
• Ограничения проектирования и реализации. Этот класс требований позволяет команде разработки понять, какие факторы нужно учитывать при проектировании продукта.
  Пример ограничения проектирования и реализации: «Интерфейс приложения должен быть адаптирован под экраны с разрешением 8K (7680 x 4320 px)».

Атрибуты качества

• Внешние атрибуты качества отвечают за то, насколько легко пользователям и заинтересованным лицам решать свои задачи. Эти характеристики ощутимы для пользователя и влияют на то, как он воспринимает продукт.
  Как именно? Допустим, функции продукта позволяют пользователю решить его проблему и может показаться, что этого достаточно. Но если в процессе ПО постоянно зависает или нужные для решения опции трудно найти с первого раза, у пользователя создаётся впечатление, что продукт некачественный.
• Внутренние атрибуты качества отвечают за то, насколько эффективно продукт работает с точки зрения его создателей. Эти характеристики только на первый взгляд кажутся незаметными для пользователя и важными для разработчиков и тестировщиков. На самом деле они непосредственно влияют на возможность развития продукта и позволяют представить, как много усилий нужно для того, чтобы что-то поменять в продукте. Как правило, эти требования составляются вместе с командой разработки.

1. Доступность — время, в течение которого сервисы системы полностью доступны для пользователя.
   Например: «Приложение должно быть доступно не менее 99% времени в сутки, за исключением времени планового обслуживания».
   Это требование говорит, что приложение должно быть доступно пользователям как минимум 23 часа 38 минут в сутки. Если приложение будет недоступно для пользователей больше 14 минут 24 секунд в сутки, это говорит о снижении качества.
2. Удобство установки — то, насколько просто пользователю установить, обновить, удалить и переустановить приложение.
   Например: «При обновлении версии приложения должна сохраниться авторизация пользователя и все настройки его профиля».
3. Целостность — характеризует качество защиты данных. В частности, безопасность хранения данных и возможность в определённых ситуациях восстановить их.
   Например: «Система должна бессрочно хранить все данные заказов активного пользователя».
4. Совместимость — характеризует возможность системы взаимодействовать и обмениваться данными с другими системами.
   Например: «Система должна иметь возможность запрашивать и получать список продуктов из системы „Склад”».
5. Производительность — скорость реакции системы на действия пользователя и другие внешние события. Система не просто должна работать быстро, она должна иметь точные показатели требуемой скорости работы.
   Например: «Система должна уведомлять пользователя об изменении статуса заказа не позднее 10 секунд после изменения».
6. Надёжность — то, как долго система работает без сбоев в течение определённого времени. Любая система может дать сбой, из-за чего снизится её доступность. Надёжность системы определяется именно тем, как она должна вести себя в подобных ситуациях.
   Например: «Количество заказов, завершённых по причине ошибок в работе системы или её компонентов, не должно превышать более 0,1% от всех заказов в сутки».
7. Устойчивость — характеризует способность системы сохранять работоспособность в разных ситуациях и реагировать на них. То, как система ведёт себя во время нештатных ситуаций и сбоев, определяет её устойчивость.
   Например: «Если при работе с приложением произошёл сбой и был выполнен автоматический перезапуск приложения, система должна восстановить состав корзины по состоянию на момент последнего изменения».
8. Защита — то, насколько пользователю физически безопасно взаимодействовать с системой.
   Например: «При наличии в корзине товаров, у которых срок годности закончится спустя двое суток от текущей даты, система должна уведомить пользователя о наличии таких товаров в корзине».

9. Безопасность — если атрибут «целостность» характеризует безопасность данных с точки зрения их хранения, то атрибут «безопасность» описывает требования к системе по защите этих данных от неправомерного доступа.
   Например: «При входе в приложение система должна запрашивать подтверждение в виде четырёхзначного кода».
10. Удобство использования — определяет то, насколько пользователю удобно и комфортно работать с продуктом. На самом деле удобство использования учитывается в описанных выше атрибутах, а также пользовательских интерфейсах. При этом не лишне дать дополнительные критерии удобства.
    Например: «Пользователь, который не авторизован в приложении, должен проходить путь от авторизации до просмотра витрины с товарами не более чем за 15 секунд».

1. Эффективность — говорит о том, насколько хорошо система использует ресурсы компьютера. Если система требует слишком больших ресурсов для работы, например, слишком много оперативной памяти и, как следствие, замедляет работу остальных программ, то это может привести к недовольству пользователей и общему снижению качества продукта.
   Например: «При размещении готовой версии приложения в AppStore и Google Play размер приложения должен быть менее 200 Мб».
2. Возможность модификации — этот атрибут качества очень важен для часто меняющихся продуктов. Поэтому он актуален для всех ПО, которые разрабатываются в рамках гибких подходов или по методу набегающей волны. Возможность модификации в первую очередь позволяет понять, насколько просто внести правки в существующий код ПО и изменить продукт.
   Например: «Управление версиями продукта должно осуществляться с помощью Git».
3. Переносимость — характеризует то, насколько просто перенести продукт и все данные из одной среды в другую. Например, легко ли сделать так, чтобы приложение, которое работает с операционной системой iOS, заработало и на Android? Для этого нужно переписать 99% кода или 10%? А если пользователь поменяет старый ноутбук на новый, насколько просто перенести все данные приложения с одного устройства на другое? Ответы на эти и подобные вопросы определяет качество продукта.
   Например: «Приложение должно запускаться в операционных системах Unix, Windows и MacOS».
4. Возможность повторного использования — переиспользование некоторых компонентов ПО повышает его качество и упрощает процесс развития. Например, повторное использование дизайна интерфейса, программного кода, базы данных экономит время на разработке. Требования к этому атрибуту качества обычно представляют собой единые требования к элементам интерфейса, использование библиотек и многое другое.
   Например: «Функциональность обращения в техподдержку должна быть спроектирована таким образом, чтобы её можно было переиспользовать в любых пользовательских сценариях».
5. Масштабируемость — ещё один важный фактор, который влияет на возможность развития продукта. Этот атрибут качества говорит о возможности масштабирования продукта так, чтобы он мог пропускать через себя больше пользователей, сохраняя при этом высокую производительность и оставаясь устойчивым к нагрузкам.
   Например: «Необходимо обеспечить быструю (менее одной секунды) загрузку изображений товаров в условиях запуска маркетинговых кампаний и планового увеличения суточной посещаемости на 60%».
6. Тестируемость — если тестирование одной функции (то есть проверка её работы) отнимает много времени и ресурсов, то изменение такой функциональности будет дорого обходиться. Поэтому тестируемость продукта — это тоже показатель качества.
   Например: «Должна быть предоставлена возможность отслеживания результата тестирования каждого отдельного функционального требования в одном рабочем пространстве».

Требования к внешним интерфейсам

1. Пользовательские интерфейсы (UI) Требования к пользовательским интерфейсам содержат описание каждой части интерфейса, включая размеры экранов и всех его элементов, а также стилевые характеристики — шрифты, цветовые схемы и прочие.
2. Программные интерфейсы Требования к программным интерфейсам включают в себя описание взаимодействия системы с другими ПО, а также описания взаимодействия компонентов системы между собой. Подробнее о программных интерфейсах вы узнаете в следующих спринтах курса.
3. Аппаратные интерфейсы Работа ПО может зависеть от оборудования, с которым оно взаимодействует. Для такого программного обеспечения нужно указывать требования к аппаратным интерфейсам (физическим), например виды поддерживаемых устройств, типы физических носителей, протоколы обмена данными между ПО и оборудованием. Пример аппаратного требования — требование о запуске компьютерной игры на устройствах только с видеокартой определённой версии.
4. Коммуникационные интерфейсы Для систем, которые взаимодействуют с пользователем и обмениваются с ним данными посредством внешних систем, например браузера, электронной почты, описываются требования для интерфейсов коммуникации с пользователем.

5. Требования к внешним интерфейсам
   6. Пользовательские интерфейсы
      5.1.1 Карточка товара должна содержать информацию о калорийности продукта в табличной форме.
   7. Программные интерфейсы
      5.2.1 Система дисконтных карт партнёра А.
      5.2.1.1 Система должна запрашивать статус активности дисконтной карты в системе дисконтных карт партнёра А.
   8. Аппаратные интерфейсы
      Неприменимо.
   9. Коммуникационные интерфейсы**
      5.4.1 Система должна отправлять пользователю смс-сообщение с уникальным кодом для подтверждения смены пароля учётной записи.

Ограничения проектирования и реализации

2. Общее описание
   ….
   2.4 Ограничения проектирования и реализации
   Продукт должен быть разработан с использованием библиотеки React и фреймворка Jest для проведения быстрого тестирования новой версии приложения.

Подведём итоги

• Заинтересованные лица часто описывают нефункциональные требования как характеристики продукта. Системный аналитик должен их конкретизировать и превратить именно в требования.
  • «Приложение должно работать быстро» — скажут вам заинтересованные лица. Что значит «быстро»? Как мы будем измерять эту скорость?
  • «Приложение должно работать на всех компьютерах». Что значит «на всех»? Каковы конкретные модели, размеры экранов, операционные системы этих компьютеров?
• Нефункциональные требования делятся на классы:
  • Атрибуты качества
  • Требования к внешним интерфейсам
  • Ограничения проектирования и реализации
• Атрибуты качества — это характеристики системы, которые влияют на лёгкость выполнения задач пользователями, а также на эффективность работы продукта с точки зрения разработчика.
• Требования к внешним интерфейсам описывают любое взаимодействие ПО с внешним миром: пользователями, другими системами и оборудованием.
• Ограничения проектирования и реализации — это особенности реализации, которые могут существенно влиять на архитектуру, процесс разработки и внутренние атрибуты качества.
• Нефункциональные требования составляются так же, как и функциональные: в форме утверждений со словами «должен» или «должна».