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

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

Опыт работы с требованиями — это одна из ключевых компетенций QA Engineer. За 10+ лет я разработал эффективный подход к анализу, уточнению и управлению требованиями, который позволяет выявлять недоговорённости на ранних этапах и предотвращать проблемы в production.

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

1. Функциональные требования (Functional Requirements)

Это то, что система должна делать:

• Позитивные сценарии: Как правильно работает функция

  • Пользователь вводит email и пароль → система проверяет → выполняет вход
  • Пользователь нажимает "Купить" → система обрабатывает платёж → отправляет квитанцию

• Граничные случаи: Что происходит на границах

  • Пустой email
  • Пароль ровно 8 символов (минимум)
  • Пароль 256 символов (максимум)
  • Цена товара = 0
  • Количество = 1, 999999

• Обработка ошибок: Что если что-то пошло не так

  • Неправильный пароль → сообщение об ошибке
  • Email не существует → сообщение об ошибке
  • Платёж отклонён → возврат в корзину

2. Нефункциональные требования (Non-Functional Requirements)

Это как система должна работать:

• Performance: Приложение загружается за < 2 секунд
• Security: Пароли хранятся в хэшированном виде (bcrypt)
• Scalability: Система выдерживает 1000 одновременных пользователей
• Usability: Главное меню должно быть понято за 3 секунды
• Reliability: Uptime > 99.9%
• Accessibility: Приложение работает на screen readers для слепых

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

Фаза 1: Сбор требований

Мой подход:

1. Встречи с Product Owner и клиентом

   • Понимаю бизнес-задачу
   • Записываю все детали
   • Задаю уточняющие вопросы
   • Прошу привести примеры

2. Изучение документации

   • Спецификация (SRS)
   • User stories в Jira
   • Прототипы в Figma
   • Старые версии (если есть)

3. Анализ конкурентов

   • Как это реализовано в других приложениях
   • Что работает хорошо
   • Какие edge cases может быть

Пример встречи:

Проект: E-commerce платформа
Феатура: Система скидок

ПО: Нужно добавить возможность применять промокоды
Я: Какие типы промокодов существуют?
ПО: Процентная скидка, фиксированная сумма, бесплатная доставка
Я: Может ли пользователь применить несколько кодов сразу?
ПО: Нет, только один
Я: Что если код истёк?
ПО: Показать ошибку
Я: Какая минимальная сумма для применения?
ПО: Зависит от кода, может быть не указана

Эти вопросы уже выявили 5 edge cases!

Фаза 2: Анализ требований

Что я проверяю:

1. Полнота: Нет ли пропусков?

   • Что означает "успешный вход"?
   • Сколько попыток ввода пароля до блокировки?
   • Как долго учётная запись заблокирована?

2. Непротиворечивость: Нет ли конфликтов?

   • Требование A: "Минимальная сумма 100 рублей"
   • Требование B: "Бесплатная доставка при покупке"
   • Конфликт? Бесплатная доставка = скидка, может быть < 100?

3. Тестируемость: Можно ли это протестировать?

   • "Система должна быть быстрой" → не тестируемо
   • "Система загружается за < 2 сек на 4G" → тестируемо!
   • "Нужен красивый интерфейс" → субъективно
   • "На мобильных экранах < 480px интерфейс не должен поломаться" → тестируемо!

4. Реалистичность: Можно ли это реализовать?

   • "API должна обработать 1 млн запросов в секунду" — нереалистично
   • Нужно согласовать с разработчиком

Документирование вопросов:

Требование: "Пользователь может скачать свой профиль в PDF"

Мои вопросы:
- Какие данные должны быть в PDF? (ФИО, аватар, история заказов?)
- Какой формат даты? (ISO, локализованный?)
- Если заказов > 1000, он влезет в PDF?
- Какой размер максимально? (< 5MB?)
- Может ли пользователь скачать чужой профиль?
- Если профиль удалён, что показывать?

Фаза 3: Уточнение требований

Техники уточнения:

1. 5 Why (Пять почему)

   Требование: "Сортировать товары по цене"
   Почему 1: Пользователю нужно найти дешёвые товары
   Почему 2: Чтобы не переплачивать
   Почему 3: У него ограниченный бюджет
   
   Вывод: Может быть, нужна фильтрация по диапазону цены, а не просто сортировка!
   

2. User Stories в формате Given-When-Then

   Given: Пользователь залогинен и в корзине есть товары
   When: Пользователь нажимает "Оформить заказ"
   Then: Система требует выбрать адрес доставки
   And: Система показывает стоимость доставки
   And: Пользователь может вернуться в корзину
   

3. Acceptance Criteria (Критерии приёма)

   Требование: Реализовать фильтр по цене
   
   AC1: Диапазон цены от 0 до максимальной цены товаров в каталоге
   AC2: При изменении фильтра список товаров обновляется за < 1 сек
   AC3: Фильтр сохраняется при переходе на другую страницу
   AC4: Кнопка "Сбросить фильтр" очищает все выбранные значения
   AC5: Фильтр работает на мобильных экранах (< 480px)
   

