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

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

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

Методика ЛЮСТРА решает следующие проблемы:

1. Частое изменение требований на проекте со стороны бизнеса из-за того, что:

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

2. Заказчики изначально формулируют конкретные решения и аналитику сложно в разговоре с ними перейти на выявление потребностей.

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

Наилучшим образом методика ЛЮСТРА проявляет себя в проектах, для которых верно одно или несколько из следующих утверждений:

1. Это проект по развитию существующей информационной системы.
2. Это стартовая автоматизация в компании со сложными бизнес-процессами.
3. В корпоративной среде произошел сдвиг в сторону требований к системе, когда и сами заказчики, и бизнес-аналитики формулируют требования к системе, а не бизнес-требования.
4. Бизнес-заказчики выдают большой объем информации, сложный для анализа и структурирования.

Методика детализирует и уточняет существующие стандарты по разработке требований: ISO/IEC/IEEE 29148, BABOK Guide, онтологию Вигерса, INCOSE.

В методике не рассматриваются другие этапы работы с требованиями в проекте по автоматизации:

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

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

Представленная схема похожа на люстру — по этой мнемотехнике можно запомнить методику разработки бизнес-требований.

• Л — легитимность. Убеждаемся, что опрашиваем нужного стейкхолдера, и проверяем правомерность требований к бизнесу, чтобы потом ни у кого из участников проекта не было оснований их оспорить.
• Юзер
• Стори: формулируем потребности стейкхолдеров, которые возникают из предъявленных к ним требований, контекста, в котором эти требования приходится выполнять, и личных интересов. Формулируем, например, в формате User Story
• Требование к
• Решению: потребности стейкхолдеров определяют требования к решению.
• А потом всё остальное: требование к решению, в свою очередь, в зависимости от проблем и целей проекта, рисков и выгод поможет подобрать правильные решения для бизнеса, некоторые из них потом трансформируются в требование к системе.

При опросе стейкхолдера проекта, который является ответственным сотрудником предприятия, следует действовать в следующей последовательности:

1. Найти ИКС — место возникновения изменения, которое привело к формированию потребности. Выясняем, нужного ли стейкхолдера мы опрашиваем.
2. Сформулировать БИЗНЕС-требование: выяснить требование к бизнесу в лице ответственного сотрудника. Проверяем источники и предпосылки требований.
3. Провести ОПРОС: определить, что формулирует стейкхолдер. Подталкиваем его к тому, чтобы вместо конкретных требований сформулировать потребности.
4. Сформулировать потребности ответственного сотрудника в формате User Story или Job Story: что ему нужно для того, чтобы выполнить взятые на себя обязательства.
5. Выявить СВОД бизнес-функций, которые затрагивает потребность в данном бизнес-процессе. Выявляем неявные и подразумеваемые требования, расширяем список стейкхолдеров для опроса.
6. Сформулировать требования к решению на основании потребностей и выявленного реестра бизнес-функций.

Рассмотрим подробно каждый шаг методики.

ИКС — место возникновения изменения, которое привело к формированию потребности.

Выясняем, нужного ли стейкхолдера мы опрашиваем:

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

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

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

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

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

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

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

Прежде чем выявить потребности сотрудника, выясняем: а что требуется от него самого? Задайте вопросы заказчику по мнемотехнике БИЗНЕС и сформулируйте требования по канве:

• База требования. В каком нормативном акте содержится требование к бизнесу в лице ответственного сотрудника? Если требование нигде не прописано, то кто источник требования? При каком условии это требование вступает в силу?

• Исполнитель. Кто должен выполнить требование?

• Заказчик. Кто выгодоприобретатель? Кто будет принимать исполнение требования?

• Нормативная Единица требования. В чём заключается требование? Что именно нужно выполнить? Какое действие с каким объектом нужно совершить?

• Стандарт требования. По каким параметрам требование можно считать выполненным? Место, время, продолжительность, формат, образ действия.

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

В рамках методики ЛЮСТРА бизнес-требования трактуются как требования к бизнесу, то есть то, что требуется от организации: выполнить обязательства, которые взяли на себя лица, ответственные за процессы на каждом иерархическом уровне компании и которые зафиксированы в нормативно-правовых актах страны, договорах с третьими лицами или во внутренних документах организации.

Требования к организации содержатся в следующих нормативно-правовых актах и документах:

