usecase.ru – вариант использования

В статьях Проектирование бизнес-приложения: Анализ и Проектирование бизнес-приложения: Анализ 2 я показал подход к возможному способу анализа функциональности системы. Теперь следует более подробно осветить этот процесс на основе примера.

Возьмем для примера интернет-магазин по продаже книг для небольшого издательства.

От заказчика (коммерческого директора Василия) поступило следующее письмо:

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

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

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

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

Рассмотрим работу самой главной роли на этапе анализа – работу аналитика.

Первоначально аналитик должен определить заказчика проекта (в нашем случае это коммерческий директор Василий). Далее определяется рабочая группа со стороны заказчика, в которую должны входить ключевые заинтересованные лица: сам коммерческий директор Василий, начальник отдела розничных продаж Светлана, начальник отдела доставки Максим, начальник склада Роман.

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

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

В результате наших первых встреч с рабочей группой был получен документ по следующему шаблону: Шаблон документа-концепции

После согласования первой версии документа необходимо по полученным высокоуровневым параметрам системы подобрать бесплатные или коммерческие аналоги системы. Если аналог найден, то задача в некоторой степени упрощается – далее будет производиться внедрение системы и ее настройка под требования заказчика. Если удовлетворяющего аналога нет или стоимость и/или трудоемкость внедрения превысит стоимость и трудоемкость разработки своими силами, то принимается решение о разработке новой системы или отказ от системы вообще.