Формирование требований и классификация требований

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

Сбор требований

Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.
Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.
Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:

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

Выжимка по процессу формирования требований

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

Бизнес-процессы — самое начало работы.
Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. Бизнес-моделирование
2. Выявление требований
3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
4. Реализация
5. Тестирование
6. Опытно-промышленная эксплуатация
7. Support и развитие системы

Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

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

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

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

Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM, TelelogicDoors, Rational RequisitePro) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

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

Схема процесса разработки с уровнями требований

Формирование и анализ требований

Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.
Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.
Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

Аттестация требований

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

Подготовка к интервью по сбору требований у заказчика

Классификация и описание требований на пути от бизнеса к технической реализации

Компания — Бизнес-требования

Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта

Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:

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

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

Заказчик — Документ требований заинтересованных лиц

Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:

Бизнес-назначение
Бизнес-рамки
Обзор бизнеса
Заинтересованные лица
Организационная среда
Цели и результаты
Бизнес-модель
Информационная среда
Бизнес-процессы
Политики и правила
Ограничения деятельности
Организационная структура
Концепция использования системы
Сценарии эксплуатации
Проектные ограничения

Пользователь — Требования пользователя

Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.
Источники: Пользователь
Документ: Пользовательские требования/Требования к ПО
Ответственный: Системный аналитик

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

Проблемы при формировании пользовательских требований

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

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

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

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

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

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

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

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

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

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

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:

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

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

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

Требования к продукту

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

Организационные требования

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

Требования к интеграции

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

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:

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

Интеграция точка-точка

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

Интеграция данных

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

Задачи интеграции данных:

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

Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.

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

Требования к пользовательскому интерфейсу

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

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

К первой группе можно отнести следующие типы требований:

Требования к размещению элементов управления на экранных формах
Требования к содержанию и оформлению выводимых сообщений
Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

Требования к реакции системы на ввод пользователя
Требования к времени отклика на команды пользователя

Управление требованиями

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

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

Классификация изменяемых требований

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

Процесс управления изменениями

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

Кто читает документацию

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

Как правильно сформулировать и контролировать цель проекта?

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

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

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

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

Документы процесса разработки и управления требованиями (по Вигерсу)

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

Документы процесса разработки требований

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

Документы процесса управления требованиями

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

Пример дорожной карты совершенствования процессов работы с требованиями

Документ по управлению требованиями

Управление требованиями from Ivan Shamaev

Краткое введение в свод знаний по бизнес-анализу BABOK 3

Перевод выполнил: Шамаев Иван (ivan.shamaev@gmail.com). Копирование материалов статьи запрещено!

Введение в свод знаний по бизнес-анализу

Свод знаний по бизнес-анализу (BABOK Guide v.3) — это всемирно признанный стандарт по практикам бизнес-анализа. Руководство описывает области знаний бизнес-анализа, задачи, базовые компетенции, методики и перспективы на то, как подходить к бизнес-анализу.
Рисунок «Взаимосвязи между областями знаний в бизнес-анализе»:

Ключевые концепции бизнес-анализа

Глава «Ключевые концепции бизнес-анализа» содержит в себе информацию, которая обеспечивает основу для другого контента, концепций и идей в рамках руководства BABOK. Данная глава обеспечивает бизнес-аналитиков базовым пониманием центральных идей, необходимых для понимания и применения Руководства BABOK в своей повседневной практике по бизнес-анализу.
Эта глава состоит из:
• Центральная концептуальная модель бизнес-анализа (BACCM): определяет концептуальную основу для профессии в бизнес-анализе.
• Основные термины: даются определения основных понятий, которые выделены из-за их важности для руководства BABOK.
• Схема классификации требований: определяются уровни или типы требований, которые помогают бизнес-аналитику и другим заинтересованным сторонам в классификации требований.
• Заинтересованные стороны (Stakeholders): определяются роли и характеристики групп или лиц, которые участвуют или затрагиваются в ходе деятельности по бизнес-анализу в пределах изменения.
• Требования и проектирование (дизайн): описываются различия между требованиями и дизайном и их важность, поскольку они относятся к бизнес-анализу.
Рисунок «Концепт BACCM»:

Рисунок «Цикл требований и дизайна»:

Планирование и мониторинг бизнес-анализа