1.Нормативно-правовые акты:
1) Конституция РФ
2) Международные договоры
3) Федеральные законы
4) Указы президента
5) Постановления правительства
6) Постановления главного санитарного врача РФ
7) Региональное законодательство
8) Муниципальные акты
9) Приказы федеральных министерств
10) Указания и положения Банка России
11) Приказы служб

2.Требования от основателей, владельцев, акционеров:
1) Бизнес-модель
2) Концепция
3) Миссия
4) Бизнес-план
5) Стратегия развития компании

3.Обязательства перед третьими лицами - клиентами, контрагентами, сотрудниками:
1) Договор оферты
2) Договор купли-продажи
3) Договор аренды
4) Договор об оказании услуг
5) Трудовой договор
6) Гражданско-правовой договор
7) и др.

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

• Устав
• Учетная политика
• Положения
• Правила
• Приказы
• Должностная инструкция
• Регламент
• Порядок
• Методика
• Рабочая инструкция

Согласно методике ЛЮСТРА не надо заходить слишком далеко для определения требования к бизнесу: достаточно найти зафиксированное требование к опрашиваемому ответственному лицу.

Однако для примера начнем с формулировки требования к организации:

Опишем требование к владельцу бизнес-процесса, то есть главному бухгалтеру, по канве:

Определить, что формулирует стейкхолдер:

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

Понятие требований в следующих документах:

• Стандарт IEEE 610.12−1990
• Стандарт ISO/IEC/IEEE 29148
• Российский ГОСТ 34.601−90
• BABOK Guide
• Руководство по написанию требований международного совета по системной инженерии (INCOSE)
• организационно-управленческий подход Six Sigma

трактуется со следующих точек зрения:

1. требуется от чего-то или кого-то
2. требуется кому-то
3. требуется что-то.

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

• к решению проблемы
• к системе,
• к другому лицу.

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

Стандарт ISO/IEC/IEEE 29148 и Руководство по написанию требований международного совета по системной инженерии (INCOSE) выделяют требования стейкхолдера отдельно от бизнес-требований. В стандарте ISO/IEC/IEEE 29148 потребности описываются понятием concerns — опасения, в INCOSE используется слово expectations — ожидания. В методике ЛЮСТРА предлагается:

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

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

• какие риски стейкхолдер несёт при невыполнении взятых на себя обязательств?
• что стейкхолдеру нужно, чтобы выполнить взятые на себя обязательства?

Напомню исходное требование от главного бухгалтера:

Хотя требование сформулировано в виде User Story, по сути это требование к системе. Для того чтобы вернуть главного бухгалтера на формулирование потребности, можно зайти издалека и опросить в произвольном формате об опасениях и ожиданиях.

Например, главный бухгалтер может выразить опасения следующим образом:

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

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

Ворох опасений и ожиданий мы приводим в более формализованный вид потребностей. Их можно описывать в разных форматах, рассмотрим два из них: User Story и Job story. В рамках методики ЛЮСТРА эти два формата подчеркивают место возникновения потребности:

• Интересы
• Контекст
• Требование к сотруднику

User Story — способ описания потребности, сформулированный как одно или более предложений на повседневном или деловом языке пользователя. В рамках методики ЛЮСТРА User Story следует применять, если место возникновения потребности — интересы стейкхолдера или требование к нему.

Изначально Job Story — фреймворк из концепции Jobs To Be Done для исследования целевой аудитории, её мотивов и проблем. В целях данной методики этот способ используется, если нужно сосредоточить внимание на контексте, в котором у ответственного лица возникли сложности.

Составляющие части форматов:

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

В нашем примере мы определили основную потребность главного бухгалтера:

Определить бизнес-процесс и бизнес-функцию, в рамках которых нужно сформулировать требования к решению. Каждый бизнес-процесс и подпроцесс можно разложить на следующие бизнес-функции, которые описываются словом СВОД:

• Событие: итог бизнес-процесса
• Выбор: решения, которые нужно принимать в рамках данного бизнес-процесса
• Операция: действия, которые нужно выполнять в рамках данного бизнес-процесса
• Данные: информация, которую нужно собрать, обработать, сохранить и предъявить в рамках данного бизнес-процесса.

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

Метасистема требований по методике ЛЮСТРА отличается от указанной в BABOK двумя предпосылками:

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

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

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

