Проведение бизнес анализа для создания системы “Управление школой”

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

Данная статья описывает один из вариантов проведения бизнес анализа для проектирования и разработки системы управления школьным образованием. Материал публикуется в учебных целях, для начинающих бизнес аналитиков и консультантов, вовлеченных в процесс создания и доработок ИТ продуктов.

Шаг 1. Домашнее задание

Надеюсь, что предметная область “Школьное образование” достаточно хорошо знакома читателям, поэтому время на погружение в домен тратить не нужно, хотя именно с этого следует начать в случае, если аналитик не знаком с областью, в которой предполагается создавать или улучшать систему. Момент ключевой и отметим его сейчас просто как хорошее правило для аналитика – выполнить свое домашнее задание и изучить область, если она незнакома. Заказчик не должен тратить свое время на обучение специалиста по бизнес анализу. Хороший специалист сделает это сам.

Итак, правило для хорошего аналитика:

(!) Выполните свое домашнее задание. Изучите домен Заказчика.

На данном этапе можно (и нужно) выполнить такие действия:

  1. Изучить предметную область, ее термины и типовые процессы.
  2. Изучить решения конкурентов, сделать сравнительную таблицу возможностей
  3. Предположить самому, какие задачи потребуется решить
  4. Подготовиться к встрече по выяснению требований

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

  1. Решение будет разрабатываться для одного Заказчика или предполагается, что оно должно быть типовым и в будущем будет предлагаться и другим клиентам. Если это так, то требования к анализу следует повысить, так как такая система должна быть более гибкой и настраиваемой.
  2. Сколько человек будет вообще работать с таким продуктом? Порядок цифр лучше понимать сразу, чтобы определить для себя уровень значимости системы (и стоимость ошибок аналитика 🙂 )

Шаг 1. Выявление бизнес требований

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

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

Тут аналитику пригодится знание такой области знаний как Стратегический анализ, который детально описан в BABOK 3.0, который собственно и пришел на смену стандарту 2.0, и одна из причин – более детальная проработка именно области стратегического анализа.

Итого, следующий совет для хорошего аналитика:

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

Для упрощения начального понимания, можно использовать технику Mind Map и сделать модель, в которой описать тезисы из проведенного стратегического анализа, и потом уже более детальные требования к решению. Модель Mind Map хороша тем, что позволяет легко следовать базовой логике – вначале выяснить бизнес требования, потом детальные требования к решению и только потом думать про возможную архитектуру системы. Модель конечно же на верхнем уровне можно использовать потом и для других проектов. Вот начальный вариант карты:

Global MM

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

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

Strategy Analysis

 

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

Контекст

Шаг 2. Выявление требований пользователей

В классике бизнес анализа и сбора требований пользователей, которая замечательно расписана как в BABOK 3.0 так и работах таких аналитиков, как Карл Вигерс (“Разработка требований к ПО“) можно получить много информации и советов, но пару замечаний из собственной практики я себе все же позволю:

  1. Не рассчитывайте на то, что заинтересованные лица расскажут Вам все пожелания к системе, и вам останется только задокументировать их письменно. В реальной жизни Заказчик предоставит нам список проблем, пожеланий, предложений. Это будет информация, которую аналитик должен конкретизировать, переосмыслить и привести к единому виду, упорядочить и задокументировать.
  2. Подвергайте внутреннему сомнению требования Заказчиков, докопайтесь до истиной причины каждого требования, проверьте, насколько это поможет решить проблемы, собранные на этапе стратегического анализа. то поможет отфильтровать ненужные требования и уменьшить скоп работ.
  3. Пишите просто, на языке Заказчика, но избегая сленга. Специальные термины затем необходимо собрать в одну таблицу, это позволит коллегам в будущем понимать ваши документы. Заказчик должен читать ваши документы, ему должно быть понятно. Задача аналитика в том, чтобы написать требования так, чтобы они были понятны и Заказчику и Разработчикам одновременно.
  4. Помните, требования не должны содержать решения. Решение предоставит архитектор, нужно дать ему свободу для маневра. Требование “Предоставить ученикам личный сайт для просмотра учебных материалов” диктует определенное архитектурное решение. Возможно, разработчик решит использовать просто веб страницу, или отдельное приложение. Требование “Предоставить ученику сервис в виде личного кабинета для доступа к учебным материалам”  даст большую свободу системному архитектору.
  5. Выявляйте, думайте, слушайте и сами предлагайте решения, обсуждайте это с Заказчиком. Проявляйте фантазию. Помните, аналитик – немножко изобретатель, ведь мы предлагаем то, чего еще нет. Такая часть нашего мышления крайне важна. Но вовремя умейте и остановиться, выбрав только главное и приоритетное. Скоп нужно держать.

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

Bus Analysis

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

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

User Req

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

Больше рисуйте. Заказчики в основном визуалы. Читать списки и документы, особенно на начальных этапах анализа никто не любит. Изучите UML, это не так сложно как кажется.

Диаграмма сценариев использования системы может выглядеть примерно так:

Learning.Use Cases

 

Шаг 3. Разработка функциональных и нефункциональных требований к ПО

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

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

ИтогИтогоMindMap.Learning.FR2

 

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

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

Статья в работе. Продолжение следует…

В следующих разделах (информация в процессе подготовки и редактирования):

Шаг 4. Дизайн системы

  • Модель сущностей

Итак, модель сущностей. Зачем она бизнес аналитикуи какую роль играет этот артефакт для учасников проекта? Зачем навыки моделирования и в частности навыки построения ERD модели являются обязательными при публикации вакансий?

Мои комментарии следующие:

  1. Аналитик обязан понимать предменую область, с которой он работает;
  2. Аналитик является связующим звеном между разработчиками и Заказчиком, модель сущностей дает разработчикам очень четкое понимание о рамках и структуре информации, которая должна храниться и обрабатываться в будущей системе.
  3. Диаграмма сущностей – самый быстрый способ понять назначение и рамки системы.
  4. Диаграмма сущностей показывает не только возможности системы, но  и ее ограничения, что также очень важно для понимания и оценки новых требований.

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

Итак, как же выглядит диаграмма сущностей для конкретной ситемы “Управление школой”? В рамках озвученных потребностей пример такой диаграммы показан на рисунке ниже:

ERD

  • Прототипы пользовательского интерфейса
  • Модели бизнес процессов
  • Модель артефактов

Шаг 5. Оценка, приоретизация и прочие атрибуты качественных требований

Шаг 6. Управление требованиями

  • Использование инструмента Excel
  • Использование системы управления требованиями Microsoft Team Foundation Services

Для демонстрации текущего кейса, для читателей создан бесплатный ресурс по адресу: https://almdemoua.visualstudio.com/

Ссылка для получения доступа: заполните свой e-mail 

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

TFS Learning 01

Шаг 7. Внедрение и поддержка системы

 

Advertisements