Перейти к основному содержимому

Бизнес-логика

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Руководителю Аналитику Техническому писателю
Теория данных (раздел 3)

Данные в бизнес-контексте — Данные и информация, роль БД в организации. Карта подраздела — о разделе.

Что такое бизнес-логика?​

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

Бизнес-логика устроена как иерархия правил разного уровня:

  • стратегические правила: политика ценообразования, условия сотрудничества
  • операционные правила: последовательность шагов в процессе, критерии принятия решений
  • тактические правила: обработка исключительных ситуаций, эскалация проблем
  • валидационные правила: проверка корректности данных и соблюдения ограничений

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

Система электронной коммерции содержит бизнес-логику расчёта итоговой стоимости заказа. Правила логики определяют последовательность применения скидок — сначала учитываются промокоды, затем накопительные скидки за объём покупок, после этого рассчитывается стоимость доставки в зависимости от региона и веса заказа, и в конце добавляется налог. Для постоянных клиентов применяется дополнительная скидка лояльности. Если общая сумма заказа превышает порог бесплатной доставки, стоимость доставки обнуляется. Система проверяет наличие товаров на складе и блокирует оформление заказа при отсутствии критически важных позиций. Каждое правило реализовано как отдельный компонент, что позволяет изменять политику скидок без переписывания основной логики расчёта.

Код ITЗагрузка примера кода…

def calculate_order_total(order, customer):
    base_amount = sum(item.price * item.quantity for item in order.items)
    
    promo_discount = apply_promo_code_discount(base_amount, order.promo_code)
    volume_discount = apply_volume_discount(base_amount - promo_discount, order.total_items)
    loyalty_discount = apply_loyalty_discount(base_amount - promo_discount - volume_discount, customer.loyalty_level)
    
    subtotal = base_amount - promo_discount - volume_discount - loyalty_discount
    shipping_cost = calculate_shipping_cost(order.delivery_address, order.total_weight, subtotal)
    tax = calculate_tax(subtotal + shipping_cost, order.delivery_address.region)
    
    return subtotal + shipping_cost + tax

Код ITЗагрузка примера кода…

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

Бизнес функционирует как целостная система, где индустрия определяет контекст, рынок задаёт условия конкуренции, а бизнес-модель описывает способ создания ценности. Бренд формирует восприятие продукта, маркетинг привлекает клиентов, продажи конвертируют интерес в сделки. Логистика обеспечивает доставку, цена отражает баланс затрат и ценности, а бизнес-логика воплощает правила работы в цифровых системах. Корпорация предоставляет организационную форму, реализация превращает планы в результаты, а бюрократия и монополизация влияют на эффективность и конкуренцию в системе.

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

Менеджер​

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

Менеджер устроен как центр управления потоками:

  • сбор и анализ требований от заинтересованных сторон
  • приоритизация задач и распределение ресурсов
  • координация работы специалистов разных профилей
  • мониторинг прогресса и управление рисками
  • коммуникация с заказчиками и стейкхолдерами
  • принятие оперативных решений в рамках полномочий

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

Требование​

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

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

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

Требование устроено как структурированное утверждение, содержащее:

  • субъект: кто или что предъявляет требование
  • действие: что система должна делать или как должна вести себя
  • объект: над чем или с чем выполняется действие
  • условия: при каких обстоятельствах требование применяется
  • критерии проверки: как будет подтверждено выполнение

Примеры требований разного уровня детализации:

  • бизнес-требование: "Система должна сократить время обработки заказа до 5 минут"
  • пользовательское требование: "Покупатель может отменить заказ до момента передачи курьеру"
  • функциональное требование: "При нажатии кнопки "Отмена" система проверяет статус заказа и при значении "Собран" устанавливает статус "Отменён""

Требования становятся основой для проектирования, разработки и тестирования, обеспечивая единое понимание целей проекта всеми участниками.

Потребность​

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

Потребность устроена как триада:

  • источник — кто испытывает потребность (пользователь, бизнес, система)
  • суть — в чём проявляется нехватка (время, ресурсы, функциональность)
  • мотивация — почему важно устранить эту нехватку (выгода, снижение рисков, соответствие нормам)

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

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

Конкретика​

Конкретика — это степень детализации и определённости в описании, исключающая двусмысленность и допускающая однозначную интерпретацию. Конкретика превращает абстрактные идеи в измеримые и проверяемые утверждения.

Конкретика устроена через применение измеримых параметров:

  • количественные показатели: "время загрузки не более 3 секунд" вместо "быстрая загрузка"
  • чёткие границы: "поддержка браузеров не старше двух лет" вместо "поддержка современных браузеров"
  • конкретные сценарии — "пользователь вводит номер телефона, система отправляет СМС с кодом, пользователь вводит код" вместо "удобная авторизация"
  • определённые роли: "администратор магазина" вместо "ответственное лицо"

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

Основы теории требований​

Дизайн​

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

Требования могут изложить просто в сообщении в мессенджере, вроде "хочу сайт, который будет генерировать мне случайные фильмы для просмотра на вечер". А могут быть в виде огромного технического задания с подробным описанием всех полей, структур, с примерами дизайна сайта, а также перечнем сопутствующих вопросов, которые нужно будет решить.

Уровни требований​

Выделяют три уровня требований:

  • бизнес-требования;
  • требования пользователей;
  • требования к решению.

Бизнес-требования же отличаются тем, что они формулируют цели, задачи, результаты разработки, без углубления в технические моменты. Как раз AS IS, TO BE. Туда можно включать бизнес-цели, концепцию решения, какие-то рамки и границы, критерии готовности, описания пользователей. Словом, общий контекст.

