Сбор требований: функциональные и нефункциональные

Первый и самый недооценённый шаг: превратить «спроектируйте X» в список конкретных требований.

Функциональные требования — что система делает (функции). Нефункциональные — какими свойствами обладает: масштаб, латентность, доступность, согласованность.

Два типа требований

Любая задача делится на две части. Функциональные требования отвечают на вопрос «что умеет система»: для сократителя ссылок — создать короткую ссылку и перейти по ней. Нефункциональные — «как хорошо она это делает»: сколько запросов в секунду, какая задержка допустима, насколько важна доступность против согласованности.

Как сужать скоуп

На «спроектируйте Twitter» нельзя ответить за 45 минут целиком. Поэтому сразу спросите: какие функции в скоупе? Обычно интервьюер согласится сузить до 2–3 ключевых («постинг и лента, без поиска и рекламы»). Это нормально и ожидаемо — фиксация скоупа экономит время и показывает зрелость.

Как работает под капотом

Нефункциональные требования напрямую определяют архитектуру. «Доступность важнее согласованности» означает выбор AP-системы по CAP, реплики, кэш. «Латентность < 100 мс» означает CDN и кэш у границы. «Сильная согласованность для баланса кошелька» означает транзакции и, возможно, отказ от агрессивного кэширования. Каждое нефункциональное требование позже превращается в конкретный компонент схемы.

Вопросы, которые стоит задать

• Кто пользователи и сколько их (DAU)?
• Соотношение чтений к записям?
• Какие функции в скоупе, какие можно отложить?
• Что важнее: согласованность или доступность?
• Какая допустимая задержка?

Частые ошибки

• Сразу начать проектировать, не задав ни одного вопроса.
• Смешать функциональные и нефункциональные требования в кашу.
• Не зафиксировать соотношение чтений к записям — а оно меняет всю архитектуру.

Итог

• Делите требования на функциональные (что) и нефункциональные (как хорошо).
• Сужайте скоуп до 2–3 ключевых функций — это ожидаемо.
• Нефункциональные требования напрямую превращаются в компоненты схемы.