Область знаний по планированию и мониторингу бизнес-анализа — это задачи, при выполнении которых организуются и координируются усилия бизнес-аналитиков и заинтересованных сторон. Эти задачи производят результаты, которые используются в качестве ключевых принципов для других задач на протяжении всего руководства BABOK.
Область знаний по планированию и мониторингу бизнес-анализа включает в себя следующие задачи:
• Подход к планированию бизнес-анализа: описывает работы по планированию бизнес-анализа от создания или выбора методологии до планирования отдельных мероприятий, задач и конечных результатов.
• План взаимодействия с заинтересованными сторонами: описывает понимание заинтересованных сторон, которые имеют отношение к изменению, что нужно от них бизнес-аналитикам, что заинтересованные стороны требуют от бизнес-аналитиков и лучшие способы по сотрудничеству.
• Управление планом по бизнес-анализу: определяет компоненты бизнес-анализа, которые используются для поддержки функций управления в организации. Это помогает гарантировать, что решения приняты правильно и последовательно, и поддерживает процесс, который обеспечивает необходимой информацией людей, которые принимают решения. Примерами этого являются управление требованиями, управление рисками в бизнес-анализе, аллокация/распределение ресурсов в бизнес-анализе.
• Управление информацией в плане по бизнес-анализу: определяет как информация, разработанная бизнес-аналитиками (включая требования и дизайн), фиксируется, хранится и интегрируется с другой информацией для долгосрочного использования.
• Идентификация возможностей повышения производительности бизнес-анализа: описывает управление и мониторинг того, как работа по бизнес-анализу выполняется, для того, чтобы гарантировать, что обязательства будут выполнены и непрерывное обучение и совершенствование реализуется.

Выявление и взаимодействие

Область знаний «Выявление требований и взаимодействие (сотрудничество)» описывает задачи, которые бизнес-аналитики выполняют для того, чтобы получить информацию от заинтересованных сторон, а также для того, чтобы подтвердить результаты. Эта область также описывает коммуникацию с заинтересованными лицами после того, как информация по бизнес-анализу собрана.
В ходе выявления требований информация получается от заинтересованных сторон или из других источников. Это основной путь по обнаружению требований и проектированию информации, также данный процесс может включать прямые беседы с заинтересованными лицами, изучение различных локальных практик, экспериментирование, или простую передачу информации. Взаимодействие (сотрудничество) — это действие двух или более лиц, которые вместе работают для достижения общей цели. Область знаний по «Извлечению и взаимодействию» описывает, как бизнес-аналитики определяют и достигают соглашения о взаимном понимании всех видов информации по бизнес-анализу. Работа по выявлению и взаимодействию не является какой-то отдельной фазой в бизнес-анализе, скорей всего, данная деятельность продолжается на протяжении всего этапа по бизнес-анализу.
Выявление и сотрудничество могут быть запланированными этапами, незапланированными, или и то, и другое вместе. Планируемые виды деятельности, такие как семинары, эксперименты, и/или обследования, могут быть структурированы и организованы заранее. Незапланированные мероприятия осуществляются без предварительного уведомления, например, на последней минуте или во время запланированных взаимодействия/переговоров. Информация по бизнес-анализу, которая получена в ходе незапланированной активности требует более глубокого изучения в рамках намечаемой деятельности.
Выявление информации по бизнес-анализу — это не изолированная деятельность. Информация возникает при выполнении любой задачи, которая включает в себя взаимодействие с заинтересованными сторонами, а также, пока бизнес-аналитик выполняет независимую аналитическую работу. Выявление может потребовать дополнительную итерацию по выявлению деталей для того, чтобы заполнить пробелы в информации или повысить понимание.
Область знаний по Выявлению требований и сотрудничеству состоит из следующих задач:
• Подготовка к выявлению: предполагает проверку того, что заинтересованные лица получают информацию, необходимую для обеспечения понимания деятельности, которую они собираются выполнять. Данная задача задает общий набор ожиданий относительно итогов деятельности. Подготовка может также включать выявление источников для обследования или подготовку к проведению эксперимента для того, чтобы увидеть, если изменение процесса приведут к фактическому его улучшению.
• Проведение выявления: описывает работу, которая выполняется для того, чтобы понять потребности заинтересованных сторон и определить потенциальные решения, которые могут удовлетворить эти потребности. Выявление может включать в себя прямое взаимодействие с заинтересованными сторонами, проведение исследований или проведение экспериментов.
• Подтвердите результаты по этапу выявления: предполагает проверку того, что заинтересованные стороны имеют общее понимание результатов сбора информации, что выявленная информация правильно записана, а также что бизнес-аналитик имеет информацию, открытую через деятельность по выявлению. Эта задача также предполагает сравнение полученной информации с другой информацией для того, чтобы выявить несоответствия или пробелы.
• Информация по бизнес-анализу для коммуникаций: обеспечивает заинтересованных лиц информацией, в которой они нуждаются в текущий момент. Информация представлена в удобном виде, используется правильная терминология и концепции.
• Управление взаимодействием с заинтересованными сторонами: описывает работу с заинтересованными сторонами по вовлечению их в общий процесс бизнес-анализа для того, чтобы бизнес-аналитик получил те результаты, которые ему необходимы.

