Какие знаешь форматы требований?

Форматы требований в разработке ПО

В своей практике я сталкивался с множеством форматов требований, которые можно условно разделить на текстовые, структурированные, визуальные и специализированные. Каждый формат служит своей цели и эффективен в определённом контексте.

1. Текстовые (естественно-языковые) требования

Это самый распространённый и исторически первый формат. Требования описываются на естественном языке (русском, английском) в документах.

• Плюсы: Доступны всем участникам (заказчики, менеджеры, разработчики), не требуют специальных инструментов.
• Минусы: Высокий риск неоднозначности, дублирования, сложность отслеживания изменений.
• Примеры документов: Vision & Scope, Пользовательские истории (User Stories), Требования к продукту (Product Requirements Document — PRD), Бизнес-требования (Business Requirements Document — BRD).

Пример пользовательской истории:

Как <роль пользователя>,
Я хочу <возможность>,
Чтобы <получить выгоду/решить проблему>.

Критерии приемки (Acceptance Criteria):
1. Дан пользователь с ролью "Администратор".
2. При переходе в раздел "Пользователи" отображается таблица со списком.
3. Над таблицей есть кнопка "Добавить".
4. При нажатии на кнопку открывается модальное окно с формой.

2. Структурированные и формальные форматы

Эти форматы призваны преодолеть недостатки естественного языка за счёт чёткой структуры.

• Требования в виде "должен" (Shall-Statements):

    Чёткие, тестируемые утверждения. Часто используются в технических заданиях (ТЗ) и системных требованиях.

```plaintext
Система должна предоставлять возможность аутентификации пользователя по логину и паролю.
Система должна блокировать учётную запись после 5 неудачных попыток входа.
```

• Таблицы решений (Decision Tables) и матрицы трассируемости:

    Идеальны для описания сложной бизнес-логики с множеством условий. Позволяют наглядно увидеть все возможные комбинации.

    **Пример таблицы решений для скидки:**
    | Сумма покупки > 1000 | Постоянный клиент | Итоговая скидка |
    | :--- | :--- | :--- |
    | Да | Да | 15% |
    | Да | Нет | 10% |
    | Нет | Да | 5% |
    | Нет | Нет | 0% |

3. Визуальные модели

Диаграммы и схемы, которые позволяют быстро понять структуру системы, потоки данных и взаимодействия.

• Моделирование бизнес-процессов: BPMN (Business Process Model and Notation) диаграммы для описания сквозных процессов.
• Диаграммы потоков данных (DFD).
• Мокапы (Mockups) и прототипы интерфейсов (в Figma, Adobe XD). Для QA это бесценный источник требований к UI/UX.
• Диаграммы состояний (State Transition Diagrams). Критически важны для тестирования сложных объектов с разными статусами (например, заказ: "Новый", "Оплачен", "Отправлен", "Доставлен", "Отменён").

4. Специализированные языки и форматы

• User Story Mapping: Визуальная техника размещения пользовательских историй на временной шкале (карте), что помогает понять целостность продукта.
• Примеры и сценарии (Example Mapping, BDD): Использование конкретных примеров для уточнения требований. Gherkin — это DSL (предметно-ориентированный язык), который формализует сценарии в стиле "Given-When-Then".

  Feature: Калькулятор
    Scenario: Сложение двух чисел
      Given я открыл калькулятор
      When я ввожу число "5"
      And я нажимаю кнопку "+"
      And я ввожу число "3"
      And я нажимаю кнопку "="
      Then на экране отображается результат "8"
  

    Такой формат является **исполняемой спецификацией** и может напрямую использоваться для автоматизации тестов (Cucumber, SpecFlow, Behave).

• Модель предметной области (Domain Model): Описание ключевых сущностей, их атрибутов и взаимосвязей. Часто используется в Domain-Driven Design (DDD).

5. Современные и гибкие подходы

В Agile-командах требования часто живут в:

• Backlog в системах управления проектами (Jira, YouTrack, Azure DevOps).
• Формате Epic > User Story > Task/Sub-task.
• Вживую, в виде обсуждений на планировании (Planning), уточнении (Refinement) и в процессе разработки. Здесь ключевую роль играет непрерывная коммуникация.

Почему QA Engineer должен разбираться во всех форматах?

1. Понимание полной картины: Текстовые требования дают контекст, таблицы — логику, диаграммы — связи, прототипы — UI.
2. Выявление противоречий и "белых пятен": Часто нестыковки становятся очевидны только при сопоставлении требований из разных источников. Например, описание бизнес-правила в тексте может не соответствовать логике, отображённой на диаграмме BPMN.
3. Эффективное тест-анализ и дизайн тестов: На основе структурированных требований (таблиц решений, диаграмм состояний) гораздо проще применять такие техники, как анализ классов эквивалентности, граничных значений и таблицы решений для создания исчерпывающих тест-кейсов.
4. Участие в уточнении требований: QA Engineer, понимающий форматы, может предложить продукту или аналитику переформулировать неоднозначное текстовое требование в виде таблицы или набора сценариев Gherkin, что сразу повысит качество спецификации.

Идеального единого формата не существует. В реальном проекте требования обычно представлены комбинацией нескольких форматов. Задача QA — уметь "читать" каждый из них, синтезировать информацию и на её основе выстраивать стратегию тестирования, гарантирующую, что реализованная система соответствует всем заявленным ожиданиям, явным и неявным.