Привет, Хабр! Меня зовут Елена, я ведущий аналитик ИТ-компании SimbirSoft. Сегодня хочу затронуть такую тему, как нефункциональные требования к ИТ-продукту, которым не всегда уделяется должное внимание, а зря. Их несоблюдение может привести к потере прибыли, клиентов, репутации, остановке производственных процессов и большим штрафам, хотя с первого взгляда их влияние на осуществление пользовательского функционала неочевидно. 

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

  • мощности и производительности;

  • безопасности, соответствию стандартам и законодательству;

  • переносимости и совместимости.

При проектировании системы чаще всего говорят о её функциональности: что она должна делать для того, чтобы соответствовать целям бизнеса, как решать те или иные проблемы пользователей, какие ценности им поставляет, как оптимизирует процессы в компании и т.п. Ключевая формулировка – «ИТ-продукт должен делать то-то и то-то». Но это даже не вершина айсберга, это Титаник. Айсбергом в этом случае станет среда, в которой ИТ-система будет существовать после релиза. 

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

Так и с ИТ-системой: она может быть изящной, эффективной, функциональной, даже гениальной и уникальной, но вдребезги разбиться о реалии своего существования. Нужно ли говорить о том, какие за этим стоят риски для бизнеса?

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

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

Нефункциональные требования (НФТ) описывают, как должен работать программный продукт и какими свойствами или характеристиками обладать, чтобы доставить ту ценность, которую несёт система, с учетом условий ее существования. Такие требования вносят вклад в инфраструктуру, а не в поведение системы.

Часто к ним относятся с пренебрежением, ведь их влияние на осуществление пользовательских требований неочевидно. Как показывает практика, именно их несоблюдение напрямую сказывается на отказоустойчивости системы, её безопасности, а также на претензиях со стороны регуляторов.

Нефункциональных требований достаточно много. Подробно они описываются в BABOK (руководство к Своду знаний по бизнес-анализу), в ISO / IEC 25000. В рамках данной статьи мы рассмотрим три: 

  1. Требования, описывающие производительность и мощность. Должны содержать информацию о планируемых нагрузках, которые ваша система должна выдерживать в пиковые моменты ее работы. 

  2. Требования к безопасности и соответствию законодательству и стандартам. Гарантируют, что все данные внутри системы или ее компонентов будут защищены от вредоносных атак или несанкционированного доступа.  

  3. Требования к переносимости и совместимости системы. Они описывают среду, в которой будет использоваться система – устройства, операционные системы, браузеры, другие системы, с которыми приложение должно работать. 

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

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

Представьте, что ваше приложение рассчитано на средний поток в 3000 уникальных посетителей в день. Но тут маркетологи решили провести масштабную кампанию, результатом которой стало общее увеличение количества пользователей в несколько раз. Показателен недавний случай с ИКЕА, сайт которой не справился с нагрузкой после объявления о распродаже.

Другой пример. Во время пандемии ПЦР-тесты были обязательными для въезда в страну, посещения мероприятий, офиса и т.д. На тот момент серьезно возросла нагрузка на ИТ-системы не только лабораторий и медицинских организаций, но и учреждений, куда эти документы необходимо было подгружать. В тот же период многократно увеличилось количество заказов в интернет-магазинах, сервисах доставки готовых блюд и продуктов из супермаркета. 

Конечно, такие ситуации, как пандемия, предугадать сложно. Но действия маркетологов в первом примере должны были бы быть согласованы с ИТ-службой, чтобы предусмотреть все моменты и обеспечить выполнение взятых перед клиентами обязательств. Ведь если нагрузка системы рассчитана неверно, она не справляется и падает. В результате бизнес теряет не только новых пользователей, но и действующих.

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

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

Плохой пример нефункциональных требований:

«Приложение должно максимально быстро реагировать на действия пользователя»

Хороший пример нефункциональных требований: 

«Пользователь, находясь в сети 3G, должен получать расчёт стоимости услуги не более чем за 2 секунды»


Чек-лист «Как определить требования к производительности и мощности»

  1. Сколько запросов в секунду предполагается для системы:

    1. В обычном режиме;

    2. В периоды пиковой нагрузки.

  2. Какое допустимое время ответа сервера:

    1. В обычном режиме;

    2. В периоды пиковой нагрузки.

  3. Какое время загрузки страниц:

    1. Первичная загрузка;

    2. Повторная загрузка.

  4. Сколько пользователей ожидается в системе:

    1. Активных: 

      1. На старте;

      2. Через год;

      3. Через 2 года.

    2. Зарегистрированных:

      1. На старте;

      2. Через год;

      3. Через 2 года.

    3. Одновременно работающих:

      1. В обычном режиме;

      2. В периоды пиковой нагрузки.

  1. Сколько данных можно хранить и что с ними нужно делать:

    1. Ожидаемое число объектов различного типа в день / неделю / месяц / год, а также в пиковые периоды (например, позиций в каталоге, количество сформированных заказов);

    2. Каковы прогнозируемые темпы роста;

    3. Типы хранимых файлов и их объем (документы, изображения, аудио, видео):

      1. Максимальный размер файла;

      2. Есть ли ограничения по количеству загружаемых к объекту/сущности файлов?

      3. Как долго эти данные надо хранить в системе (например, можно удалить их через N лет)?

  2. Есть ли ограничения по характеристикам серверов, какими серверными мощностями обладает заказчик и готов ли он масштабировать их.

  3. Максимальное время для восстановления системы после отказов, например, после отключения серверов.

  4. Процент доступности сервера при обновлении и проведении плановых работ.

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