Управляющие бизнес-процессы:
1.Управление персоналом

• Найм и адаптация новых сотрудников.
• Оценка и мотивация персонала.

2.Финансовое управление

• Ведение учета и отчетности.
• Контроль кассовых операций и банковских переводов.

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

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

Любой бизнес-процесс можно разложить на следующие бизнес-функции, которые описываются словом СВОД:

• Событие: итог бизнес-процесса
• Выбор: решения, которые нужно принимать в рамках данного бизнес-процесса
• Операция: действия, которые нужно выполнять в рамках данного бизнес-процесса
• Данные: информация, которую нужно собрать, обработать, сохранить и предъявить в рамках данного бизнес-процесса

Рассмотрим подпроцесс: «Обслуживание покупателя на кассе». В соответствии с моделью СВОД, бизнес-функции можно описать следующим образом:

1.Событие: покупателю выдан товар и чек о покупке
2.Выбор: Кассиру нужно принять решение о том, можно ли отпустить товар и выдать чек о покупке или нет. Это зависит от того, успешно ли прошла оплата товара.
3.Операции:

• Сканирование товаров и вывод итоговой суммы к оплате.
• Принятие оплаты от покупателя (наличными или через POS-терминал).
• Выдача сдачи, если требуется
• Печать чека.

4.Данные:

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

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

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

Например, требование к бизнесу:

Это требование может быть, в итоге, реализовано совершенно разными способами, возьмем два варианта решения:

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

Первое решение определяет требование к владельцу бизнес-функции:

Требование к другому решению, включающее в себя кассу самообслуживания, звучит так:

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

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

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

Выделим в процессе сдачи налоговой декларации следующие функции:

События:

• Сдача налоговой декларации по налогу на прибыль в налоговый орган.
• Получение подтверждения о принятии декларации.

Выбор:

• Определить, можно ли запускать расчет налоговой декларации
• Определить, корректна ли налоговая декларация, то есть готова ли для подачи в ИФНС
• Определить, допустим ли рассчитанный налог на прибыль
• Определить, нужно ли вносить корректировки в учет и в декларацию

Операция:
Формирование налоговой декларации — внесение данных в налоговую декларацию, включая доходы, расходы, налоговые вычеты и льготы.

Данные:

• Финансовая информация: суммы доходов и расходов за отчетный по данным налогового учета.
• Информация о применяемых налоговых льготах и вычетах.
• Полные реквизиты предприятия
• Документы, подтверждающие финансовые операции

Перед тем как перейти к формулированию требования к решению, необходимо проанализировать информацию по каждой из бизнес-функций:

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

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

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

• создании продукта,
• автоматизации процесса,
• обучении сотрудников,
• оптимизации бизнес-процессов,
• найме новых сотрудников
• аутсорсе, и т.д.

Требование к решению можно описать по канве разработки любого требования:

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

1.Учетная политика предприятия в целях налогообложения

• Декларация по налогу на прибыль должна быть предоставлена в электронной форме, установленной приказом ФНС России, через личный кабинет налогоплательщика.
• Декларация по налогу на прибыль должна отражать сумму налога на прибыль на основании корректно подсчитанных доходов и расходов, расчет которых соответствует главе 25 НК РФ.

2.Регламент учёта доходов и расходов

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

Также мы выяснили потребность главного бухгалтера:

Требование к решению опишем по канве:

Требование к решению в зависимости от проблем и целей проекта, рисков и выгод поможет подобрать правильные решения для бизнеса, некоторые из них потом трансформируются в требование к системе. Эти этапы уже не входят в методику ЛЮСТРА, однако на сквозном примере можно проследить, как методика помогает в дальнейшем описать требования к системе.

При перечислении бизнес-функций по методу СВОД мы выяснили, что необходимо:

• предоставить налоговую декларацию в ИФНС,
• для этого налоговую декларацию нужно сформировать,
• для этого нужно определить момент запуска формирования декларации по налогу на прибыль

Как мы проследили, требование к системе не возникло «из воздуха»:

