Артефакты аналитика: документы и техники

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

5 главных документов аналитика

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

• Документ бизнес-требований (BRD, Business Requirements Document);
• ТЭО (Технико-Экономическое обоснование, бизнес-кейс);
• Спецификация требований к решению (ТЗ, Техническое задание);
• Проект решения;
• Программа и методика испытаний (ПМИ).

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

Основы бизнес-анализа: вход в профессию для начинающих

Код курса

INTRO

Ближайшая дата курса

2 июня, 2025

Продолжительность

24 ак.часов

Стоимость обучения

54 000 руб.

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

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

Обычно BRD (Business Requirements Document) разрабатывает бизнес-аналитик, а основными потребителями изложенной в нем информации являются Заказчик, Менеджер проекта и Системный аналитик. Этот документ создается в самом начале любого проекта или даже на стадии предпроектного обследования (discovery) и содержит как минимум следующие пункты:

• Краткое описание проекта;
• Цели проекта;
• Бизнес-контекст текущей ситуации (as is);
• Вернеуровневое видение желаемой ситуации (as to be), включая видение решения;
• Границы и содержание проекта (scope);
• Бизнес-требования;
• Ключевые стейкхолдеры;
• Главные требования стейкхолдеров;
• Ограничения проекта.

При разработке документа пригодятся следующие техники бизнес-анализа:

• BACCM (Business Analysis Core Concept Model) – модель базовых понятий бизнес-анализа, которая позволяет определить границы и содержание проекта, ответив ответы на 6 вопросов: что включает Изменение, какова Потребность, какое будет Решение, кто Стейкхолдеры, какова ожидаемая Ценность, каков Контекст.
• Канва бизнес-модели и цепочка создания ценности;
• CATWOE;
• Анализ стейкхолдеров;
• Бенчмаркинг и анализ рынка;
• Причинно-следственный анализ (диаграмма Исикавы, метод 5Why);
• Нотации моделирования бизнес-процессов (IDEF0, BPMN, EPC);
• Анализ бизнес-правил, в т.ч. DMN-модели.

Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)

Код курса

MODP

Ближайшая дата курса

7 апреля, 2025

Продолжительность

10 ак.часов

Стоимость обучения

22 000 руб.

Технико-экономическое обоснование (ТЭО)

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

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

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

• Бизнес-кейс;
• Финансовый анализ;
• SWOT-анализ;
• Анализ решений;
• Анализ рисков.

Основы бизнес-анализа: вход в профессию для начинающих

Код курса

INTRO

Ближайшая дата курса

2 июня, 2025

Продолжительность

24 ак.часов

Стоимость обучения

54 000 руб.

Спецификация требований или техническое задание (ТЗ)

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

Разработку технического задания можно начать после одобрения документа бизнес-требований и ТЭО. Точный состав спецификации требований регламентируется стандартом, которому она должна соответствовать, например, ГОСТ 34.602-2020, ГОСТ 19781-90, SRS по IEEE 830-1998, ISO IEEE 29148-2011 или внутренний шаблон ТЗ. В любом случае, этот документ должен включать следующие разделы:

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

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

• пользовательские требования в форме User Story или Use Case с критериями приемки (Acceptance Criteria);
• нотации моделирования бизнес-процессов (IDEF0, BPMN, EPC);
• CRUDL-матрица.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

TTIS

Ближайшая дата курса

12 мая, 2025

Продолжительность

22 ак.часов

Стоимость обучения

48 000 руб.

Проект решения

Как я недавно отмечала здесь, одних только требований, упакованных в полное и консистентное ТЗ, недостаточно для реалиазации. Необходимо материализованное представление дизайна решения, которое будет удовлетворять этим требованиям. Проект должен описывать компоненты логической и физической архитектуры решения, включая рекомендуемый стек технологий. Обычно такой документ составляет Архитектор или Системный аналитик, обладающий необходимыми для этого компетенциями. Именно проект решения лежит в основе постановок задач на реализацию, т.е. потребителями информации, изложенной в этом документе являются Разработчик и Тестировщик. Причем роль Разработчик относится не только к программисту, но и к UI/UX-дизайнеру.

Разработать проект решения можно после после одобрения ТЗ, отразив точки зрения на архитектуру решения, указанные в ГОСТ Р 57193-2016, SEBoK, ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011. Для этого документ должен как минимум содержать следующие пункты:

