Основные вопросы для сбора требований к проекту.

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

Прежде чем приступать к проектированию, важно детально собрать и уточнить требования, которые предъявляются к будущему продукту (веб-приложению, сервису и т.д.). Прочитав техническое задание и ознакомившись с бизнес-кейсами, у разработчика обычно складывается определённое представление о том, как должна работать система. Но иногда, это представление отличается от того, что хочет заказчик на самом деле и за что готов платить. Я сделал шпаргалку по основным вопросам, которые помогут уточнить требования. Важно учитывать, что некоторые требования могут быть взаимоисключающими (например, как в случае с CAP-теоремой) или значительно увеличивать стоимость проекта. Эти моменты лучше прояснить на старте.

1. Функциональные требования:
1. Какую задачу будет решать система, какие у неё будут функции.
2. Бизнес требования которые решаются этой системой. Какой ожидается результат.
3. Взаимодействие с пользователем. Как пользователь будет использовать приложение. Например, через UI, API или командный интерфейс.
4. Требования к интерфейсу. Юзабилити, доступность для разных людей, документация, поддержка, обучение.
2. Производительность и нагрузка. Сколько ожидается пользователей и запросов от них (каких). Это нужно, чтобы рассчитать предполагаемый RPS.
3. Объём данных (Capacity). Сколько данных будет храниться и сколько данных будут генерировать пользователи. От этого зависит тип и размер БД.
4. Задержка (Latency). Какая допустима задержка в ответах. Вполне очевидно, что например для конвертера больших файлов - задержка будет не так важна, как например в мессенджере, где данные нужно получать в реальном времени.
5. Гео-распределённость. Понадобится ли шардировать данные по регионам, а также задействовать кеширующие сервера (CDN).
6. Надёжность (Reliability) описывает, как часто система выходит из строя, тогда как доступность (Availability) — это процент времени, когда система доступна для использования.
7. Отказоусточивость (Fault tolerance). Как система должна реагировать на сбои в сети или аппаратном обеспечении. Насколько важна целостность данных и как быстро они должны восстанавливаться после сбоя.
8. Масштабируемость (Scalability). Должна ли система подстраиваться при увеличении нагрузки. Будет ли она постоянно испытывать высокие нагрузки или она будет чаще простаивать и нагружаться только раз в сутки. Какую максимальную нагрузку система должна выдерживать.
9. Совместимость (Compatibility). Будет ли система интегрироваться с другими системами через API? Поддерживает ли она обратную совместимость с предыдущими версиями.
10. Security (Безопасность). Требуется ли аутентификация и авторизация. Какие права доступа у разных типов пользователей. Нужно ли шифровать данные при передаче (TLS) и хранении (AES)? Какие данные.
11. Юридические и географические ограничения. В каких странах будет использоваться система и какие правовые нормы важны (например, GDPR, HIPAA). Нужно ли соблюдать промышленные стандарты.
12. Срок жизни и поддерживаемость (SLA). Какой жизненный цикл у приложения, сколько времени планируется его поддержка после релиза. А также, есть ли специфичные требования к фреймворкам, языкам, архитектуре. Например, предпочтение может быть отдано популярным технологиям для упрощения найма разработчиков. Либо нужен сайт для разового мероприятия, и дальнейшая поддержка и развитие не потребуется.

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