1. Требование к решению о том, что декларация должна быть сформирована не ранее 19 и не позднее 20 числа месяца, следующего за отчетным кварталом, преобразовалось в требование к системе, что время формирования декларации должно быть не более одного рабочего дня, то есть восьми часов. Это не соответствует исходному требованию главного бухгалтера, что декларация должна быть сформирована за полчаса. Оказывается, она может быть сформирована и за полчаса, и за час, и за четыре — главное, не больше восьми.
2. Требование к решению о том, что декларация должна быть сдана в электронной форме, установленной приказом ФНС России, выразилось в конкретных системных требованиях: форме и формате.

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

Согласно методике мы после этого должны опросить бухгалтера по налоговой отчетности и выявить его потребность.

На основании потребности и СВОДа бизнес-функций сформулируем требования к решению:

На основании этих требований к решению будут сформулированы свои требования к системе.

Производственная компания, проект по автоматизации нового бизнес-направления.

Поступило исходное требование от оператора склада:

Выясняем причину изменений: изменилось требование к сотруднику.

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

2. Сформулировать БИЗНЕС-требование

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

3. Провести ОПРОС
Выясняем у руководителя отдела продаж, что это он переложил на оператора склада ответственность сформулировать требование, поэтому получилось требование к системе.

4. Сформулировать потребность
Направляем ход разговора в сторону формулирования потребности руководителя отдела продаж:

5. Сформулировать СВОД бизнес-функций
Процесс «Продажи», подпроцесс «Выставление документов, подтверждающих факт продажи». Разложим его на бизнес-функции:

События, которые являются итогом бизнес-процесса:

• Доставка товара: клиент получает товар вместе с накладной и товарной накладной.
• Самовывоз: клиент забирает товар с накладной.

Выбор, которые необходимо сделать в бизнес-процессе:

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

Операции, которые нужно выполнять в рамках данного бизнес-процесса:

• Принять заказ и выбор способа получения товара
• Сформировать необходимые документы в зависимости от выбранного способа получения
• Проверить корректность подготовленных документов
• Распечатать документы
• Выдать документы клиенту вместе с товаром
• Сохранить копии документов для внутреннего учета и отчетности

Данные, которые нужно собрать, обработать, сохранить и предъявить в рамках данного бизнес-процесса

• Информация о заказе (номер заказа, дата, наименование товара, количество)
• Информация о клиенте (ФИО, адрес доставки, контактные данные)
• Информация о способе получения товара (доставка или самовывоз)
• Информация для оформления транспортной накладной в соответствии с требованиями законодательства

6. Сформулировать требования к решению
На основании выявленных потребностей руководителя отдела продаж мы можем составить следующие требования к решению:

ТВ соответствии с требованием к решению впоследствии вместе с заказчиком можно разработать разные варианты решения, например:

1. Внедрение электронного документооборота, который исключит нужду в печати.
2. Интеграция учетной системы с веб-сайтом, который будет отслеживать выбор клиента (самовывоз или доставка) и автоматически формировать необходимый набор документов.
3. Автоматизация существующей системы:

1) в случае наличия в накладной услуги доставки, программное обеспечение автоматически должно формировать и «Накладную», и «Транспортную накладную».
2) в случае включения накладной в план по доставке, программное обеспечение автоматически должно формировать и «Накладную», и «Транспортную накладную».

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

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

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

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

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

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

2. При переходе от бизнес-требований к требованиям к решению необходимо оставить следующую информацию:

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

3. Для работы над требованиями к системе должна остаться следующая информация:

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

В проекте по автоматизации ключевыми являются требования к системе, однако они не должны возникать «из воздуха». С помощью методики ЛЮСТРА мы подсвечиваем заказчику направление, по которому мы должны пойти, чтобы разработать корректные бизнес-требования. Необязательно быть профессионалом и разбираться в предметной области, просто нужно начинать с того, чтобы уточнить у стейкхолдеров, на основании чего они действуют и принимают решения, что они должны и кому, и почему именно сейчас возникла потребность в изменениях.

Методика направлена на развитие способности видеть за программным кодом живой организм компании, его потребности и потребности его клиентов, выступая своеобразным напоминанием о первичности бизнеса перед системой. Она применяется при опросе стейкхолдера, когда сам заказчик формулирует требования на языке взаимодействия пользователя с системой: «Я хочу, чтобы система сама формировала», «Алгоритм должен рассчитать», «Мне нужна кнопка» — и помогает направить разговор о разработке требований в сторону бизнеса.

Методика минимизирует последующие изменения требований в течение проекта за счет того, что в начале проекта:

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