• контекст проектируемой ИС;
• архитектурная категория;
• структура элементов системы;
• взаимодействие элементов архитектуры между собой и реакции в ответ на внешние события;
• протоколы сетевого и межсистемного взаимодействия, в т.ч. по веб-API;
• форматы и схемы данных;
• стек технологий;
• физические схемы моделей баз данных для выбранных СУБД;
• ограничения и подходящие конфигурации настройки компонентов системы;
• порядок реализации спроектированной архитектуры, основанный на технических зависимостях одних компонентов от других.

При разработке проекта решения пригодятся следующие техники:

• Прототипирование;
• UML-диаграммы и схемы С4;
• Документирование структуры данных и системных вызовов, например, в виде спецификации OpenAPI для REST API или AsyncAPI для асинхронной интеграции.

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

Основы архитектуры и интеграции информационных систем

Код курса

OAIS

Ближайшая дата курса

26 мая, 2025

Продолжительность

22 ак.часов

Стоимость обучения

48 000 руб.

Программа и методика испытаний (ПМИ)

Этот документ содержит одну или несколько методик испытаний объекта поставки, включая перечень проверок и допустимых результатов, чтобы показать, насколько результат отвечает требованиям ТЗ. Обычно ПМИ совместно разрабатывается бизнес-аналитиком и системным аналитиком, если эти роли разделены между разными людьми. Потребителями изложенной в ПМИ информации являются Заказчик, Менеджер проекта и Тестировщик. Очень важно, чтобы ПМИ была согласована с представителем Заказчика, который отвечает за приемку, чтобы во время приемочных испытаний не возникло желания проверить работу решения в ранее неизвестных условиях, т.к. подобный тест не пройдет в 99% случаях .

Составление ПМИ можно начать после одобрения ТЗ и дополнять его по мере выполнения модульного, интеграционного и нагрузочного тестирования. Помимо проверки соответствия реализованной информационной системы функциональным и нефункциональным требованиям, изложенным в ТЗ, также проверяется комплектность и качество документации.

По ГОСТ Р 59795-2021 состав ПМИ для автоматизированной системы включает следующие пункты:

• краткое описание объекта испытаний (наименование системы и ее компонентный состав);
• цель испытаний (цели и задачи, которые должны быть достигнуты и решены в процессе испытаний);
• общие положения (регламенты, место и время испытаний; организации, участники, результаты предыдущих испытаний);
• объем испытаний (этапы испытаний и проверок, нормативные количественные и качественные значения показателей, последовательность проведения и режима испытаний, работ по завершении испытаний и порядок их проведения);
• условия и порядок проведения испытаний, включая меры обеспечения безопасности и требования к участникам испытаний;
• материально-техническое обеспечение испытаний, включая задачи и обязанности участников по их поставке и подготовке. Например, для приемочного тестирования ИС в этом пункте может быть указано, на чьей стороне (Заказчика или Исполнителя) разворачивается тестовый стенд и кто отвечает за его работоспособность.
• метрологическое обеспечение испытаний, включая задачи и обязанности участников по их поставке и подготовке. К примеру, для ИС в этом разделе ПМИ можно указать, какой бенчмаркинговый тест будет использоваться для оценки производительности, а также какими инструментами будут логироваться и оцениваться результаты.
• отчетность — список отчетных документов, включая перечисление участников, которые должны их разработать, согласовать и утвердить, а также сроки их оформления. Обычно отчетными документами являются акт и отчет о результатах испытаний, акт технического состояния системы после испытаний.
• приложения – методики испытаний, математические и прочие модели для оценки качества объекта испытаний.

Для разработки такого документа, основанном на ТЗ, пригодятся техники спецификации пользовательских требований в форме User Story или Use Case с критериями приемки (Acceptance Criteria), анализ бизнес-правил и нефункциональных требований. Подробнее про документ ПМИ и виды испытаний автоматизированной системы по ГОСТ читайте в моей новой статье.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

TTIS

Ближайшая дата курса

12 мая, 2025

Продолжительность

22 ак.часов

Стоимость обучения

48 000 руб.

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

А научиться составлять все рассмотренные и другие артефакты, включая полезные техники вам помогут мои курсы в Школе прикладного бизнес-анализа на базе лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

• Основы бизнес-анализа: вход в профессию для начинающих
• Разработка ТЗ на информационную систему
• Основы архитектуры и интеграции информационных систем
• UML для бизнес-аналитика