A pedibus usque ad caput
Если спросить аналитика, какие требования существуют, он ответит:
- Бизнес-требования;
- Пользовательские требования;
- Функциональные требования;
- Нефункциональные требования.
Если с первыми тремя всё более-менее понятно, с нефункциональными требования вечно выходят какие-то факапы. То про них, вообще, забудут, то упустят что-то важное. Давайте разберёмся, что в них входит, чтобы на реальном проекте ничего из этого не продолбать.
- Надежность (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) – девопс-хозяйство. Тестовые стенды, препрод, прод, сервера, гиты, докеры, куберы. Тоже всё очень важно.
В целом, это исчерпывающий чек-лист по нефункциональным требованиям. Их ни в коем случае нельзя упускать при подготовке требований к ПО, они крайне важны на всех этапах разработки.