Будь бизнес-аналитиком

Диана Сюняева, 2023

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

Требования

Следующий шаг приведет нас к главе, посвященной требованиям.

Все начинается с идеи. Например, такой идеи: «Хочу, чтобы холодильник сам заказывал продукты, когда надо». Такая «хотелка» к моменту итоговой реализации начинает обрастать другими «хотелками», как снежный ком при спуске с горы. Юристы хотят, чтобы пользовательское соглашение к холодильнику было размером с «Войну и мир». Продуктовые магазины хотят, чтобы холодильник заказывал у них только самые дорогие продукты. А пользователь хочет… вкусно поесть и не переживать за пустой холодильник. И чтобы было место для магнитиков.

Набор таких «хотелок» и называется требованиями.

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

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

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

Требования влияют не только на сам результат, но и на восприятие этого результата. Помните, что требования исходят от человека. А человеку свойственно радоваться от исполнения желаний (и требований).

Требования не равно цель

Важно понимать, что Цель и Требование — это разные понятия в рамках реализации проекта.

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

Требования — это формализованное описание потребностей (т.е. конкретные функции, свойства и атрибуты).

Цель. Строго связано с бизнес-показателями. Ставится 1 раз на весь период реализации проекта.

Пример: Повысить эффективность процесса обслуживания на 20%.

Требования могут ставиться многократно к разным объектам внутри проекта изменений.

Пример: Запускать процесс X ежедневно с 9 до 10 утра за исключением вторника и воскресенья.

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

К ИТ-системе / к ИТ-решению

— Выбираем конкретную компоненту в ИТ-решении

— Описываем ее функциональность

— Описываем нефункциональные требования

Акценты на:

— атрибуты системы

— сроки осуществления операций

— использование справочников

К Бизнес-процессу

— Выбираем процесс или часть процесса (с учетом рамок процесса)

— Описываем требования к выполнению подшагов процесса

— Описываем условия выполнения подшагов процесса

Акценты на:

— сроках выполнения

— участниках и ответственных

— ограничениях процесса

— условиях процесса

Существует универсальная формула описания требований:

Пример 1

1.1. Требуется, чтобы будильник включался ежедневно с понедельника по пятницу в 7.00 и играл с повышением звука от уровня 1 до уровня 5.

1.2. В случае отсутствия реакции на будильник в течение 1 минуты, будильник производит паузу в течение 20 секунд и цикл п. 1.1 запускается заново.

Пример 2

2.1. Требуется автоматизированная отправка платежного поручения на адрес контрагента из системы N в момент осуществления транзакции К для каждой операции с меткой J.

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

Классификация

Сбор требований начинается с определения того, что требование должно из себя представлять. Разобраться в типах требований поможет общая классификация.

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

Для чего это нужно нашей компании?

— Автоматизировать процессы

— Сократить затраты времени на этапах процесса

— Повысить качество продукции

— Оптимизировать принятие решений

2. Требования стейкхолдеров

Что хочет стейкхолдер?

— Рассчитать производительность и экономическую эффективность

— Получить отчеты в интересующих форматах и детализации

— Отправить запросы и получить актуальную информацию

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

Какие условия окружающей среды нужно учитывать и для чего?

— Создать условия для локализации

— Обеспечить юридическую, финансовую и аудиторскую прозрачность

— Сохранить конфиденциальность

— Написать документацию для пользователей

— Сохранить непрерывность бизнес-процессов

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

Что должно делать итоговое решение?

— Персонифицировать настройки

— Ограничивать доступ

— Обеспечить возможность поиска данных

— Предоставить возможность интеграции данных из других систем

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

Что нужно сделать для соответствия внешним ограничениям?

— Выполнить условия нормативных документов

— Учесть все вводимые регулятором ограничения

— Получить лицензии и другие разрешения

6. Переходные требования

Что нужно для перехода из текущего состояния в будущее?

— Обучить пользователей из бизнес-подразделений

— Хранить документацию и данные при миграции из одной архитектуры в другую

— Разработать алгоритм ввода в эксплуатацию

— Оказать поддержку на этапе ввода в эксплуатацию

Пример: развитие персонала и обучающие приложения и порталы

Цель: Повышение эффективности производственных процессов на Х процентов за счет развития цифровых компетенций сотрудников

Бизнес-требование: Повышение численности сотрудников, прошедших курсы по ИТ, на 10%

Требование заинтересованных лиц (рядовой сотрудник):

— Доступность курса вне корпоративной сети

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

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

Нефункциональное требование: Система должна стабильно работать при нагрузке не менее 1000 пользователей, одновременно работающих с видео-контентом

Свойства, которыми должны обладать требования легко запомнить по мнемоформуле: 4П-НОСОК.

Какими должны быть требования?

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

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

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

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

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

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

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

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

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

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

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

Перед тем, как приступить к этапу «Выявление», убедитесь, что у вас и ваших собеседников одинаковое понимание термина «требования».

Методы выявления

Традиционные

— Интервью

— Воркшопы

— Фокус-группы

— Анкетирование

— Анализ системных интерфейсов

— Анализ пользовательских интерфейсов

— Анализ документов

Дополнительные:

— Обратная связь от сотрудников

— Наблюдение за пользователями

— Наблюдение за разработчиками

— Анализ обращений в службу поддержки

— Обзор систем конкурентов

— Прототипирование

— Проверка концепции

Как выбрать метод выявления требований

1) Доступность информации

2) Количество источников информации

3) Бюджет проекта

4) Другие ограничения

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

Важно не только выбрать корректный метод сбора требований, но и качественно пройти все этапы метода.

Матрица выбора методов выявления требований

Такой тип матрицы для помощи в выборе методов выявления требований предложен К. Вигерсом.

В матрице собраны методы выявления требований для разных типов проектов разработки.

Методы анализа

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

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

Какие компоненты входят в анализ требований?

1. Понимание: Фиксируем описания в доступных для понимания терминах, со всеми деталями

2. Моделирование: Применяем моделирование процессов и данных для отображения вносимых изменений

3. Верификация: Проверяем соответствие требований критериям качества

4. Управление: Обеспечиваем исполнение и внесение изменений в подтвержденные требования

Виды моделирования при анализе требований

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

Моделирование процесса

Отображение взаимодействия между разными людьми и задачами в виде последовательности операций

Моделирование данных

Предоставление структуры и формата данных, которые используются для решения

Моделирование предметной области

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

Моделирование интерфейса

Отображение структуры или дизайн-концепции интерфейса

Диаграммы потоков данных

Отображение потока движения данных: ввод, хранение, обработка, вывод

Диаграммы последовательности

Моделирование последовательности взаимодействия между объектами внутри одного сценария использования

Формализация

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

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

— Концепция проекта (бизнес-требования)

— Презентация об архитектуре решения

— Техническое задание

— Технический проект

Способы формализации требований

Приоритизация

Приоритизация — это процесс определения относительной важности объекта (информации, задачи, требования и пр.) на основе предварительной оценки его значения, рисков, сложности реализация или других четких критериев. BABOK 3.0

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

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

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

Для приоритизации требований разработан целый арсенал методов.

Конец ознакомительного фрагмента.

Примечания

5

Лучшее определение по мнению К. Вигерса