Что такое требования?

Требования в контексте разработки проекта

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

Что такое требования простыми словами

Представьте, что вы заказываете разработку сайта для кофейни. Требование — это не просто сделайте сайт, а конкретные описания:

• На главной странице должна быть карта кофейни с меню
• Клиенты должны иметь возможность забронировать столик на определённое время
• При клике на напиток должна открываться карточка с описанием и ценой

Без чётких требований разработчик может понять задачу неправильно, потратить время впустую, и результат не совпадёт с ожиданиями. С чёткими требованиями все понимают, что нужно делать.

Типы требований

Функциональные требования Описывают, что система должна делать. Это функции, которые видит или использует пользователь.

Примеры:

• Система должна позволять пользователю создать аккаунт с помощью email и пароля
• При оплате заказа система должна отправить квитанцию на email клиента
• Пользователь должен иметь возможность фильтровать товары по цене и категориям

Нефункциональные требования (NFR) Описывают как система должна работать: производительность, надёжность, безопасность, удобство.

Примеры:

• Система должна загружаться не дольше 3 секунд
• Система должна быть доступна 99.9% времени (SLA)
• Все пароли должны храниться в зашифрованном виде
• Интерфейс должен быть доступен для людей с ограниченным зрением (WCAG 2.1)
• Система должна обрабатывать 10,000 запросов в секунду

Характеристики хороших требований (SMART)

Specific (Конкретное) Требование должно быть ясным, без двусмысленности. Сделать загрузку быстрой — плохо. Загрузка должна занимать не более 2 секунд — хорошо.

Measurable (Измеримое) Должна быть возможность проверить выполнение. Как вы поймёте, что требование выполнено?

Achievable (Достижимое) Требование должно быть реалистичным в рамках проекта, бюджета и времени.

Relevant (Релевантное) Требование должно быть связано с целями бизнеса и потребностями пользователей.

Time-bound (С временными рамками) Когда требование должно быть реализовано? Сейчас, в следующем спринте или в версии 2.0?

Как пишутся требования

User Story (самый популярный формат в Agile)

As a role I want function So that benefit

Пример: Как клиент я хочу добавлять товары в корзину прямо на странице товара, чтобы быстро собрать свой список покупок.

Acceptance Criteria (критерии приёма) Чёткие условия, при которых требование считается выполненным:

• Я на странице товара
• Я кликаю кнопку Добавить в корзину
• Товар добавляется в корзину
• Счётчик корзины увеличивается на 1
• Я остаюсь на странице товара

Классификация требований по уровню детализации

Бизнес-требования Высокоуровневые, описывают зачем нужен проект. Часто формулирует клиент или Product Owner. Пример: Нам нужно снизить время обработки заказов с 2 часов до 15 минут, чтобы повысить удовлетворённость клиентов на 30%

Функциональные требования Детализируют, что конкретно делать. Пример: Система должна автоматически распределять входящие заказы между свободными операторами на основе их специализации

Технические требования Описывают, как технически это реализовать. Обычно это прерогатива архитекторов и старших разработчиков. Пример: Использовать очередь сообщений RabbitMQ для асинхронной обработки заказов

Процесс работы с требованиями

1. Сбор — интервью с пользователями, анализ рынка, конкурентов
2. Анализ — разделение на функциональные и нефункциональные, выявление зависимостей
3. Документирование — запись в понятном формате (user stories, спецификации)
4. Валидация — согласование с заинтересованными сторонами
5. Приоритизация — определение, что реализовать в первую очередь
6. Управление изменениями — контроль запросов на изменение требований

Ошибки при работе с требованиями

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

Вывод: Требования — это контракт между бизнесом и разработкой. Чем чётче и полнее требования, тем выше вероятность того, что проект будет успешным.