Область знания. Анализ требований и определение дизайна

Записаться

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

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

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

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

После того, как мы перешли от потребностей к требованию, кажется, можно сразу перейти к решению. Но нет, в BABOK будет еще один промежуточный слой, который называется дизайн. Это представление решения. Если требование – это представление потребностей, то дизайн – это представление решения. Получается так, что с одной стороны есть потребность, с другой стороны есть решение. Но, прежде чем перейти от потребности к решению, мы должны понять требования и дизайн этого решения. Таким образом, четыре ключевых термина важны для данной области знания. Дизайн – это представление решения, пригодное для использования. Решение можно представлять по-разному. Для того, чтобы дать понять заинтересованной стороне, что решение из себя представляет, делают какого-то рода дизайн данного решения.

Я уже приводил пример, когда заказчик может выразить потребность сократить время выполнения бизнес-процесса. Вы должны специфицировать требование: сократить время выполнения на 10%, трудозатраты на 20% и т.д. После того, как вы сформулировали требования, какой может быть дизайн данного решения? Что может быть решением? Решением может быть новый бизнес-процесс. Дизайном этого решения может быть новая модель процесса.

Решение – специфический путь удовлетворения одной или нескольких потребностей в рамках какого-то контекста.

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

Для дальнейшего рассмотрения в этой области знания я буду пользоваться кейсом. Кейс следующий – вы бизнес-аналитик на крупном производственном предприятии, у которого есть филиальная сеть по России. Руководство решило начать проект по внедрению новой информационной системы финансовых модулей и заменить старую наследуемую систему. Система класса ERP (планирование ресурсов предприятия, Enterprise Resource Planning). Главная заинтересованная сторона – спонсор (это у нас финансовый директор). Методологом по бухгалтерскому учету, по финансам в целом выступает внешняя компания (внешние аудиторы). В качестве заинтересованных сторон, экспертов по предметной области, выступают руководители финансовых или бухгалтерских служб. Данный кейс мы будем вспоминать по ходу того, как я буду рассказывать про эту область знания.

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

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

Далее, результатами выполнения задачи 4.2 и 4.3 будут являться результаты выявления бизнес-аналитической информации (фактически в любом статусе). На вход этой области знаний поступают все выходы из области знания «Выявление и взаимодействие».

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

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

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

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

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

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

Разберем их подробно. Задача 7.1 – «Специфицирование и моделирование требований». Эта задача посвящена тому, что бизнес-аналитик здесь формулирует, оформляет, специфицирует требования и, возможно, моделирует их в графической форме.

Задача 7.2 – очень важная («Верификация требований»). В рамках этой задачи мы проверяем требования на корректность, на то, что она правильно удовлетворяет нашим критериям качества. При этом мы должны понимать, что является с нашей точки зрения качественным требованием. Мы должны составить свой чек-лист, чтобы удостовериться – требование является лаконичным, оно сформулировано по шаблону, оно использует необходимые ключевые слова и т.д.

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

Следующая задача 7.4 «Определение архитектуры требований». Здесь вопрос заключается не в структурировании требований, их упорядочении в пространстве и времени. Вопрос состоит в том, что именно эта совокупность требований, которую мы выявили в ходе работ по бизнес-анализу, полно описывает то, что нам необходимо и достаточно. Нужно, чтобы требования были выстроены таким образом, чтобы каждая заинтересованная сторона видела свои требования с тем уровнем детализации и в той форме, которая ей необходима.

Интересный пункт 7.5 «Определение вариантов дизайна». Я уже говорил о том, что от потребности до решения проходит два как минимум два шага: требования и дизайн решений. Здесь мы определяем варианты дизайна, потому что одно и то же требование можно воплотить по-разному, возможно несколько вариантов того, какое будет решение.

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

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

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

Всего доброго, успехов в обучении!