Уровни и виды требований по Вигерсу на примере пиццы

Бизнес-требования

На самом верхнем уровне находятся бизнес-требования. Они отвечают на вопросы:

• Зачем нужно это решение?
• Какую проблему бизнеса мы хотим решить?
• Какой результат компания ожидает получить?

Здесь формируется документ о концепции и границах, где описываются цели проекта, границы будущего решения и ключевые показатели успеха. При этом в бизнес-требования могут быть «вшиты» бизнес-правила — внутренние или внешние регламенты, законы, стандарты, которые влияют на то, как нужно разрабатывать и использовать систему. Бизнес-правила оказывают влияние на все виды требований.

Пользовательские требования

На следующем уровне находятся пользовательские требования — что именно пользователи ожидают от системы в повседневной работе. Можно сказать, это «мост» между бизнес-уровнем и более конкретными системными деталями.

Здесь описывается, как пользователь будет взаимодействовать с системой, какие задачи он будет решать. Эти требования обычно оформляются в виде:

• User Stories (короткие истории о том, кто пользователь и чего он хочет добиться).

По Вигерсу эти требования объединяют в единый Документ пользовательских требований, чтобы зафиксировать всё, что действительно важно для конечных пользователей.

Функциональные требования

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

• Сценарии использования (Use Cases): какую конкретную задачу решает пользователь и как система ему в этом помогает.
• Приложения и модули: какие основные компоненты будут в системе (например, модуль «Заказы», «Расчёт стоимости», «Управление пользователями»).
• Логику: как обрабатываются данные и какие результаты возвращаются.

Нефункциональные требования

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

1. Внешние интерфейсы

   Описывают, как система взаимодействует с внешними сервисами, модулями или устройствами. Например, каким протоколом обмениваться данными с платёжным шлюзом или как интегрироваться с системой логистики.

2. Атрибуты качества

   • Производительность (через сколько секунд должна открываться страница с меню или обрабатываться заказ).
   • Безопасность (какие механизмы авторизации, шифрования данных и защиты от атак используются).
   • Удобство использования (принципы UX/UI, чтобы пользователям было легко и понятно).
   • и другие атрибуты

3. Ограничения

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

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

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

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

• Требования к аппаратному обеспечению: минимальная конфигурация сервера или пользовательского устройства (оперативная память, мощность процессора, объём диска).
• Соответствие операционной системе: система должна запускаться под Windows, Linux, iOS, Android или иметь кроссплатформенную поддержку.
• Совместимость с версией браузера: приложение корректно работает в последних версиях Chrome, Safari, Firefox.
• Видеоадаптер: если это продукт с 3D-графикой или высоким уровнем визуализации, указываются требования к видеокарте.

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

Итог

По Вигерсу все требования делятся на три уровня:

1. Бизнес-требования

   Отвечают на вопрос «зачем мы это делаем?» и определяют цели и границы будущего решения.

2. Пользовательские требования

   Показывают, «что нужно пользователям» для выполнения своих задач.

3. Системные требования

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

Такая структура помогает двигаться от самых глобальных целей (бизнес-требований) к конкретному описанию решения на уровне системы и её компонентов. Если правильно учесть взаимосвязи между этими тремя уровнями, то удастся создать понятное и целостное описание проекта, где каждая деталь решения обоснована с точки зрения целей бизнеса и реальных нужд пользователей.

Нет ничего лучше примеров

Чтобы наглядно показать взаимосвязь трёх уровней требований и всех дополнительных факторов, рассмотрим сквозной пример с сервисом для заказа пиццы:

1. Бизнес-требование

   • Увеличить онлайн-продажи пиццерии на 30% за счёт запуска удобного веб-приложения.

2. Пользовательские требования

   • Пользователь может выбрать пиццу (с учётом ингредиентов и размеров) и оформить заказ.
   • Пользователь может оплатить заказ онлайн.
   • Пользователь может просмотреть статус доставки.

3. Функциональные требования, которые детализируют каждое пользовательское требование:

   • Для «Пользователь может выбрать пиццу (с учётом ингредиентов и размеров) и оформить заказ»:

     1. Система предоставляет каталог пицц.
     2. Система позволяет добавлять или убирать ингредиенты.
     3. Система позволяет выбирать количество пицц.
     4. Система позволяет выбирать размер пиццы.
     5. Система рассчитывает итоговую стоимость заказа с учётом выбранных ингредиентов, скидок и промокодов.
     6. Система формирует заказ и передаёт информацию на сервер для дальнейшей обработки.

   • Для «Пользователь может оплатить заказ онлайн»:

     1. Система интегрируется с платёжным шлюзом, обеспечивая приём онлайн-платежей.
     2. Система проверяет статус оплаты в реальном времени и уведомляет о результатах.
     3. Система формирует чек (электронный или PDF) и отправляет его пользователю.

   • Для «Пользователь может просмотреть статус доставки»:

     1. Система интегрируется с сервисом отслеживания курьеров и получает информацию о текущем положении заказа.
     2. Система отображает текущее состояние (принят, в работе, на доставке, доставлен) в личном кабинете пользователя.
     3. Система рассылает уведомления пользователю (push или e-mail) при изменении статуса заказа.

Бизнес-правила могут накладывать дополнительные условия. Например, скидка по промокоду не превышает 50% от стоимости заказа, а доставка для VIP-клиентов всегда бесплатна. Такие правила влияют на формулировку бизнес-требований (увеличить средний чек за счёт скидок), уточняют пользовательские требования (учёт разных типов клиентов и скидок) и отражаются в функциональных требованиях (необходимость логики по валидации промокодов и определения статуса клиента).

Нефункциональные требования задают качество и ограничения. Например:

• Система должна обрабатывать до 100 заказов одновременно без существенной потери производительности.
• Ответ сервера на формирование или обновление заказа не должен превышать 2 секунд.
• Приложение должно соответствовать политике работы с персональными данными.

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

Системные требования описывают окружение и оборудование:

• Приложение должно поддерживать работу в актуальных версиях браузеров (Chrome, Firefox, Safari).
• Необходимо учитывать минимальные требования к видеокарте, если появится функциональность визуализации процесса готовки пиццы в реальном времени.

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