Привет, Хабр! Меня зовут Елена, я ведущий аналитик ИТ-компании 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. В периоды пиковой нагрузки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответы на эти вопросы помогут не только грамотно спроектировать архитектуру приложения, но и  повлияют на функциональные требования, например, в части авторизации и аутентификации пользователя, предоставления им согласия на обработку и хранение ПД, хранение 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.