Бизнес-правила​

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

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

Бизнес-правило является условием поведения системы или её конкретных элементов.

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

Требования пользователей, или пользовательские требования – описание с точки зрения выполнения сценария, через два варианта:

  • User Story – пользовательская история, которая приводит пример, играя роль соответствующего пользователя, при этом короткая, простая и акцентируется на потребностях пользователя, без деталей - "Как [роль], я хочу [действие], чтобы [цель/выгода]. ";
  • Use Case – более детальный сценарий, указывающий уже "как" должна вести себя система, указав роль, цель, шаги и альтернативные потоки, к примеру, "покупатель жмёт кнопку, система выводит окно с подтверждением, если да – выполняет, если нет – возвращается на шаг назад".

Требования к решению​

Требования к решению, или спецификация включает в себя:

  • функциональные требования (описание поведения системы по данной функции – самые детальные особенности именно тут);
  • нефункциональные требования:
    • требования к данным – объектная модель, связи, атрибуты, свойства;
    • требования к интерфейсу (пользовательский интерфейс, внешний вид);
    • ограничения (какие-то особые условия, допустим набор технологий);
    • системные требования (требования к программному обеспечению и оборудованию, на котором будет функционировать разработанное решение);
    • показатели качества (удобство использования, производительность, доступность, безопасность).

Все требования, как правило, документируют по завершению анализа, потом проверяют на соответствие бизнес-цели и верифицируют.

Функционал​

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

Функционал устроен как иерархия возможностей:

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

Пример функционала интернет-магазина:

  • просмотр каталога товаров
  • добавление товаров в корзину
  • оформление заказа с указанием адреса доставки
  • оплата банковской картой
  • отслеживание статуса заказа
  • управление личным кабинетом
  • администрирование товаров и заказов

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

Приёмка​

Приёмка — это процесс проверки и подтверждения соответствия разработанного решения утверждённым требованиям с последующим принятием решения о вводе в эксплуатацию. Приёмка завершает цикл разработки и передаёт ответственность за систему от команды разработки к эксплуатирующей стороне.

Приёмка устроена как последовательность этапов:

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

Критерии приёмки формулируются заранее и описывают конкретные условия, при которых функция считается принятой. Например — "После оформления заказа пользователь получает электронное письмо с подтверждением в течение 1 минуты, письмо содержит номер заказа, состав товаров и итоговую сумму".

Успешная приёмка подтверждает, что система решает поставленные бизнес-задачи и готова к использованию конечными пользователями.

Описание​

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

Описание устроено через комбинацию элементов:

  • контекст: обстановка или условия, в которых существует описываемый объект
  • структура: составные части и их взаимосвязи
  • поведение: как объект функционирует или взаимодействует с окружением
  • атрибуты: измеримые характеристики и свойства
  • ограничения: рамки и условия применения

В разработке программного обеспечения описания принимают разные формы:

  • описание требований: что система должна делать
  • описание архитектуры: как устроена система на высоком уровне
  • описание интерфейса: как пользователь взаимодействует с системой
  • описание данных: структура и взаимосвязи информации в системе

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

Критерии​

Критерии — это заранее определённые показатели или условия, по которым оценивается соответствие объекта ожидаемым требованиям или стандартам качества. Критерии превращают субъективные оценки в объективные измерения.

Критерии устроены как набор проверяемых утверждений:

  • измеримость: возможность количественной или качественной оценки
  • однозначность: отсутствие двусмысленности в трактовке
  • проверяемость: возможность подтвердить выполнение фактами
  • релевантность: связь с целями проекта или бизнеса

Примеры критериев разных типов:

  • критерии приёмки: "Форма регистрации сохраняет данные при потере интернет-соединения и отправляет их после восстановления связи"
  • критерии качества: "Время отклика интерфейса не превышает 200 миллисекунд при нагрузке до 1000 одновременных пользователей"
  • критерии готовности: "Все критические баги исправлены, покрытие автотестами основных сценариев составляет не менее 70%"

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

Верификация​

Верификация — это процесс проверки соответствия продукта разработки установленным требованиям и спецификациям на каждом этапе жизненного цикла. Верификация отвечает на вопрос "Правильно ли мы делаем продукт?", подтверждая, что текущая реализация соответствует задуманному замыслу.

Верификация устроена как многоуровневая система проверок:

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

Верификация отличается от валидации: верификация подтверждает соответствие спецификации ("делаем ли мы продукт правильно"), тогда как валидация подтверждает соответствие потребностям пользователя ("делаем ли мы правильный продукт").

Примеры верификационных действий:

  • анализ кода статическими анализаторами на соответствие стандартам
  • проверка покрытия кода юнит-тестами
  • сравнение поведения системы с описанными в требованиях сценариями
  • аудит документации на полноту и непротиворечивость

Регулярная верификация на ранних этапах позволяет выявлять отклонения от требований до того, как они превратятся в дорогостоящие ошибки на этапе приёмки или эксплуатации.

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

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

Как "бизнес-логика" выглядит в реальной задаче​

Частый сценарий из проектов: заказчик формулирует запрос "нужно быстрее согласовывать заявки".
Чтобы превратить это в реализуемую систему, команда проходит несколько шагов:

  1. Выявляет процесс AS IS: кто и где задерживает согласование.
  2. Фиксирует целевое состояние TO BE: что именно изменится после внедрения.
  3. Описывает правила принятия решений — кто согласует, в какие сроки, по каким условиям.
  4. Добавляет критерии приёмки: как понять, что изменение реально сработало.

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

Мини-чеклист качества требований​

Перед передачей задачи в разработку полезно пройти быстрый чеклист:

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

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

Содержание