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

Записаться

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

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

Давайте посмотрим, в чем состоит задача 7.1 Специфицирование и моделирование требований.

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

Давайте посмотрим, что же указано в окружении данной задачи. Итак, задача 7.1 Специфицирование и моделирование требований. Задачи 4.2 и 4.3 – результаты выявления в любом статусе – поступают на вход.

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

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

Какие еще можно выделить нотации? Например, idef0, или uml-нотация, там достаточно много диаграмм, или PC.

Многие аналитики, к сожалению, до сих пор не в курсе, что помимо выбора нотации еще необходимо определиться со стандартом моделирования. На практике это означает, что необходимо разработать некий свод правил по тому, как вы в своей организации или в конкретном проекте будете эту нотацию использовать. Например, дорожки в BPMN – это роль, или это должность, или это название отдела, или это название департамента? Что собой символизирует дорожка? Или, например, эксклюзивный шлюз вы будете использовать с маркером или без маркера? Вы будете использовать шлюз или можете использовать поток управления?

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

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

Какие инструменты моделирования приходят на ум? Если крупные системы, то это Aris. Большинство просто рисует в Visio… Инструмент моделирования может быть с локальной установкой или с облачным размещением. Выбор инструмента моделирования важен, поскольку зачастую инструмент моделирования накладывает свои ограничения.

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

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

Помимо того что мы выбрали инструменты, нотацию и стандарты моделирования, нам необходимо еще управлять жизненным циклом требований. Есть такие специальные инструменты, называются «системы управления требованиями», они управляют каждым требованием на протяжении всего жизненного цикла: выявили требование, специфицировали, верифицировали, валидировали, согласовали, утвердили. Когда требований немного, в качестве инструментов управления жизненным циклом требований годятся и Excel с Word, чем большинство и ограничивается. Сейчас модно для этих целей использовать Jira, хотя Jira – это система управления задачами, а не система управления требованиями, но тем не менее там управляются и с задачами, и с требованиями. Но, когда встает вопрос систематического управления требованиями и их повторного возможного использования, необходим выбор специализированных инструментов управления требованиями в разном виде, чтобы можно было требования, например, в формате пользовательской истории хранить, в формате вариантов использования, в текстовом варианте, генерировать оттуда спецификации.

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

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

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

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

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

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

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

Особенностью задачи 7.1 является очень большой перечень методов бизнес-анализа, которые стандарт или свод знаний по бизнес-анализу рекомендует использовать. Я не буду сейчас подробно останавливаться на каждом методе, это займет очень много времени, но на что я могу обратить внимание? Здесь есть методы, которые явно связаны с каким-то типом требований, вернее – со способом формулировки требований. Например, если вы хотите формулировать требования в формате пользовательских историй, по-английски user stories, у вас есть метод, который называется «пользовательские истории». Пожалуйста, воспользуйтесь им. Если ваша методология использует унифицированный язык моделирования, вы выбрали в качестве подхода варианты использования и сценарии, тогда пожалуйста, – use cases, варианты использования и сценарии. Можете смоделировать диаграмму состояний, если у вас есть объект, который вы описываете, и он может принимать различное состояние. В качестве примера возьмем телефон. Он может находиться в каком-то одном из нескольких состояний – ожидания или когда вы по нему звоните, или когда вам звонят, или в режиме набора номера и так далее. В принципе в любом объекте можно выделить перечень состояний и описать правила перехода из одного состояния в другое.

Моделирование процессов, прототипирование – вот эти все техники или методы моделирования широко используются при выполнении задачи 7.1 Специфицирование и моделирование требований.

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

На этом по задаче 7.1 Специфицирование и моделирование требований все, я с вами прощаюсь, всего доброго, до свидания.