Практические примеры из моего опыта

Пример 1: Платёжная система

Исходное требование:

"Реализовать платёжную систему Stripe"

Мои уточнения:

• Какие валюты поддерживаем? (USD, EUR, RUB?)
• Что если платёж отклонён? (Retry? Сообщение? Как долго ждём?)
• Что если пользователь закроет браузер во время платежа?
• Как обрабатываем chargebacks (споры о платежах)?
• Нужна ли двухфакторная аутентификация для платежей > 1000?
• Как долго храним историю платежей? (Месяцы, годы?)
• Каким образом нотифицируем пользователей? (Email, SMS, push?)

Результат: Выявил 15 edge cases, которые могли привести к потере денег пользователей.

Пример 2: Система уведомлений

Исходное требование:

"Отправлять пользователям уведомления о новых заказах"

Мои уточнения:

• Какой канал? (Email, SMS, Push, в-приложение?)
• Когда отправлять? (Сразу, через 5 минут после создания?)
• Что если пользователь выключил уведомления?
• Что если email неправильный?
• На каком языке отправлять? (Язык пользователя, язык системы?)
• Если пользователь заказал несколько товаров, один email или несколько?
• Что если сервис отправки недоступен? (Queue, retry?)

Результат: Спроектировали robust систему, которая не теряет уведомления.

Пример 3: Authentication (Вход в систему)

Исходное требование:

"Реализовать вход через email и пароль"

Мои вопросы привели к уточнениям:

• Минимальная длина пароля? (8 символов минимум?)
• Обязательно ли заглавные буквы, цифры, спецсимволы?
• Может ли пароль содержать пробелы?
• Сколько попыток входа до блокировки? (3, 5?)
• На как долго блокируется? (15 минут, 1 час?)
• Как разблокировать? (Email link, support?)
• Нужно ли требовать смену пароля при первом входе?
• Как долго сессия остаётся активной? (30 минут? 24 часа?)
• Что если пользователь заходит с нового устройства?
• Нужно ли двухфакторная аутентификация? (Всем или опционально?)

Результат: Документировал 25 test cases только для функции входа!

Работа с документацией

Формат SRS (Software Requirement Specification)

ID: REQ-001
Название: User Login
Описание: Система должна позволять пользователям входить по email и паролю
Тип: Функциональное
Сeverity: Critical (без входа система неиспользуема)

Functional Details:
- Email: user@example.com (valid email format)
- Password: 8-256 символов
- Rate limit: 5 попыток в 15 минут
- Session timeout: 24 часа неактивности

Acceptance Criteria:
AC1: Правильный email + пароль = успешный вход
AC2: Неправильный пароль = ошибка (не указываем, какой именно неправ)
AC3: После 5 ошибок = блокировка на 15 минут
AC4: Email не существует = ошибка (generic, как при неправ пароле)

Test Cases:
TC-001: Valid email and password -> success
TC-002: Valid email, wrong password -> error
TC-003: Invalid email format -> error
...(20 более тестов)

Инструменты для работы с требованиями

Что я использовал:

• Jira/Azure DevOps — управление требованиями и test cases
• Confluence — документирование требований
• Figma — анализ дизайна
• Spreadsheets (Excel) — составление матрицы требований vs тестов
• Mind Maps — визуализация сложных требований

Типичные проблемы с требованиями

Проблема 1: Неполные требования

Пример: "Реализовать поиск по товарам" Вопросы: По какому полю? (название, описание, оба?). Case-sensitive? Exact match или fuzzy search? Сколько результатов показывать?

Проблема 2: Конфликтующие требования

Пример:

• Требование A: "Все товары должны быть видны сразу"
• Требование B: "Страница должна загружаться < 2 сек"
• Конфликт при 100k товаров!

Проблема 3: Неизмеримые требования

Плохо: "Интерфейс должен быть интуитивный" Хорошо: "90% пользователей должны найти кнопку "Купить" за < 3 сек"

Проблема 4: Технически невозможные требования

Пример: "Система должна обработать 1 млн запросов в секунду на $100 сервере" Решение: Согласовать с разработчиком и бизнесом реалистичные параметры

Мой checklist при анализе требований

□ Требование описано на русском
□ Не содержит двусмысленностей
□ Тестируемо (есть чёткие критерии приёма)
□ Полное (ничего не пропущено)
□ Непротиворечиво (не конфликтует с другими)
□ Реалистично (разработчик согласен, что это возможно)
□ Нет технических деталей в AC (не писать "использовать REST API")
□ Приоритет определён (Critical, High, Medium, Low)
□ Зависимости указаны (требует ли других требований?)
□ Есть примеры и граничные случаи

Результаты

Благодаря тщательной работе с требованиями:

• Уменьшили количество багов на 40% (выявили их на этапе требований)
• Сократили время тестирования на 30% (понимали что тестировать)
• Улучшили коммуникацию с разработчиками (ясные требования = яснее реализация)
• Повысили скорость разработки (не переделывали функции)

Заключение

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