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