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

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

Возникают вопросы: как узнать целевые значения? Про что я должен подумать в первую очередь, выбирая метрики?

Хотя, во многом, большую роль в формировании НФТ играет архитектор, аналитику полезно иметь общее представление о том, что они из себя представляют и как их можно измерить.

Предлагаю далее рассмотреть перевод статьи на эту тему.
Ссылка на оригинал - https://www.altexsoft.com/blog/non-functional-requ...

Немного о сущности НФТ
Нефункциональное требование - это спецификация, описывающая возможности работы системы, а также ограничения, улучшающие ее функциональность
Представьте, что вы покупаете мотоцикл. Какие функции вы ожидаете увидеть?

Ожидаете ли вы, что он будет двигаться со скоростью 170 миль в час и не развалится?
Сможете ли вы прикрепить к нему коляску или расширить багажное отделение, добавив прицеп? И не забываем о системах безопасности.

Хотя эти требования не описывают напрямую функции транспортного средства: перемещение человека из точки А в точку Б, они по-прежнему важны для удовлетворения ваших потребностей, как водителя.

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

Будь то веб-сайт, мобильное или десктопное приложение, оно должно соответствовать ряду качественных атрибутов для удовлетворения потребностей конечных пользователей.


Что такое нефункциональные требования, они же НФТ?

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

Это могут быть требования к скорости, безопасности, надежности и т. д.
Что говорят стандарты?
Структура стандартов ISO / IEC 25000 определяет нефункциональные требования, как требования к качеству системы и качеству программного обеспечения.

BABOK, один из основных источников знаний для бизнес-аналитиков, предлагает термин нефункциональные требования (NFR), который в настоящее время является наиболее распространенным определением.

Тем не менее, эти обозначения относятся к одному и тому же типу вопросов - требованиям, которые описывают рабочие качества, а не поведение продукта.

При этом их список варьируется в зависимости от типа приложения. Например, если вы собираетесь хранить пользовательские данные и ваш веб-сайт работает в ЕС , вы должны соответствовать регламенту о защите данных GDPR.

В некоторых случаях НФТ могут не иметь отношения к потребностям бизнеса. Например, в случае дополнительных требований соответствия при обработке платежей.

В этой статье будут рассмотрены только самые распространенные типы НФТ, которые должны попасть в ваш чек-лист. Однако их может быть сотни.

Требования будут распределены на несколько групп, поскольку подходы к документированию этих требований совпадают, а также по причине их взаимного влияния друг на друга.
Рассмотрим следующие группы
1. Производительность и масштабируемость
- Как быстро система возвращает ответ на запрос?
- Насколько изменится эта производительность при более высоких нагрузках?

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

3. Надёжность, доступность, ремонтопригодность
- Как часто в системе случаются критические сбои?
- Cколько времени у пользователей есть на время простоя?

4. Безопасность
- Как система и её данные защищены от атак?

5. Локализация
- Соответствует ли система местной специфике?

6. Удобство использования (юзабилити)
- Насколько легко клиенту пользоваться системой?
1. Производительность и масштабируемость
Производительность определяет, насколько быстро работает приложение: как быстро каждый её модуль реагирует на действия определённых пользователей при определённой рабочей нагрузке.

В большинстве случаев эта метрика объясняет, сколько пользователь должен ждать, прежде чем произойдёт целевая операция (отобразится страница, обработается транзакция и т. д.), учитывая общее количество пользователей в данный момент.

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

Масштабируемость оценивает максимальные рабочие нагрузки, при которых система по-прежнему будет соответствовать требованиям к производительности.
Как определить?
1. Начните с рекомендаций Google для обычных веб-страниц

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

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

Основываясь на сумме факторов, Google предлагает разные оценки производительности, которые вы можете использовать в качестве НФТ и для своего веб-сайта.

2. Ознакомьтесь с рекомендациями по времени отклика системы

Якоб Нильсен еще в 1993 году обозначил 3 основных показателя времени отклика. Хотя эти рекомендации могут показаться устаревшими, показатели всё же имеют значение, поскольку они основаны на том, как работает человеческое внимание:
  • 1 секунда - предел, после которого реакция системы уже не кажется пользователю мгновенной;
  • 1 секунда - это время, когда пользователь заметит задержку, но без прерывания мыслей;
  • 10 секунд - время, когда внимание пользователя полностью потеряно.

