Системный аналитик. Краткий гайд по профессии. Часть 2
Данный текст является обзорной статьей и преимущественно ориентирован на новичков в IT-индустрии, предназначен для желающих познакомиться с профессией, узнать о ее содержании, основных принципах, практиках и инструментах, используемых в ней.
Из этой статьи вы узнаете какие бывают требования к создаваемым системам и как их собирать, познакомитесь с основными методами их сбора, а также со способами и инструментами их документирования.
Что такое требования и какие они бывают.
Из первой части статьи вы узнали об основах сетевых взаимодействий, основном протоколе и формате обмена данными в сетях, познакомились с устройством простейших приложений и рассмотрели пример построения архитектуры сложного приложения в виде распределенной системы.
Для того, чтобы спроектировать любую систему прежде всего необходимо понять чего хочет бизнес-заказчик и описать требования на разработку.
Выделяют три уровня требований:
Бизнес-требования. Обычно это описание целей, задач и желаемых для заказчика результатов.
Пользовательские требования. Это потребности пользователей и других заинтересованных сторон, которые нужно удовлетворить, чтобы выполнить бизнес-требования.
Функциональные требования, которые определяют конкретные функции, которые система должна осуществлять. Функциональные требования обычно выражаются в виде списка конкретных задач, которые система должна выполнить.
Также выделяют такой тип требований как нефункциональные.
Нефункциональные требования описывают то, каким образом система должна работать и могут включать характеристики системы, которые не связаны непосредственно с ее функциональностью: производительность, безопасность, масштабируемость, удобство использования и т.д., зачастую выражаясь в виде ограничений или критериев качества.
На изображении ниже приведен пример оформления требований на разработку.
Пример описания требований в общем виде
В зависимости от подходов, принятых в команде, требования на разработку состоят из изложения всех перечисленных видов требований, а также могут включать в себя описание API, различные схемы и диаграммы, ссылки на стандарты, документацию смежных систем и иные артефакты.
Спецификация требований может быть представлена в виде документа (например в формате .doc или .pdf) или оформлена в wiki-системах, например в Confluence. Шаблон оформления зависит от команды и принятых в ней правил.
Реализация функциональных требований обеспечивает соответствие системы бизнес-потребностям, а нефункциональных — ее надежность, эффективность и удобство использования.
Важно качественно описывать все требования, потому что стоимость внесения изменений в программное обеспечение или устранения дефектов увеличивается пропорционально этапу, на котором вносятся изменения или исправления.
Этапы разработки программного обеспечения
Анализ и формирование требований. Сбор бизнес-требований и подготовка пользовательских требований.
Этап проектирования. Определение архитектуры приложения, подготовка функциональных и нефункциональных требований.
Разработка. Написание кода.
Тестирование ПО на соответствие требованиям к нему.
Приёмка результатов (приемо-сдаточные испытания). Демонстрация результатов бизнес-заказчику, проверка на соответствие пользовательским и бизнес-требованиям.
Эксплуатация и сопровождение. Установка ПО, обучение пользователей (при необходимости), поддержка работы ПО командой сопровождения.
В зависимости от обстоятельств и используемой в команде методологии разработки ее этапы могут гибко изменять свою последовательность и содержание, но в общем случае цикл разработки именно такой, как описано выше.
Более подробно методологии разработки будут рассмотрены в следующих частях статьи.
Как собирать требования?
Процесс сбора требований — итеративный процесс, который может неоднократно повторяться, особенно, если вы работаете в гибких методологиях типа Scrum.
Процесс сбора требований
Понимание бизнес-целей. Прежде всего, необходимо понять бизнес-цели и задачи, которые должна решать система. Это поможет определить, какие функции и возможности должны быть включены в систему, а также продумать верхнеуровневую реализацию (high-level design — HLD) разрабатываемой системы, выбрать архитектурный стиль и типы интеграционных взаимодействий в случае необходимости.
Зачастую для этого аналитику необходимо изучить домен, для которого вы разрабатываете решение. Подход, который позволяет значительно ускорить процесс проектирования системы в незнакомой предметной области называется Domain-driven-design (DDD).
Подход DDD заключается в том, чтобы представить предметную область (домен) в виде набора ограниченных контекстов (bounded context), каждый из которых содержит набор сущностей и связей между ними. Внутри одного контекста все сущности должны иметь одинаковую интерпретацию.
С точки зрения проектирования архитектуры каждый контекст можно рассматривать как отдельный микросервис, реализующий строго определенную функциональность и взаимодействующий с другими микросервисами. Подробная информация о микросервисной архитектуре будет приведена в следующих частях статьи.
При разработке в целях реализации концепции DDD используются принципы объектно-ориентированного программирования для представления содержимого контекста в виде классов и их атрибутов и методов.
Опрос стейкхолдеров (заказчиков). Это включает в себя их интервьюирование и анализ потребностей. На основе полученной информации системный аналитик формулирует требования к системе.
Требования должны быть как можно более подробными и исключать наличие двусмысленных трактовок.Документирование требований. После формулирования требований системный аналитик документирует их в виде спецификации.
Спецификация должна содержать все необходимые детали и быть понятной для всех заинтересованных сторон.Обсуждение требований. После составления требования обсуждаются с заинтересованными сторонами, включая разработчиков, тестировщиков и всех членов команды.
В случае работы по scrum это, как правило, происходит на одной из командных церемоний по уточнению задач (PBR — product backlog refinement, grooming).Цель обсуждения — убедиться, что все требования понятны и реализуемы. На этом этапе прорабатывается solution (детальная) архитектура будущей системы, после чего требования необходимо согласовать со стейкхолдерами (а зачастую еще и со специалистами по информационной безопасности, архитектором и командой сопровождения).
Уточнение и корректировка требований: В процессе разработки системы могут возникать новые требования или изменения в уже существующих требованиях.
Системный аналитик должен быть готов к уточнению и корректировке требований в соответствии с изменениями, а также с оповещением об этом всех заинтересованных сторон и повторным согласованием с ними.Разработка, тестирование и приемо-сдаточные испытания. В процессе разработки аналитик помогает разработчикам ориентироваться в домене и описанных им требованиях. При выявлении недостаточности требований для реализации функциональности, выявленные гэпы (пробелы) отправляются аналитику на уточнение и корректировку требований.
После завершения разработки системы, аналитик участвует (опционально) в тестировании системы, чтобы убедиться, что она соответствует всем требованиям и функционал корректно работает.
Чем более детальными будут требования, тем проще разработчикам будет писать код, а тестировщикам писать тест-кейсы.
Однако важно соблюдать баланс между избыточным (когда требования излишне детализированы) и недостаточным описанием (когда могут быть упущены требования, критичные для реализации функциональности).
Методы сбора требований
Существует несколько методов сбора требований, но подробно хочу остановиться на самых актуальных и наиболее используемых в реальной жизни.
Интервью. Самый очевидный и эффективный способ. Помогает быстро понять потребности заказчиков/пользователей и подготовить предварительные требования для дальнейшего обсуждения.
Интервью проще проводить в формате «один на один», особенно, если наладить доверительные отношения с интервьюируемыми, так как люди легче делятся своими мыслями в таком формате, чем в небольшой группе.
Как проводить интервью
Подготовьте вопросы, которые планируете задавать на интервью, таким образом вы создадите точку, от которой можно оттолкнуться в диалоге.
В начале интервью поприветствуйте участников и представьтесь, напомните о целях интервью, и изложите его план. Таким образом вы установите с ними контакт.
В процессе беседы следите за тем, чтобы она не отдалялась от целей интервью и не переходила к обсуждению деталей, слабо относящихся к теме беседы.
Один из самых важных навыков аналитика — умение внимательно слушать собеседника. Не стесняйтесь переспрашивать, если что-то вам не ясно, но не перебивайте, дайте собеседнику завершить свою мысль. Чтобы показать свое понимание, можете попытаться перефразировать основную идею рассказчика — таким образом вы поможете ему более точно сформулировать идею.
Не стесняйтесь предлагать свои идеи по ходу интервью.
Фиксируйте темы для дальнейшего обсуждения.
Не увеличивайте размер команды, приглашенной на интервью и старайтесь ограничивать время, отведенное на обсуждение каждого из вопросов, заранее это проговаривая.
Анкетирование. Подходит для сбора информации от широкого круга заинтересованных лиц. Результаты анкетирования можно использовать как основу для подготовки требований с использованием других методов сбора требований, например интервью.
В процессе анкетирования важно правильно построить вопросы в анкете.
Как подготовить анкету
Вопросы должны иметь однозначную интерпретацию и не допускать двусмысленных трактовок.
Варианты ответов должны быть взаимоисключающими и исчерпывающими (содержащими все возможные непересекающиеся варианты).
Старайтесь использовать «закрытые» вопросы с ограниченным количеством ответов.
Не «раздувайте» объем анкеты.
Анализ документов. Хороший способ разобраться в новом домене — изучить документацию к системам, находящимся в нем, а также ознакомиться со стандартами. Важно отметить, что есть риск наткнуться на устаревшую документацию.
Результаты можно использовать для подготовки к интервью или анкетированию.Анализ систем. Незаменимый способ разобраться с окружением, в котором находится исследуемая система. Для каждой смежной системы необходимо выявить функциональность, которая может создавать требования к вашей системе.
Эти требования должны описывать, какие данные передавать или получать из другой системы и правила работы с этими данными в рамках той или иной функциональности (функциональность может быть как действующей — ее надо учесть, чтобы не «сломать», так и планируемой к реализации).
Документирование требований.
Описание API
UML-диаграммы.
UML (Unified Modeling Language — унифицированный язык моделирования) это язык графического описания для объектного моделирования в области разработки программного обеспечения. Его также используют для моделирования бизнес-процессов, системного моделирования и отображения организационных структур.
Типы UML-диаграмм
Все UML диаграммы по своей сущности делятся на два вида:
Структурные диаграммы — описывают структуру сложных объектов и систем, показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь.
Диаграммы поведения — иллюстрируют взаимодействие с системой и процесс её работы.
Для составления UML диаграмм наиболее удобно использовать специальный инструмент — PlantUML. По ссылке доступно подробное описание с примерами создания каждой диаграммы.
Ниже речь пойдет только о диаграммах, используемых, на мой взгляд, в 90% случаев при проектировании систем. Основываясь на моем опыте, скажу, что команде разработки было достаточно этих схем (зачастую даже не всех, а только нескольких из них, например ER-diagram, State и Sequence), чтобы наглядно воспринимать планируемую к реализации функциональность.
Описание пользовательских историй (UML Use Cases)
Пример Use case diagram
Диаграмма сценариев использования (Use Case) является частью диаграммы прецедентов и представляет детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты, отталкиваясь от понятия User Story — пользовательской истории.
User Story — краткое описание того, что хочет достичь пользователь, используя систему.
Они обычно начинаются со слов «я, как пользователь, хочу…» или «мне, как заказчику, необходимо…», и далее следует описание того, что пользователь хочет сделать. User Story сосредоточены на том, что пользователь хочет, а не на том, как это реализовать.
На диаграмме участники процесса обозначаются специальными знаками в виде человечков с подписью, обозначающей группу, к которой они относятся.
Каждая функция системы изображается в виде эллипса, внутри которого записывается ее название. Этот эллипс и является Use Case’ом.
Для обозначения связей между элементами используются линии, называемые отношениями.
Выделяют несколько типов отношений:
отношение ассоциации — обозначается обычной стрелкой, показывает, что два или более вариантов использования связаны друг с другом. Стоит отметить, что эта связь не отображает направление или порядок взаимодействия.
отношение включения — обозначается пунктирной стрелкой с надписью «include», показывает, что один вариант использования включает другой вариант использования, являющийся его частью.
отношение расширения — обозначается пунктирной стрелкой с надписью «extends», показывает, что основной вариант взаимодействия может расширен дополнительными функциями.
отношения обобщения — обозначается стрелкой с закрашенным или прозрачным треугольником на конце, показывает, что конкретный вариант использования наследует поведение от общего варианта.
Также Use Case можно описывать в текстовом виде, как показано на изображении ниже.
Текстовое описание Use Case’а
В текстовом описании указывается:
название кейса;
участники (группы участников);
предусловие — в каком состоянии должны находиться участники, перед выполнением кейса;
триггер — то, что запускает выполнение кейса;
результат успешного выполнения кейса;
основной сценарий — то, что должно произойти в процессе выполнения кейса;
альтернативные сценарии — то, что может произойти в ходе выполнениякейса, если не будет достигнут его результат.
Диаграмма последовательности (UML Sequence-diagram)
Называемая в народе «сиквенс» диаграмма изображает последовательные во времени действия, которые называют сценариями.
Пример Sequence-diagram
Дабы не плодить одинаковый материал здесь будет ссылка на замечательную статью с Хабра, в которой коллега по цеху рассказывает из чего состоит диаграмма последовательности и приводит наглядные примеры.
Для тех, кому лень переходить по ссылкам, изложу кратко здесь — диаграмма последовательности состоит из объектов, линий жизни и сообщений.
Объекты это взаимодействующие друг с другом сущности разного типа. Например, пользователь, микросервис, база данных и т.д. Каждый объект на схеме должен иметь название.
Линии жизни это вертикальная линия, отображающая исполнение функций объекта.
Сообщения показывают направление информационного обмена между объектами и их содержание: запрос или ответ, вызов хранимой процедуры или отправка сообщения. Сообщения отображаются в виде стрелок, направленных от одной линии жизни к другой, и имеют несколько типов.
Одним из важных понятий являются группировки сообщений, накладывающие определенные правила взаимодействия. Их существует несколько типов:
Alt — группировка для демонстрации альтернативных кейсов взаимодействия.
Opt — группировка для демонстрации опционального (необязательного) кейса взаимодействия.
Par — группировка для демонстрации параллельно выполняемых кейсов взаимодействия.
Loop — группировка для демонстрации циклов с условием.
Group — группировка сообщений по смыслу.
Диаграмма состояний (UML State diagram)
Отображает состояния объекта и связи между ними.
Состоит из: начального/конечного состояния, обозначаемого кругом, промежуточных состояний, обозначаемых прямоугольником, переходов, обозначаемых стрелками.
Диаграмма классов (UML Class diagram)
Отображает структуру системы, содержащей различные объекты и классы.
Чаще всего используется, чтобы спроектировать систему, реализованную на принципах объектно-ориентированного подхода, при котором вся программа рассматривается как набор взаимодействующих друг с другом объектов (классов) и продемонстрировать иерархию классов внутри программы.
На изображении ниже представлены упрощенные примеры диаграммы классов и состояний.
Class diagram и State diagram
Описание структуры данных (ER-diagram)
Схема «сущность-связь» (также ERD или ER-диаграмма) — это разновидность блок-схемы, где показано, как разные «сущности» связаны между собой внутри системы. ER-диаграммы чаще всего применяются для проектирования реляционных баз данных.
Выделяют три уровня ER-моделей: концептуальный, логический, физический.
Концептуальная ER-модель — это высокоуровневое представление сущностей. Она содержит наименьшее количество деталей и отражает общий объём модели, то есть количество сущностей и связей в ней.
Логическая ER-модель — это описание важных для предметной области сущностей, их атрибутов и связей между ними.
Физическая ER-модель — это описание того, как логическая ER-модель может быть разработана с помощью определённой технологии (СУБД).
Существует две нотации ERD: нотация Питера-Чена и нотация Crow’s Foot. Наиболее популярной и используемой из них является последняя, поэтому она и будет рассмотрена далее.
На изображении ниже показан пример логической модели ER-диаграммы в нотации Crow’s Foot (она же известна, как «Воронья лапка»).
Логическая модель ER-диаграммы
Основные положения нотации:
Сущности изображаются в виде прямоугольников с названием.
Сущность в базе данных может рассматриваться как таблица.Атрибуты сущности перечисляются в нижней части прямоугольника. Первичный ключ выделяется звездочкой.
Атрибуты сущностей в базе данных должны рассматриваться как поля таблицы. Для каждого поля нужно определить:Имя на английском языке.
Тип данных и размерность.
Допустимость пустых значений.
Значение по умолчанию (если требуется).
Правила валидации значений (если требуется).
Связи между таблицами отражаются через внешний ключ.
Связь между сущностями изображается линией.
У связи в нотации Crow'«s Foot есть две характеристики — модальность и кардинальность.Модальность показывает какое минимальное количество связей должно быть у такой сущности (ноль или минимум одна).
Обязательная связь (минимум одна) обозначается вертикальной чертой.
Опциональная связь (может быть ноль) обозначается кругом.Кардинальность показывает какое максимальное количество связей может быть между экземплярами разных сущностей (одна или много).
Если максимальное количество связей — одна, то кардинальность обозначается вертикальной чертой.
Если связей может быть несколько, то кардинальность обозначается как та самая «воронья лапка».Обозначения характеристик связи располагаются на линии именно в таком порядке: сначала модальность (минимум), потом кардинальность (максимум).
Логическую ER-модель можно перевести в физическую за пять шагов. Для этого нужно:
Преобразовать сущности в таблицы.
Преобразовать атрибуты в поля с указанием типов и ограничений.
Добавить первичные ключи.
Добавить внешние ключи.
Добавить системные таблицы и поля.
Физическая модель ER-диаграммы
Описание бизнес-процесса (BPMN)
BPMN — это нотация для моделирования и описания бизнес-процессов.
Чтобы попрактиковаться в составлении диаграмм есть хороший бесплатный инструмент bpmn.io в открытом доступе.
Пример BPMN-диаграммы
И снова оставлю ссылку на прекрасную статью с Хабра, в которой рассказано о BPMN-диаграммах с наглядными иллюстрациями.
Если кратко — BPMN диаграмма состоит из следующих основных артефактов:
Дорожки — необязательные элементы, используемые для объединения объектов в рамках одной функциональности/роли (обычно используют для наглядности отображения взаимодействий между смежными системами/ролями).
Действия (задачи) используются для отображения выполняемых процессов/подпроцессов.
Шлюзы — элементы, используемые для введения в процесс развилок, условий или дополнительной логики. Чаще всего используются три типа шлюзов: «исключающее ИЛИ», «И» и «включающее ИЛИ».
Потоки — стрелки, отображающие последовательность действий.
В этой статье вы узнали о типах требований и рассмотрели пример их оформления, познакомились с основными методами их сбора, рассмотрели основные типы диаграмм и инструменты, используемые при документировании требований.
В следующих частях будут рассмотрены типы программной архитектуры и интеграций, архитектурные паттерны, методологии разработки и многое другое, что поможет получить более полное представление о профессии системного аналитика.
Эту и другие статьи по системной аналитике и IT-архитектуре, вы сможете найти в моем небольшом уютном Telegram-канале: Записки системного аналитика
