Данный текст является обзорной статьей и преимущественно ориентирован на новичков в IT-индустрии, предназначен для желающих познакомиться с профессией, узнать о ее содержании, основных принципах, практиках и инструментах, используемых в ней.
-
Системный аналитик. Краткий гайд по профессии. Часть 1. Основы сетевых взаимодействий.
-
Системный аналитик. Краткий гайд по профессии. Часть 2. Сбор, анализ и документирование требований.
Из этой статьи вы узнаете какие бывают требования к создаваемым системам и как их собирать, познакомитесь с основными методами их сбора, а также со способами и инструментами их документирования.
Что такое требования и какие они бывают.
Из первой части статьи вы узнали об основах сетевых взаимодействий, основном протоколе и формате обмена данными в сетях, познакомились с устройством простейших приложений и рассмотрели пример построения архитектуры сложного приложения в виде распределенной системы.
Для того, чтобы спроектировать любую систему прежде всего необходимо понять чего хочет бизнес-заказчик и описать требования на разработку.
Выделяют три уровня требований:
-
Бизнес-требования. Обычно это описание целей, задач и желаемых для заказчика результатов.
-
Пользовательские требования. Это потребности пользователей и других заинтересованных сторон, которые нужно удовлетворить, чтобы выполнить бизнес-требования.
-
Функциональные требования, которые определяют конкретные функции, которые система должна осуществлять. Функциональные требования обычно выражаются в виде списка конкретных задач, которые система должна выполнить.
Также выделяют такой тип требований как нефункциональные.
-
Нефункциональные требования описывают то, каким образом система должна работать и могут включать характеристики системы, которые не связаны непосредственно с ее функциональностью: производительность, безопасность, масштабируемость, удобство использования и т.д., зачастую выражаясь в виде ограничений или критериев качества.
На изображении ниже приведен пример оформления требований на разработку.
В зависимости от подходов, принятых в команде, требования на разработку состоят из изложения всех перечисленных видов требований, а также могут включать в себя описание 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 (детальная) архитектура будущей системы, после чего требования необходимо согласовать со стейкхолдерами (а зачастую еще и со специалистами по информационной безопасности, архитектором и командой сопровождения).
-
Уточнение и корректировка требований: В процессе разработки системы могут возникать новые требования или изменения в уже существующих требованиях.
Системный аналитик должен быть готов к уточнению и корректировке требований в соответствии с изменениями, а также с оповещением об этом всех заинтересованных сторон и повторным согласованием с ними. -
Разработка, тестирование и приемо-сдаточные испытания. В процессе разработки аналитик помогает разработчикам ориентироваться в домене и описанных им требованиях. При выявлении недостаточности требований для реализации функциональности, выявленные гэпы (пробелы) отправляются аналитику на уточнение и корректировку требований.
После завершения разработки системы, аналитик участвует (опционально) в тестировании системы, чтобы убедиться, что она соответствует всем требованиям и функционал корректно работает.
Чем более детальными будут требования, тем проще разработчикам будет писать код, а тестировщикам писать тест-кейсы.
Однако важно соблюдать баланс между избыточным (когда требования излишне детализированы) и недостаточным описанием (когда могут быть упущены требования, критичные для реализации функциональности).
Методы сбора требований
Существует несколько методов сбора требований, но подробно хочу остановиться на самых актуальных и наиболее используемых в реальной жизни.
-
Интервью. Самый очевидный и эффективный способ. Помогает быстро понять потребности заказчиков/пользователей и подготовить предварительные требования для дальнейшего обсуждения.
Интервью проще проводить в формате «один на один», особенно, если наладить доверительные отношения с интервьюируемыми, так как люди легче делятся своими мыслями в таком формате, чем в небольшой группе.
Как подготовиться и провести интервью
-
Подготовьте вопросы, которые планируете задавать на интервью, таким образом вы создадите точку, от которой можно оттолкнуться в диалоге.
-
В начале интервью поприветствуйте участников и представьтесь, напомните о целях интервью, и изложите его план. Таким образом вы установите с ними контакт.
-
В процессе беседы следите за тем, чтобы она не отдалялась от целей интервью и не переходила к обсуждению деталей, слабо относящихся к теме беседы.
-
Один из самых важных навыков аналитика — умение внимательно слушать собеседника. Не стесняйтесь переспрашивать, если что-то вам не ясно, но не перебивайте, дайте собеседнику завершить свою мысль. Чтобы показать свое понимание, можете попытаться перефразировать основную идею рассказчика — таким образом вы поможете ему более точно сформулировать идею.
-
Не стесняйтесь предлагать свои идеи по ходу интервью.
-
Фиксируйте темы для дальнейшего обсуждения.
-
Не увеличивайте размер команды, приглашенной на интервью и старайтесь ограничивать время, отведенное на обсуждение каждого из вопросов, заранее это проговаривая.
-
Анкетирование. Подходит для сбора информации от широкого круга заинтересованных лиц. Результаты анкетирования можно использовать как основу для подготовки требований с использованием других методов сбора требований, например интервью.
В процессе анкетирования важно правильно построить вопросы в анкете.
Как составить анкету
-
Вопросы должны иметь однозначную интерпретацию и не допускать двусмысленных трактовок.
-
Варианты ответов должны быть взаимоисключающими и исчерпывающими (содержащими все возможные непересекающиеся варианты).
-
Старайтесь использовать «закрытые» вопросы с ограниченным количеством ответов.
-
Не «раздувайте» объем анкеты.
-
Анализ документов. Хороший способ разобраться в новом домене — изучить документацию к системам, находящимся в нем, а также ознакомиться со стандартами. Важно отметить, что есть риск наткнуться на устаревшую документацию.
Результаты можно использовать для подготовки к интервью или анкетированию. -
Анализ систем. Незаменимый способ разобраться с окружением, в котором находится исследуемая система. Для каждой смежной системы необходимо выявить функциональность, которая может создавать требования к вашей системе.
Эти требования должны описывать, какие данные передавать или получать из другой системы и правила работы с этими данными в рамках той или иной функциональности (функциональность может быть как действующей — ее надо учесть, чтобы не «сломать», так и планируемой к реализации).
Документирование требований.
UML-диаграммы.
UML (Unified Modeling Language — унифицированный язык моделирования) это язык графического описания для объектного моделирования в области разработки программного обеспечения. Его также используют для моделирования бизнес-процессов, системного моделирования и отображения организационных структур.
Все UML диаграммы по своей сущности делятся на два вида:
-
Структурные диаграммы — описывают структуру сложных объектов и систем, показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь.
-
Диаграммы поведения — иллюстрируют взаимодействие с системой и процесс её работы.
Для составления UML диаграмм наиболее удобно использовать специальный инструмент — PlantUML. По ссылке доступно подробное описание с примерами создания каждой диаграммы.
Ниже речь пойдет только о диаграммах, используемых, на мой взгляд, в 90% случаев при проектировании систем. Основываясь на моем опыте, скажу, что команде разработки было достаточно этих схем (зачастую даже не всех, а только нескольких из них, например ER-diagram, State и Sequence), чтобы наглядно воспринимать планируемую к реализации функциональность.
Описание пользовательских историй (UML Use Cases)
Диаграмма сценариев использования (Use Case) является частью диаграммы прецедентов и представляет детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты, отталкиваясь от понятия User Story — пользовательской истории.
User Story — краткое описание того, что хочет достичь пользователь, используя систему.
Они обычно начинаются со слов «я, как пользователь, хочу…» или «мне, как заказчику, необходимо…», и далее следует описание того, что пользователь хочет сделать. User Story сосредоточены на том, что пользователь хочет, а не на том, как это реализовать.
На диаграмме участники процесса обозначаются специальными знаками в виде человечков с подписью, обозначающей группу, к которой они относятся.
Каждая функция системы изображается в виде эллипса, внутри которого записывается ее название. Этот эллипс и является Use Case’ом.
Для обозначения связей между элементами используются линии, называемые отношениями.
Выделяют несколько типов отношений:
-
отношение ассоциации — обозначается обычной стрелкой, показывает, что два или более вариантов использования связаны друг с другом. Стоит отметить, что эта связь не отображает направление или порядок взаимодействия.
-
отношение включения — обозначается пунктирной стрелкой с надписью «include», показывает, что один вариант использования включает другой вариант использования, являющийся его частью.
-
отношение расширения — обозначается пунктирной стрелкой с надписью «extends», показывает, что основной вариант взаимодействия может расширен дополнительными функциями.
-
отношения обобщения — обозначается стрелкой с закрашенным или прозрачным треугольником на конце, показывает, что конкретный вариант использования наследует поведение от общего варианта.
Также Use Case можно описывать в текстовом виде, как показано на изображении ниже.
В текстовом описании указывается:
-
название кейса;
-
участники (группы участников);
-
предусловие — в каком состоянии должны находиться участники, перед выполнением кейса;
-
триггер — то, что запускает выполнение кейса;
-
результат успешного выполнения кейса;
-
основной сценарий — то, что должно произойти в процессе выполнения кейса;
-
альтернативные сценарии — то, что может произойти в ходе выполнения кейса, если не будет достигнут его результат.
Диаграмма последовательности (UML Sequence-diagram)
Называемая в народе «сиквенс» диаграмма изображает последовательные во времени действия, которые называют сценариями.
Дабы не плодить одинаковый материал здесь будет ссылка на замечательную статью с Хабра, в которой коллега по цеху рассказывает из чего состоит диаграмма последовательности и приводит наглядные примеры.
Для тех, кому лень переходить по ссылкам, изложу кратко здесь — диаграмма последовательности состоит из объектов, линий жизни и сообщений.
Объекты это взаимодействующие друг с другом сущности разного типа. Например, пользователь, микросервис, база данных и т.д. Каждый объект на схеме должен иметь название.
Линии жизни это вертикальная линия, отображающая исполнение функций объекта.
Сообщения показывают направление информационного обмена между объектами и их содержание: запрос или ответ, вызов хранимой процедуры или отправка сообщения. Сообщения отображаются в виде стрелок, направленных от одной линии жизни к другой, и имеют несколько типов.
Одним из важных понятий являются группировки сообщений, накладывающие определенные правила взаимодействия. Их существует несколько типов:
-
Alt — группировка для демонстрации альтернативных кейсов взаимодействия.
-
Opt — группировка для демонстрации опционального (необязательного) кейса взаимодействия.
-
Par — группировка для демонстрации параллельно выполняемых кейсов взаимодействия.
-
Loop — группировка для демонстрации циклов с условием.
-
Group — группировка сообщений по смыслу.
Диаграмма состояний (UML State diagram)
Отображает состояния объекта и связи между ними.
Состоит из: начального/конечного состояния, обозначаемого кругом, промежуточных состояний, обозначаемых прямоугольником, переходов, обозначаемых стрелками.
Диаграмма классов (UML Class diagram)
Отображает структуру системы, содержащей различные объекты и классы.
Чаще всего используется, чтобы спроектировать систему, реализованную на принципах объектно-ориентированного подхода, при котором вся программа рассматривается как набор взаимодействующих друг с другом объектов (классов) и продемонстрировать иерархию классов внутри программы.
На изображении ниже представлены упрощенные примеры диаграммы классов и состояний.
Описание структуры данных (ER-diagram)
Схема «сущность-связь» (также ERD или ER-диаграмма) — это разновидность блок-схемы, где показано, как разные «сущности» связаны между собой внутри системы. ER-диаграммы чаще всего применяются для проектирования реляционных баз данных.
Выделяют три уровня ER-моделей: концептуальный, логический, физический.
-
Концептуальная ER-модель — это высокоуровневое представление сущностей. Она содержит наименьшее количество деталей и отражает общий объём модели, то есть количество сущностей и связей в ней.
-
Логическая ER-модель — это описание важных для предметной области сущностей, их атрибутов и связей между ними.
-
Физическая ER-модель — это описание того, как логическая ER-модель может быть разработана с помощью определённой технологии (СУБД).
Существует две нотации ERD: нотация Питера-Чена и нотация Crow’s Foot. Наиболее популярной и используемой из них является последняя, поэтому она и будет рассмотрена далее.
На изображении ниже показан пример логической модели ER-диаграммы в нотации Crow’s Foot (она же известна, как «Воронья лапка»).
Основные положения нотации:
-
Сущности изображаются в виде прямоугольников с названием.
Сущность в базе данных может рассматриваться как таблица. -
Атрибуты сущности перечисляются в нижней части прямоугольника. Первичный ключ выделяется звездочкой.
Атрибуты сущностей в базе данных должны рассматриваться как поля таблицы. Для каждого поля нужно определить:-
Имя на английском языке.
-
Тип данных и размерность.
-
Допустимость пустых значений.
-
Значение по умолчанию (если требуется).
-
Правила валидации значений (если требуется).
-
Связи между таблицами отражаются через внешний ключ.
-
-
Связь между сущностями изображается линией.
У связи в нотации Crow’’s Foot есть две характеристики — модальность и кардинальность.-
Модальность показывает какое минимальное количество связей должно быть у такой сущности (ноль или минимум одна).
Обязательная связь (минимум одна) обозначается вертикальной чертой.
Опциональная связь (может быть ноль) обозначается кругом. -
Кардинальность показывает какое максимальное количество связей может быть между экземплярами разных сущностей (одна или много).
Если максимальное количество связей — одна, то кардинальность обозначается вертикальной чертой.
Если связей может быть несколько, то кардинальность обозначается как та самая «воронья лапка». -
Обозначения характеристик связи располагаются на линии именно в таком порядке: сначала модальность (минимум), потом кардинальность (максимум).
-
Логическую ER-модель можно перевести в физическую за пять шагов. Для этого нужно:
-
Преобразовать сущности в таблицы.
-
Преобразовать атрибуты в поля с указанием типов и ограничений.
-
Добавить первичные ключи.
-
Добавить внешние ключи.
-
Добавить системные таблицы и поля.
Описание бизнес-процесса (BPMN)
BPMN — это нотация для моделирования и описания бизнес-процессов.
Чтобы попрактиковаться в составлении диаграмм есть хороший бесплатный инструмент bpmn.io в открытом доступе.
И снова оставлю ссылку на прекрасную статью с Хабра, в которой рассказано о BPMN-диаграммах с наглядными иллюстрациями.
Если кратко — BPMN диаграмма состоит из следующих основных артефактов:
-
Дорожки — необязательные элементы, используемые для объединения объектов в рамках одной функциональности/роли (обычно используют для наглядности отображения взаимодействий между смежными системами/ролями).
-
Действия (задачи) используются для отображения выполняемых процессов/подпроцессов.
-
Шлюзы — элементы, используемые для введения в процесс развилок, условий или дополнительной логики. Чаще всего используются три типа шлюзов: «исключающее ИЛИ», «И» и «включающее ИЛИ».
-
Потоки — стрелки, отображающие последовательность действий.
В этой статье вы узнали о типах требований и рассмотрели пример их оформления, познакомились с основными методами их сбора, рассмотрели основные типы диаграмм и инструменты, используемые при документировании требований.
В следующих частях будут рассмотрены типы программной архитектуры и интеграций, архитектурные паттерны, методологии разработки и многое другое, что поможет получить более полное представление о профессии системного аналитика.
Эту и другие статьи по системному анализу и IT-архитектуре, вы сможете найти в моем небольшом уютном Telegram-канале: Записки системного аналитика
ссылка на оригинал статьи https://habr.com/ru/articles/842280/
Добавить комментарий