Обычно вы не захотите достигать этого 10-секундного порога, поскольку около 40 процентов пользователей покидают веб-сайт через 3 секунды.

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

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

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


4. Укажите рабочую нагрузку

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

Возможно, вы захотите добавить в качестве требований и то, и другое. А, возможно, вы захотите установить наивысший порог.

5. Исключайте из НФТ время, необходимое для получения результатов обработки запросов сторонними приложениями

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


6. Не забывайте про архитектурные ограничения

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


7. Учитывайте масштабируемость

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

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

Хотя заранее делать прогнозы сложно, стоит установить хотя бы некоторые значения ожидаемых нагрузок.
Пример требования к производительности
Целевая страница, поддерживающая 5 тыс. пользователей в час, должна обеспечивать время отклика в браузере Chrome для настольных ПК не более 6 секунд, включая рендеринг текста и изображений, через соединение LTE.
2. Переносимость и совместимость
Переносимость определяет, как система или ее компонент могут быть запущены в той или иной среде.

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

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

У переносимости также есть дополнительный аспект, называемый совместимостью.

Совместимость определяет, как система может сосуществовать с другой системой в той же среде.

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

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

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

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


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

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

Рассмотрим максимально полный список требований к переносимости.

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

В рамках переносимости следует рассматривать:

  • Операционные системы и их версии;
  • Специфику сети;
  • Браузеры и их версии;
  • Требования к устройствам и другому оборудованию.

3. Определите совместимость с другими приложениями, включая сторонние

Если система должна сосуществовать со сторонним программным обеспечением или другими приложениями в программной экосистеме, не забываете учитывать и их.
Пример требования к совместимости
Приложение iOS должно поддерживать устройства iPhone, работающие на версиях ОС: 3.6, 3.3, 3.4, 4.3, 2.3.
3. Надёжность, доступность, ремонтопригодность
Хотя эти три типа требований обычно документируются отдельно, в рамках этой статьи они объединены в один раздел, поскольку рассматривают одну и ту же проблему с разных сторон.

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

И, честно говоря, многие поставщики систем вообще не документируют их.


Надежность

Этот атрибут качества указывает, насколько вероятно, что система или её элемент будут работать без сбоев в течение заданного периода времени при заранее определенных условиях.

Традиционно выражается в процентах вероятности. Например, если система имеет 85-процентную надежность в течение месяца, это означает, что в течение этого месяца при нормальных условиях использования c вероятностью 85% мы можем утверждать, что система не выйдет из строя.

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

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

Показатель можно измерить тремя способами:
  • Вероятность в процентах, время;
  • Количество критических отказов, время;
  • Среднее время работы до отказа.

Ремонтопригодность

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

Как и надежность, она может быть выражена в виде вероятности ремонта в течение некоторого времени.

Например, если у вас показатель ремонтопригодности равен 75% в течение 24 часов, это означает, что с вероятностью 75% ошибку в компоненте можно будет исправить за 24 часа.


Доступность

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

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

Например, система может быть доступна 98% времени в течение месяца.

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

Как вы видите, эти три показателя тесно связаны. И, что еще более важно, вы должны подойти к ним одновременно, если решите добавить их в список НФТ вашей системы.
Как определить?
1. Начните с финансовой или другой важной для бизнеса точки зрения

- Можете ли вы позволить, чтобы ваше приложение было недоступно 5% времени?
- Можете ли вы выразить приемлемые потери в финансовых показателях или других ключевых показателях эффективности продукта?


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


2. Укажите компонент системы, для которого вы указываете показатель доступности

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

3. Опишите различные сценарии рабочей нагрузки

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

4. Учитывайте срок службы продукта

При установлении ремонтопригодности / надёжности / доступности учитывайте срок службы программного продукта. Чем он дольше, тем больше смысла в разработке легко обслуживаемого решения.
Другими словами, если вы создаете MVP для проверки гипотез, нет необходимости вкладывать средства в качество разработки на столь раннем этапе.

