Специфические термины - root causes и edge case. Попробуем разобраться с ними.

Root causes

Root causes (корневые причины) ошибок в требованиях — это глубинные факторы, которые приводят к некорректным, неполным или противоречивым требованиям в проекте. Их анализ помогает не просто исправить конкретную ошибку, а устранить системную проблему, чтобы избежать повторения в будущем.

Примеры root causes для типичных ошибок

1. Неполные требования

Симптом: Пропущены edge-cases (например, не учтено, как система поведёт себя при отмене заказа).

Root causes:

• Нет чек-листа для проверки полноты сценариев.
• Аналитик не провёл интервью с реальными пользователями.

2. Противоречивые требования

Симптом: В разных документах указаны разные форматы данных для одного поля (например, «дата» в RFC 2822 vs. ISO 8601).

Root cause:

• Нет единого глоссария терминов.
• Требования писали несколько аналитиков без согласования.

3. Технически нереализуемые требования

Симптом: Запрос на «мгновенную» синхронизацию данных между серверами, расположенными в разных точках мира/страны.

Root cause:

• Аналитик не проконсультировался с архитектором перед фиксацией.
• Нет процесса pre-review требований с разработчиками.

4. Двусмысленные формулировки

Симптом: «Система должна работать быстро» (без метрик).

Root cause:

• Нет шаблонов для нефункциональных требований (NFR).
• Культура «письменного мышления» не развита.

Как выявлять root causes?

Метод «5 Why» (5 вопросов «Почему?»):

1. Почему требование оказалось ошибочным? — Потому что аналитик не учёл сценарий отмены.

2. Почему не учёл? — Не было чек-листа для проверки.

3. Почему не было чек-листа? — Его не включили в процесс работы.

4. Почему не включили? — Не проводился ретроспективный анализ прошлых ошибок.

5. Почему не проводился? — Нет выделенного времени на улучшение процессов.

Итоговый root cause: Отсутствие ретроспектив и чек-листов.

Как предотвращать?

1. Ввести артефакты:

• Чек-листы для проверки требований (DOR для аналитических спайков).
• Глоссарий терминов.

2. Процессы:

• Обязательный pre-review с архитектором/разработчиками.
• Ретроспективы ошибок раз в месяц.

3. Обучение:

• Воркшопы по написанию NFR.
• Разбор кейсов с реальными проектами.

Примеры root causes аналитики:

Важно: Без устранения root causes команда будет «тушить одни и те же пожары» снова и снова.

Edge case

Edge case (крайний случай, граничный случай) — это редкий, нестандартный или экстремальный сценарий работы системы, который выходит за рамки основного потока (happy path), но может привести к сбоям, если его не учесть в требованиях.

🔍 Простыми словами, можно сказать, что это ситуации, которые:

• Возникают очень редко (например, 1 раз на 10 000 операций).
• Кажутся малозначительными на первый взгляд.
• Но если их пропустить — вызывают критичные ошибки (падение системы, потерю данных, финансовые убытки).

📌 Примеры edge cases

1. Для интернет-магазина

• Покупатель добавляет в корзину 999 999 товаров (перегрузка системы).
• Оплата заказа в момент обнуления остатков на складе.
• Ввод промокода с истёкшим сроком действия.

2. Для банковского приложения

• Перевод 0 рублей между счетами.
• Попытка входа с паролем из 10 000 символов.
• Отмена платежа после его завершения.

3. Для SaaS-платформы

• Пользователь загружает файл размером 1 ТБ.
• Одновременное редактирование документа 100+ пользователями.
• Передача данных через VPN с обрывом соединения.

❗ Почему edge cases важны?

Безопасность: Могут стать лазейкой для хакеров (например, переполнение буфера).

Репутация: Один краш-кейс может испортить впечатление пользователей.

Юридические риски: Нарушение законов (например, двойное списание денег).

🔧 Как выявлять edge cases?

1. Метод «А что, если...»

• «А что, если пользователь нажмёт кнопку «Отправить» 100 раз подряд?»

2. Анализ граничных значений (Boundary Value Analysis):

• Для поля «Возраст» проверять не только 18 и 60 лет, но и 0, -1, 150.

3. Стресс-тесты:

• Имитация пиковых нагрузок (10 000 запросов в секунду).

4. Исторические данные:

• Разбор инцидентов из прошлых проектов.

📝 Как документировать edge cases?

Включать их в требования или в тест-кейсы с пометкой:

 

Сценарий: [Описание основного потока] 

Edge case: 

- Условие: Пользователь вводит отрицательное число. 

- Ожидаемое поведение: Система показывает ошибку «Допустимы только положительные значения». 

 

⚠️ Типичные ошибки

• Игнорирование («Это же почти никогда не случится!»).
• Избыточность (учёт маловероятных сценариев в ущерб скорости разработки).
• Неясные формулировки («Система должна обрабатывать некорректные данные» — без детализации).

Золотое правило: Учитывать edge cases, но приоритезировать их по рискам и частоте.