Управление жизненным циклом требований

Область знаний по управлению жизненным циклом требований описывает задачи, которые бизнес-аналитик выполняет для того, чтобы управлять и поддерживать требования и дизайн информации от зарождения до утилизации. Эти задачи описывают установление конструктивных отношений между связанными требованиями и дизайном, оценивание изменений в требованиях и дизайне, когда изменения предлагаются, а также анализ изменений и получение согласия на их реализацию.
Целью управления жизненным циклом требований является обеспечение того, что бизнес-требования, требования заинтересованных лиц и требования по решению и дизайн, будут соответствовать друг другу и, что решение реализует все пункты указанных требований и дизайна. Данная область знаний включает в себя уровень контроля над требованиями и над тем, как требования будут реализованы в реальном решении, как решение будет построено и поставлено заказчику. Этот этап позволяет гарантировать, что информация по бизнес-анализу доступна для использования в будущем.
Жизненный цикл требований:
• Начинается с представления бизнес-потребностей как требований;
• Продолжается в ходе развития Решения;
• Заканчивается, когда Решение и требования списываются (утилизируются).
Управление требованиями не заканчивается после того, как Решение реализовано. На протяжении всего срока эксплуатации Решения, требования по прежнему представляют ценность, когда они управляются надлежащим образом.
В рамках области знаний по управлению жизненным циклом требований, концепция жизненного цикла отделена от методологии или процесса, который используется для управления работой по бизнес-анализу. Жизненный цикл относится к существованию различных фаз и состояний, через которые требования проходят как часть любых изменений. Требования могут находиться в нескольких состояниях одновременно.

Стратегический анализ

Стратегия определяет наиболее эффективный способ применения потенциала предприятия в целях достижения желаемых целей и задач. Стратегии могут существовать для всего предприятия, для отдела, департамента или региона, а также для продукта, проекта или итерации.
Область знаний по стратегическому анализу описывает работу по бизнес-анализу, которая должна быть выполнена для взаимодействия с заинтересованными сторонами с целью выявления потребностей стратегического или тактического значения (бизнес-потребности), что позволит предприятию удовлетворить эту потребность, а также выровнять результирующую стратегию путем изменений высокоуровневых и низкоуровневых стратегий (относительно рассматриваемых стратегий).
Стратегический анализ фокусируется на определении будущих и переходных состояний, которые необходимы для того, чтобы удовлетворить бизнес-потребности, а также на работе, которая требуется для определения потребностей и границ пространства решений. Стратегический анализ охватывает стратегическое мышление в бизнес-анализе, а также исследования или представление возможных решений, которые позволят предприятию создать большую ценность для заинтересованных сторон, и/или захватить большую ценность для самого предприятия.
Стратегический анализ предоставляет контекст для анализа требований и определения дизайна в рамках рассматриваемого изменения. Стратегический анализ следует выполнять в зависимости от того, как определены бизнес-потребности. Это позволяет заинтересованным сторонам делать предположение о том, следует ли удовлетворять эту потребность или нет. Стратегический анализ представляет собой непрерывный процесс, который оценивает любые изменения в потребностях, в их контексте, или любой новой информации, которая может означать, что может потребоваться корректировка стратегии проводимых изменений.
На следующем рисунке показан спектр ценности как прогресс деятельности бизнес-анализа от предоставления потенциальной ценности до реальной ценности.
Рисунок «Спектр ценности бизнес-анализа» (стратегический анализ):