5. Вернитесь к их определению на этапах разработки и тестирования

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

Так что вполне вероятно, что вы сможете сформулировать эти требования во время предпускового тестирования и производства. Однако упор на качестве кода вы можете сделать и во время самой разработки.
Пример требования к доступности
Веб-сайт должен быть доступен пользователям из США 98% времени каждого месяца в рабочее время EST.
4. Безопасность
Данное нефункциональное требование гарантирует, что все данные внутри системы или ее компонента будут защищены от вредоносных атак или несанкционированного доступа.

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

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

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

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

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

2. Расширьте нефункциональные требования до функциональных

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

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

3. Учитывайте стандарты безопасности

Если ваша система должна соответствовать стандартам или правилам безопасности, секция НФТ - лучшее место для них.
Пример требования к безопасности
Шлюз обработки платежей должен соответствовать требованиям PCI DSS.

5. Локализация
Этот атрибут определяет, насколько хорошо система или её компонент соответствуют контексту местных особенностей.

Контекст включает языки, законы, валюты, культуру и другие аспекты.

Чем больше продукт используется в местном контексте, тем больший успех он должен иметь у определённой целевой аудитории.
Как определить?
1. Положитесь на исследования рынка

Чтобы задокументировать эту группу требований, вы должны полагаться на предварительное исследование рынка, проведенное менеджером по продукту, или полное полевое исследование, проведённое исследователем UX.


2. Будьте конкретны с точки зрения локализации

Если есть несколько вариантов для каждого компонента на одном рынке, все они должны быть рассмотрены. Например, решающее значение имеют язык, валюта, формат адреса и способы оплаты.
Пример требования к локализации
Формат даты должен быть следующим: месяц-дата-год. Например, 11-01-2021.
6. Удобство использования
Удобство использования - еще одно классическое нефункциональное требование, которое отвечает на простой вопрос: насколько сложно использовать продукт?

Определить эти требования не так просто, как кажется.

Есть много типов критериев юзабилити. Один из самых популярных, от Nielsen Norman Group, предлагает оценивать удобство использования по пяти параметрам:

- Обучаемость: насколько быстро пользователи выполняют основные действия, когда видят интерфейс первый раз?
- Эффективность: как быстро пользователи могут достичь своих целей, выполняя действия в системе?
- Запоминаемость: могут ли пользователи через некоторое время вернуться к интерфейсу и сразу же начать с ним эффективно работать?
- Ошибки: как часто пользователи совершают ошибки?
- Удовлетворение: дизайн приятен в использовании?


Помня об этом, вы должны подумать, как сделать эти требования измеримыми.
Как определить?
1. Начните со старого дизайна

Если у вас уже есть продукт, подумайте об измерении количества ошибок при работе в нём. О времени, необходимом для изучения интерфейса и выполнения задач. Это нужно для установления базовых показателей.

2. Установите пороговые значения на основе ключевых показателей эффективности вашего продукта

Можете ли вы позволить себе, чтобы только 50% пользователей могли найти то, что они ищут? Какой процент соответствует вашим стратегическим планам?

3. Проведите юзабилити-тестирование продуктов конкурентов

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

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

Это простая задача, поскольку удобство использования должно быть установлено еще до того, как вы начнёте разработку.
Пример требования к удобству использования
Частота ошибок пользователей, отправляющих свои платежные реквизиты на странице оформления заказа, не должна превышать 10%.

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

1. Сделайте их измеримыми и проверяемыми

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

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

2. Устанавливайте требования к системным компонентам, а не целым продуктам

Подумайте, какие критически важные интерфейсы и системы нуждаются в каких требованиях.

Если ваши пользователи никогда не взаимодействуют с какой-либо частью вашего продукта (например, с панелью администратора), установка ограничений производительности для этих компонентов может быть бесполезной или даже ошибочной, так как ваша команда приложит гораздо больше усилий без очевидной выгоды.

3. Свяжите НФТ с бизнес-целями

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

4. Учитывайте сторонние ограничения

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


5. Думайте об архитектурных ограничениях

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

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


6. Ищите существующие стандарты и руководства

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

Перевод статьи выполнен Селявиной Юлией
Made on
Tilda