Как собрать нефункциональные требования или NFR? Советы и рекомендации

Как собрать нефункциональные требования или NFR?

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

Проблемы с производительностью:

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

Ненадежность системы:

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

Проблемы с безопасностью:

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

Отсутствие масштабируемости:

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

Что тут можно посоветовать:

🔥Устанавливать требования к компонентам системы, а не к целому продукту. Определите критически важные интерфейсы и системы, требующие особых требований. Если ваши пользователи никогда не взаимодействуют с определёнными частями продукта (например, с панелью администратора), наложение ограничений на производительность этих компонентов может быть нецелесообразным или даже контрпродуктивным. В этом случае ваша команда потратит значительные ресурсы без ощутимых преимуществ.

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

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

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

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

🔞А теперь самое страшное, о чем вы должны знать: ТЗ может меняться в ходе проекта и кажется это нормально. Реалии разработки более-менее сложного проекта таковы, что учесть все - реально невозможно (если вы не супермен). А еще - иногда на ваше ТЗ будут “забивать”, потому что “мы же agile, работающее приложение важнее исчерпывающей документации”. Но это не совсем так. И вот почему:

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

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