При выполнении стратегического анализа, бизнес-аналитики должны учитывать контекст, в котором они работают, а также какой предсказуемый диапазон возможных исходов существует. Когда изменения будут иметь предсказуемый результат, будущие состояния и возможные переходные состояния могут обычно четко определены, а также стратегия может быть четко распланирована. Если результат изменения трудно предсказать, то стратегия может потребовать сфокусироваться на вопросах снижения рисков, тестировании предположений, и менять курс до тех пор, пока стратегия, которая приведет к достижении бизнес-целей, не будет идентифицирована или до тех пор пока не закончится инициатива. Эти задачи могут быть выполнены в любом порядке, хотя они часто выполняются одновременно, а стратегия должна быть сформирована таким образом, чтобы она была фактически достижима.
Стратегия может быть представлена в виде стратегического плана, концепции продукта, бизнес-кейса, дорожной карты по продукту (план выпуска продукции) или других артефактов.
Область знаний по стратегическому анализу включает в себя следующие задачи:
• Анализ текущего состояния: понимание бизнес-потребности и как бизнес-потребность относится к текущему функционированию предприятия. Наборы базовых показателей и контекста для изменений.
• Определение будущего состояния: определяет цели и задачи, которые будут демонстрировать, что бизнес-потребности удовлетворены, а также определяет какие части предприятия нуждаются в изменениях для того, чтобы удовлетворить поставленные цели и задачи.
• Оценка рисков: понимание неопределенности вокруг изменений, учитывается влияние этих неопределенностей на возможность увеличения ценности через осуществление этих изменений, а также рекомендация действий для устранения рисков (где это уместно).
• Определение стратегии изменений: выполняется GAP-анализ между текущим и будущим состоянием, оцениваются варианты достижения будущего состояния и разрабатываются рекомендации по методикам достижения высокой ценности для перехода в будущее состояние (включая переходные состояния), которые могут потребоваться на пути.

Анализ требований и определение дизайна

Область знаний по анализу требований и определению дизайна описывает задачи, которые бизнес-аналитики выполняют, чтобы структурировать и организовать требования, обнаруженные в ходе процесса выявления требований, формулируют и моделируют требования и дизайн, а также валидируют (проверяют) и верифицируют (утверждают) информацию, идентифицируют варианты решений, которые отвечают бизнес-потребностям, и оценивают потенциальную ценность, которая может быть получена при реализации каждого варианта решения. Эта область знаний охватывает дополнительные и итерационные мероприятия, начиная от первоначальной концепции и исследования потребностей через трансформацию этих потребностей в конкретное рекомендуемое решение.
Требования и дизайн — очень важные инструменты, используемые аналитиками для того, чтобы определить и направить необходимые изменения. Основное различие между требованиями и дизайном — это как они используются и кем они используются. То, что является дизайном для одного человека, может быть требованиями для другого человека. Требования и дизайн могут быть высокоуровневыми или очень детализированными исходя из того, что является наиболее подходящим для потребителей информации. Роль бизнес-аналитика в моделировании потребностей, требований, дизайна и решения играет важную роль в проведении тщательного анализа и общения с другими заинтересованными лицами. Форма, уровень детализации, а также что будет смоделировано полностью зависит от контекста, аудитории и целей.
Бизнес-аналитики анализируют потенциальную ценность как требований, так и дизайна. Во взаимодействии с предметными экспертами по части внедрения решений, бизнес-аналитики определяют варианты решений, которые могут быть оценены для того, чтобы рекомендовать лучший вариант решения, который удовлетворяет потребность и приносит наибольшую ценность. На следующем рисунке показан спектр ценности процесса деятельности по бизнес-анализу от рассмотрения потенциальной ценности до фактической ценности.
Рисунок «Спектр ценности бизнес-анализа» (Анализ требований и определение дизайна):

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

Оценка решения

Область знаний по оценке Решения описывает задачи, которые бизнес-аналитики выполняют для оценки эффективности и ценности поставляемого решения для использования на предприятии, а также чтобы рекомендовать действия по устранению барьеров и ограничений, которые препятствуют более полно использовать ценность решения.
Хотя, возможно, существует некоторое сходство с деятельностью, которая осуществляется в стратегическом анализе, или на этапе Анализа требований и определения дизайна, важное значение данному этапу, по сравнению с другими этапами, придает наличие фактического решения (Т.е. бизнес-аналитики оперируют конкретными характеристиками решения). Это может быть только часть Решения, но решение или компонент решения уже реализуется или работает в той или иной форме. Задачи по оценке решения, которые поддерживают реализацию выгод может быть инициировано до изменений, пока текущее решение оценивается, или после того как решение уже реализовано.
Задачи по оценке решения могут быть выполнены для компонентов решения на различных стадиях разработки:
• Прототипы или обоснование концепта: выполняется в виде ограниченных версий Решения, которые демонстрируют ценность.
• Пилот или бета-релиз: ограниченная реализация или версии решения, которое используется для того, чтобы работать с реальными проблемами и чтобы понять насколько хорошо данное решение на самом деле обеспечивает ценность, прежде чем перейти к полной реализации Решения.
• Оперативные релизы: полные версии частичного или готового решения, которое используется для того, чтобы достичь бизнес-цели, выполнить процессы или достигнуть желаемого результата.
Оценка решения описывает задачи, которые анализируют фактическую ценность, которая будет получена в момент поставки, идентифицируют ограничения, которые могут мешать получить ценность от реализации, а также дают рекомендации по увеличению ценности решения. Оценка решения может включать любые комбинации оценок производительности, тестов и экспериментов, а также может сочетать в себе как объективные, так и субъективные оценки ценности. Оценка Решения в целом фокусируется на компонентах предприятия, нежели полностью на всем предприятии.
Рисунок «Спектр ценности бизнес-анализа» (оценка решения):

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

