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

Если спросить аналитика, какие требования существуют, он ответит:

• Бизнес-требования;
• Пользовательские требования;
• Функциональные требования;
• Нефункциональные требования.

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

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

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

• Надежность (Reliability) – в этом разделе расписываем, какой процент времени система должна быть доступна. Для критичных систем, вроде софта для авиадиспетчеров, должно быть 99 % или больше. Хелпдеск для какой-нибудь системы подачи документов для лицензирования может работать 95 %, ничего страшного не случится.

• Сквозной проактивный мониторинг (End-to-end Pro-active Monitoring) – понятно, что об отвалившихся компонентах вас должны уведомлять не пользователи и не собственный продукт-овнер, а система мониторинга. Хорошо бы она умела не просто констатировать факт, но и давать справочную информацию, из-за чего могла случиться авария и какие именно компоненты затронуты.
• Уведомления (Alerting) – расширение предыдущего пункта. Оперативная отправка в почту, мессенджеры инфы о функционировании системы, ключевых параметрах и метриках.
• Восстановление (Restart) – об этом пункте хорошо знают владельцы систем, пострадавшие от вирусов-шифровальщиков. Тут описывается, в какие сроки система должна восстанавливаться автоматизированно и вручную.
• Архивация (Archiving) – связано с предыдущим пунктом. Чтобы было, из чего восстанавливать, система должна своевременно архивироваться, желательно в несколько разных мест. Тут же нужно писать, по какому принципу должны удаляться устаревшие бэкапы, чтобы не засрать хранилище.
• Удаление мусора (Housekeeping) – чистка логов, устаревшего кэша, временных файлов. Например, телеграм умеет удалять старые посты в каналах, эта функция просто создана для реализации этой группы требований.
• Производительность (Performance) – для того, чтобы можно было аргументированно отвечать на претензии заказчика «система тормозит!» Расписываем требования к быстродействию системы, времени реакции интерфейса. Здесь же требования, которые будут использоваться в нагрузочных тестах.
• Сквозное логирование (End-to-end Logging) – чтобы не просить пользователей высылать подробные пути воспроизведения или, прости наука, скринкасты, логируем всё, что только можно и отправляем на служебный имейл. Или только ошибки, вам решать. В общем, тут требования к логированию.
• Работа с ошибками (Error Handling) – достаточно редкий пункт. Тут можно расписать, насколько подробно должны логироваться ошибки. В некоторых ситуациях может сильно облегчить работу разработчиков.
• Требования к коду (Code Design) – тут про стандарты кодирования в компании, требования к комментированию кода и другие программистские штуки.
• Решение инцидентов (Troubleshooting) – способы разрешения типовых инцидентов и требования к их логированию.
• Выполнение настроек (Configuration) – требования к конфигурационным файлам. Тут можно расписать, какие настройки есть смысл зашивать в код, а какие — обязательно выносить в конфиги.
• Пользовательский интерфейс для администрирования и обслуживания (Administration and Maintenance through system frontend) – здесь расписываем, какие функции выносятся в админку для облегчения администрирования системы, а какие останутся в кишках софта.
• Удобство пользователя (Usability) – требования к количеству кликов до ключевых сценариев, количеству цветов, шрифтам, количеству элементов на экране, наличию (или отсутствию) выпадающих списков, ограничений для длинных строк и т.д. Сюда же – требования к языку, дизайну, прототипированию, доступу пользователей с ограниченными возможностями (что, к слову, обязательно по ФЗ для государственных организаций) и т. д. Мой последний заказчик особенно трепетно относился к теням, интервалам и скруглениям.
• Безопасность (Security) – в свете последних событий, произошедших со СДЕКом, эти НФТ особенно важны. Требования к версиям платформ, протоколам, правилам для трафика и другие секурные вопросы.
• Совместимость (Interoperability) – если делаем приложение под мобилки, с каким версиями Андроид и Айос оно должно работать бесперебойно. Если веб — с какими браузерами. Узловые разрешения для адаптива. Если есть важные интеграции — с какими версиями интегрируемого софта всё должно работать.
• ИТ-ландшафт (Landscape) – девопс-хозяйство. Тестовые стенды, препрод, прод, сервера, гиты, докеры, куберы. Тоже всё очень важно.

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