Безопасность, соответствие стандартам и законодательству

К нефункциональным требованиям по безопасности можно отнести: 

  • соответствие федеральному законодательству о персональных данных, 

  • обязательное лицензирование отдельных видов деятельности, 

  • фискальный учёт, 

  • расположение серверов и хранение данных в определённых юрисдикциях.

Самые чувствительные в этом отношении проекты связаны с хранением и безопасностью персональных данных. Например, FinTech и банковские приложения должны соответствовать как международным стандартам, так и стандартам безопасности отдельных стран. Например, в России – есть требования Федеральной службы по техническому и экспортному контролю, 152-ФЗ «О персональных данных», а за рубежом – требования GDPR

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

Под безопасностью также подразумеваются:

  • правила доступа к функциям: наличие различных ролей пользователей и схема разграничения прав доступа между ними, 

  • требования к шифрованию данных и каналов коммуникации, 

  • использование протокола HTTPS для шифрования передаваемых данных,

  • требования к паролю, правила его сброса и смены,

  • наличие многофакторной аутентификации,

  • управление пользователями: добавление, блокировка, отслеживание активности

Рекомендуем ознакомиться с топ-10 OWASP. Этот стандарт отражает наиболее критичные угрозы для веб-приложений. В этой статье мои коллеги как раз рассказывали о веб-уязвимостях.

Плохой пример: 

Приложение должно соответствовать стандартам безопасности

Хороший пример

Клиент должен взаимодействовать с сервером посредством протокола SSL.


Чек-лист «Как определить требования к безопасности системы»

  1. От каких угроз вы хотите защитить систему.

    Например:
    - при каких обстоятельствах может произойти несанкционированный доступ;
    - какие могут быть прецеденты утечки данных;
    - какие виды вредоносных атак хотите отразить. 

  1. Какие роли пользователей предусмотрены в системе и какими правами они должны быть наделены.

  2. Какая схема авторизации и аутентификации предусматривается:

    1. Требуется ли SSO, нужна ли интеграция с LDAP, Active Directory;

    2. Нужна ли двухфакторная аутентификация;

    3. Какие требования к парольной политике;

    4. Какие требования к продолжительности сессии.

      Например:
      - должен ли пользователь быть разлогинен через какое-то время без активности;
      - удаляется ли текущая сессия при завершении сеанса;

  1. Нужно ли шифровать межсервисный трафик (HTTP, HTTPS).

  2. Предусматривается ли работа с персональными данными:

    1. Обработка;

    2. Хранение (если да, то на какой срок);

    3. Передача третьим сторонам;

    4. Где должны располагаться сервера, хранящие данные.

  3. Обеспечение сохранности данных:

    1. Наличие резервной копии;

    2. Наличие и правила создания точек сохранения БД.

  4. Существуют ли иные требования, влияющие на обработку и хранение данных (например, регламентированные сроки хранения фискальных документов, стандарты обработки данных платёжных карт и т.д.).

  5. Существуют ли соглашения об уровне услуг, устанавливающие требования к работе системы (срок обработки данных, время хранения и т.д.).

  6. Требуются ли лицензии для использования компонентов системы или интеграции со сторонними сервисами. 

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


Переносимость и совместимость

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

Совместимость – это дополнительный аспект переносимости. Она описывает, как система может существовать и взаимодействовать с другими системами и процессами в той же среде.

Например, программное обеспечение, установленное на операционной системе, должно быть совместимо с ее брандмауэром или антивирусной защитой.

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

На данный момент общепринятый стандарт для веб-приложений — кроссплатформенное, кроссбраузерное и мобильное решение.

Нефункциональные требования к переносимости обычно основываются на предварительных исследованиях рынка, полевых исследованиях или аналитических отчётах о типах программного обеспечения и устройств, которыми пользуется целевая аудитория. Определить это помогут аналитические платформы, такие как Google Analytics, Firebase и т.д.

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

Плохой пример

Приложение должно полноценно работать на iPhone и Android

Хороший пример

Приложение должно поддерживать устройства, работающие на операционных системах:

1. iOS 9.0- 16.0 

2. Android 7.0 – 12.0 (учитывая специфические особенности марок Xiaomi, Sony, Huawei)


Чек-лист «Как определить требования к совместимости и переносимости»

  1. На каких типах устройств планируется использовать приложение.

  2. На каких операционных системах должно работать приложение.

  3. В каких браузерах и их версиях должно работать приложение.

  4. Каковы минимальные требования к устройствам и другому оборудованию, необходимые для нормальной работы приложения.

  5. Требования к подключению. Использование каких сетей предполагается для работы приложения и какова их пропускная способность:

    1. Локальная;

    2. Широкополосный интернет;

    3. Мобильный интернет;

    4. Спутниковая связь;

    5. Оффлайн.

  6. С какими системами предполагается интеграция разрабатываемой системы и накладывают ли они какие-то дополнительные требования (использование определённого шифрования, объём принимаемых файлов и т.д.).

  7. Наличие программного обеспечения, существующего в той же среде, способного повлиять на работу приложения (антивирусы, firewall и т.п.).

Исходя из предполагаемых устройств и ОС, формируются требования к дизайну: размеры экранов, ориентация, наличие анимации, использование нативного дизайна и т.д.  


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

Будет очень интересно услышать о вашем опыте работы с нефункциональными требованиями. Что чаще всего используете вы и ваши заказчики?

Надеемся, наша статья была вам полезна!  Еще больше кейсов и материалов для владельцев продуктов – на нашем сайте, в ВК и Telegram.

Комментарии (1)


  1. rsashka
    15.09.2022 14:25
    +2

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

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