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

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

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

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

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

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

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

Код курса

INTRO

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

13 января, 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

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

23 декабря, 2024

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

8 ак.часов

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

18 000 руб.

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

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

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

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

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

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

Код курса

INTRO

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

13 января, 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

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

2 декабря, 2024

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

16 ак.часов

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

36 000 руб.

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

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

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

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

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

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

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

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

Код курса

OAIS

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

20 января, 2025

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

16 ак.часов

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

36 000 руб.

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

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

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

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

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

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

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

Код курса

TTIS

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

2 декабря, 2024

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

16 ак.часов

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

36 000 руб.

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

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

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