Базовые компетенции

В Главе Базовые компетенции приводятся описание поведения бизнес-аналитиков, характеристики, знания и личностные качества, которые помогают в практике бизнес-анализа.
Базовые компетенции, описанные в главе, не являются уникальными только для сферы бизнес-анализа. Они описаны для того, чтобы помочь читателям узнать о диапазоне фундаментальных навыков, которые требуются и которые обеспечивают основу для освоения новых навыков и знаний, чтобы стать более адаптируемыми бизнес-аналитиками.
Базовые компетенции сгруппированы в шесть категорий:
• Аналитическое мышление и Решение проблем;
• Поведенческие характеристики;
• Бизнес-знания;
• Навыки коммуникаций;
• Навыки взаимодействия;
• Инструменты и технологии.
Каждая из этих базовых компетенций приводится с целью, определением, а также с указанием мер для измерения эффективности.

Техники

Глава «Техники» дает верхнеуровневый обзор методов/техник, которые упоминаются в Своде знаний по бизнес-анализу (BABOK Guide). Техники — это методы, которые используют бизнес-аналитики для того, чтобы выполнять задачи по бизнес-анализу.
Техники, описанные в BABOK Guide, предназначены для того, чтобы охватить наиболее распространенные методики, которые приняты в сообществе по бизнес-анализу. Бизнес-аналитики применяют свой опыт и обсуждают какие методы являются наиболее подходящими для той или иной ситуации и как применять каждый метод. Это может включать в себя техники, которые не описаны в BABOK Guide. Так как практика бизнес-анализа эволюционирует, то техники будут добавляться, изменяться, удаляться из будущих версий руководства BABOK.
В ряде случаев, набор концептуально аналогичных подходов группируется в единую технику. Любой подход в технике может быть использован по отдельности или в комбинации для достижения цели техники.

Перспективы

Перспективы используются в работе по бизнес-анализу для того, чтобы сфокусироваться на задачах и техниках, которые характерны в контексте конкретных инициатив. Большинство инициатив, скорей всего, будут содержать одну или больше перспектив.
Перспективы, включенные в руководство BABOK:
• Agile (Гибкая методология разработки);
• Business Intelligence (Бизнес-аналитика);
• Information Technology (Информационные технологии);
• Business Architecture (Архитектура бизнеса);
• Business Process Management (Управление бизнес-процессами).
Эти перспективы не являются полным списком всех возможных перспектив, в которых практикуется бизнес-анализ. Перспективы обсуждаются в руководстве BABOK и представляют наиболее распространенные виды бизнес-анализа на момент написания.
Любая из приведенных инициатив включает одну, многие или все эти перспективы. Например, инициатива может иметь компоненту технологии (перспектива информационных технологий), компонента технологии может означать изменения в бизнес-процессах (Перспектива управления бизнес-процессами), инициатива может определять часть или все работы с применением agile подхода (Перспектива гибких методик разработки). Другая инициатива может объединять две организации и это потребует посмотреть на бизнес-возможности и как трансформация будет влиять на эти возможности (Перспектива архитектуры бизнеса), а также какая обновленная информации потребуется для бизнес-лидеров для принятия решений и анализа (Перспектива бизнес-аналитики, BI). Большие и сложные инициативы, скорей всего, будут использовать все перспективы.
Хотя задачи по бизнес-анализу детализированные в Руководстве BABOK предназначены для применения во всех областях бизнес-анализа, они также имеют отношение к каждой конкретной перспективе бизнес-анализа. Перспективы обеспечивают пути подходов к исполнению работы по бизнес-анализу в более сфокусированной форме по отношению к контексту. Перспективы помогают интерпретировать и понять области знаний и задачи в Руководстве BABOK, взглянув через «увеличительное стекло» текущих работ.
Каждая перспектива следует общей структуре:
• Change Scope (Изменение границ);
• Business Analysis Scope (Границы бизнес-анализа);
• Methodologies, Approaches, and Techniques (Методологии, подходы и техники);
• Underlying Competencies (Базовые компетенции);
• Impact on Knowledge Areas (Влияние/воздействие на области знаний).

Перевод выполнил: Шамаев Иван (ivan.shamaev@gmail.com). Копирование материалов статьи запрещено!

Лучшие практики по бизнес-анализу

Страница отсутствует.