Бизнес-анализ — Введение

Бизнес-анализ — это набор задач, знаний и методов, необходимых для определения бизнес-потребностей и определения решений бизнес-задач предприятия. Хотя общее определение схоже, методы и процедуры могут различаться в разных отраслях.

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

Бизнес-анализ также может быть выполнен, чтобы понять текущее состояние организации или служить основой для определения бизнес-потребностей. Однако в большинстве случаев бизнес-анализ выполняется для определения и проверки решений, которые соответствуют бизнес-потребностям, целям или задачам.

Кто такой бизнес-аналитик?

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

Почему бизнес-аналитик?

Организации используют бизнес-анализ по следующим причинам —

• Понять структуру и динамику организации, в которой должна быть развернута система.

• Понять текущие проблемы в целевой организации и выявить возможности улучшения.

• Чтобы клиент, конечный пользователь и разработчики имели общее представление о целевой организации.

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

Понять текущие проблемы в целевой организации и выявить возможности улучшения.

Чтобы клиент, конечный пользователь и разработчики имели общее представление о целевой организации.

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

В типичной крупной ИТ-организации, особенно в среде разработки, вы можете найти как локальные, так и оффшорные группы доставки, имеющие вышеупомянутые роли. Вы можете найти «бизнес-аналитика», который выступает в роли ключевого человека, который должен связать обе команды.

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

Следовательно, роль BA очень важна для эффективного и успешного запуска любого проекта.

Роль ИТ-бизнес-аналитика

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

Чем он отличается от других профессий?

Бизнес-анализ отличается от финансового анализа, управления проектами, обеспечения качества, организационного развития, тестирования, обучения и разработки документации. Однако в зависимости от организации бизнес-аналитик может выполнять некоторые или все эти связанные функции.

Бизнес-аналитики, занимающиеся исключительно разработкой программных систем, могут называться ИТ-бизнес-аналитиками, техническими бизнес-аналитиками, онлайн-бизнес-аналитиками, бизнес-системными аналитиками или системными аналитиками.

Бизнес-анализ также включает работу по взаимодействию между заинтересованными сторонами, группами разработчиков, группами тестирования и т. Д.

Жизненный цикл разработки программного обеспечения

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

• SDLC — это процесс, используемый ИТ-аналитиками для разработки или перепроектирования высококачественной программной системы, которая отвечает требованиям как клиента, так и реального мира.

• Он учитывает все связанные аспекты тестирования программного обеспечения, анализа и постпроцессного обслуживания.

SDLC — это процесс, используемый ИТ-аналитиками для разработки или перепроектирования высококачественной программной системы, которая отвечает требованиям как клиента, так и реального мира.

Он учитывает все связанные аспекты тестирования программного обеспечения, анализа и постпроцессного обслуживания.

Важные этапы SDLC изображены на следующей иллюстрации —

Этап планирования

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

Определение этапа

На этом этапе мы анализируем и определяем структуру системы. Мы определяем архитектуру, компоненты и то, как эти компоненты сочетаются друг с другом для создания работающей системы.

Этап проектирования

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

Стадия строительства

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

Реализация

Реализация является частью этапа строительства. На этом этапе мы начинаем генерацию кода на основе проектирования системы с использованием компиляторов, интерпретаторов, отладчиков для оживления системы.

Стадия тестирования

Как разные части системы завершены; они проходят серию испытаний. оно проверяется на соответствие требованиям, чтобы убедиться, что продукт действительно отвечает потребностям, указанным на этапе требования.

• Планы тестирования и контрольные примеры используются для выявления ошибок и для обеспечения работы системы в соответствии со спецификациями.

• На этом этапе выполняются различные типы тестирования, такие как модульное тестирование, ручное тестирование, приемочное тестирование и тестирование системы.

Планы тестирования и контрольные примеры используются для выявления ошибок и для обеспечения работы системы в соответствии со спецификациями.

На этом этапе выполняются различные типы тестирования, такие как модульное тестирование, ручное тестирование, приемочное тестирование и тестирование системы.

Отслеживание дефектов в тестировании

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

Тестирование проекта направлено на достижение двух основных целей:

• Обнаружение сбоев и дефектов в системе.

• Выявить несоответствие между требованиями и реализацией.

Обнаружение сбоев и дефектов в системе.

Выявить несоответствие между требованиями и реализацией.

Следующая блок-схема изображает процесс отслеживания дефектов —

Для достижения основных целей стратегия тестирования для предлагаемой системы обычно состоит из четырех уровней тестирования.

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

развертывание

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

Продукт может быть сначала выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде (UAT-Пользовательское тестирование). Затем, основываясь на отзывах, продукт может быть выпущен как есть или с предлагаемыми улучшениями в сегменте таргетинга.

Пост SDLC Процесс

После того, как продукт выпущен на рынок, его обслуживание выполняется для существующей клиентской базы.

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

Роль бизнес-аналитика в процессе SDLC

Как видно из приведенной ниже диаграммы, BA участвует в формировании бизнес-требований и преобразовании их в требования к решениям.

Он занимается переводом функций решения в требования к программному обеспечению. Затем возглавляет этап анализа и проектирования, диктует разработку кода, затем следует этап тестирования во время исправления ошибок в качестве агента изменений в команде проекта и в конечном итоге удовлетворяет требованиям заказчика.

Бизнес-анализ — Роли

Роль бизнес-аналитика в ИТ-проекте может быть множественной. Члены проектной команды могут иметь несколько ролей и обязанностей. В некоторых проектах БА может взять на себя роль аналитика бизнес-аналитики, дизайнера базы данных, специалиста по обеспечению качества программного обеспечения, тестировщика и / или тренера, если ресурсы ограничены.

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

Бизнес-анализ в значительной степени совпадает с анализом требований бизнеса, чтобы функционировать как обычно и оптимизировать, как они функционируют. Некоторые примеры бизнес-анализа:

• Создание бизнес-архитектуры
• Подготовка бизнес-кейса
• Проведение оценки риска
• Выявление требований
• Анализ бизнес процессов
• Документация требований

Основные роли бакалавра

Ключевая роль большинства бизнес-аналитиков — связь между бизнесом и техническими разработчиками. Бизнес-аналитики начинают работать вместе с бизнес-клиентами, чтобы собирать / определять требования системы или процесса для повышения производительности, одновременно работая с техническими группами по разработке и внедрению системы / процесса.

Как участник

Основная обязанность БА состоит в том, чтобы содействовать развитию бизнес-пользователей / ключевых пользователей в определении бизнес-проблем, потребностей и функций, понимании проблем и требований заинтересованных сторон для определения возможностей улучшения и внесении бизнес-вклада в разработку бизнес-кейса для ИТ. проект разработки системы.

В качестве посредника

Бизнес-аналитик также должен содействовать / координировать выявление и анализ требований, сотрудничать и общаться с заинтересованными сторонами и управлять их ожиданиями и потребностями, а также обеспечивать, чтобы требования были полными, однозначными и отображали их в соответствии с потребностями бизнеса в реальном времени. организации.

Как аналитик

Другая важная роль будет заключаться в оценке предлагаемой системы и организационной готовности к внедрению системы и оказанию поддержки пользователям и координации с ИТ-персоналом.

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

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

Основные обязанности бизнес-аналитика

Набор ответственности бизнес-аналитика потребует от него выполнения различных обязанностей на разных этапах проекта, и они объяснены ниже —

Фаза инициации

Этот этап ознаменует начало нового проекта, и бизнес-аналитик изменит следующие обязанности:

• Оказание помощи в проведении анализа затрат и выгод проекта.
• Понять бизнес-кейс.
• Убедитесь в целесообразности решения / проекта / продукта.
• Помощь в создании устава проекта.
• Определите заинтересованные стороны в проекте.

Этап планирования

Этот этап будет включать сбор требований и планирование, как проект будет выполняться и управляться. В его обязанности будут входить следующие функции:

• Выявление требований
• Анализировать, систематизировать и документировать требования.
• Управление требованиями путем создания сценариев использования, RTM, BRD, SRS и т. Д.
• Оцените предложенные решения.
• Поддерживать связь и улучшать связь с заинтересованными сторонами.
• Помощь в разработке планов управления проектом.
• Помощь в определении масштаба проекта, ограничений, допущений и рисков.
• Помощь в разработке пользовательского опыта решения.

Выполнение Фазы

Этот этап знаменует собой разработку решения в соответствии с собранными требованиями. В обязанности входит —

• Объясните требования к команде ИТ / разработчиков.

• Разъясните сомнения, опасения по поводу предлагаемого решения предстоит разработать.

• Обсудите и приоритизируйте изменения в объеме проекта и получите согласие.

• Создание сценариев бета-тестирования для начального тестирования.

• Обмен развивающимися модулями с заинтересованными сторонами и получение их обратной связи.

• Соблюдение сроков и управление ожиданиями заинтересованных сторон.

• Разрешение конфликтов и управление коммуникациями с командой проекта.

Объясните требования к команде ИТ / разработчиков.

Разъясните сомнения, опасения по поводу предлагаемого решения предстоит разработать.

Обсудите и приоритизируйте изменения в объеме проекта и получите согласие.

Создание сценариев бета-тестирования для начального тестирования.

Обмен развивающимися модулями с заинтересованными сторонами и получение их обратной связи.

Соблюдение сроков и управление ожиданиями заинтересованных сторон.

Разрешение конфликтов и управление коммуникациями с командой проекта.

Фаза мониторинга и контроля

На этом этапе проект измеряется и контролируется на предмет любых отклонений от первоначальных планов. Эта фаза проходит одновременно с фазой исполнения.

• Разработка тестовых сценариев и проведение комплексного модульного и интеграционного тестирования.

• Проведение UAT (использование приемочного тестирования) и создание отчетов о тестировании.

• Получить принятие / утверждение результатов от клиента.

• Объясните запросы на изменение команде разработчиков.

• Контролировать разработку запросов на изменение и проверять их выполнение в соответствии с целью проекта.

Разработка тестовых сценариев и проведение комплексного модульного и интеграционного тестирования.

Проведение UAT (использование приемочного тестирования) и создание отчетов о тестировании.

Получить принятие / утверждение результатов от клиента.

Объясните запросы на изменение команде разработчиков.

Контролировать разработку запросов на изменение и проверять их выполнение в соответствии с целью проекта.

Закрытие Фазы

Этот этап знаменует собой закрытие проекта. Обязанности —

• Представление завершенного проекта клиенту и получение его принятия.

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

• Провести сложные интеграционные испытания в производственной среде.

• Создание окончательной документации по продукту, документирование полученных уроков проекта.

Представление завершенного проекта клиенту и получение его принятия.

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

Провести сложные интеграционные испытания в производственной среде.

Создание окончательной документации по продукту, документирование полученных уроков проекта.

Какую БА предполагается доставить?

Бизнес-аналитик служит связующим звеном между бизнес-пользователями и техническими специалистами по ИТ. Их присутствие внесет значительный вклад в успех ИТ-проектов. Есть много преимуществ наличия выделенного бизнес-аналитика. Преданный бизнес-аналитик может —

• Обеспечивает четкую сферу проекта с точки зрения бизнеса.

• Разработка обоснованных бизнес-кейсов и более реалистичная оценка ресурсов и выгод для бизнеса.

• Готовит более качественные отчеты о масштабах, планировании и управлении проектами с точки зрения затрат и графика, особенно для крупных ИТ-проектов.

• Создает четкие и краткие требования, которые, в свою очередь, помогают обеспечить более четкие и точные требования, если ИТ-проект передается на аутсорсинг.

• Выявляйте реальные бизнес-потребности у пользователей и эффективно управляйте ожиданиями пользователей.

• Повышает качество проектирования для предлагаемой ИТ-системы, чтобы она соответствовала требованиям пользователя.

• Обеспечивает качество разработанной системы перед передачей конечным пользователям для проверки и принятия.

• Организация комплексного тестирования качества поставляемых систем и предоставление обратной связи техническим специалистам по ИТ.

Обеспечивает четкую сферу проекта с точки зрения бизнеса.

Разработка обоснованных бизнес-кейсов и более реалистичная оценка ресурсов и выгод для бизнеса.

Готовит более качественные отчеты о масштабах, планировании и управлении проектами с точки зрения затрат и графика, особенно для крупных ИТ-проектов.

Создает четкие и краткие требования, которые, в свою очередь, помогают обеспечить более четкие и точные требования, если ИТ-проект передается на аутсорсинг.

Выявляйте реальные бизнес-потребности у пользователей и эффективно управляйте ожиданиями пользователей.

Повышает качество проектирования для предлагаемой ИТ-системы, чтобы она соответствовала требованиям пользователя.

Обеспечивает качество разработанной системы перед передачей конечным пользователям для проверки и принятия.

Организация комплексного тестирования качества поставляемых систем и предоставление обратной связи техническим специалистам по ИТ.

Бизнес-анализ — Инструменты и методы

Бизнес-аналитик должен быть знаком с различными аналитическими инструментами и связанными с ними технологиями, когда вы носите шапку BA. Я имею в виду, если вы занимаетесь этой позицией.

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

По сути, есть 3 вида бизнес-анализа, которые мы можем разделить на:

• Стратегический анализ — Стратегический бизнес-анализ связан с предпроектной работой. Это метод или процесс выявления бизнес-проблем, разработки бизнес-стратегий, целей и задач, помогающий высшему руководству. Предоставляет управленческую информационную отчетность для эффективного процесса принятия решений.

• Тактический анализ — включает в себя знание конкретных методов бизнес-анализа, которые необходимо применять в нужный момент в соответствующем проекте.

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

Стратегический анализ — Стратегический бизнес-анализ связан с предпроектной работой. Это метод или процесс выявления бизнес-проблем, разработки бизнес-стратегий, целей и задач, помогающий высшему руководству. Предоставляет управленческую информационную отчетность для эффективного процесса принятия решений.

Тактический анализ — включает в себя знание конкретных методов бизнес-анализа, которые необходимо применять в нужный момент в соответствующем проекте.

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

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

Тем не менее, чтобы воплотить бизнес-требования в понятную информацию, хороший БА будет использовать методы повседневной деятельности, такие как поиск фактов, интервью, анализ документации, анкетирование, отбор проб и исследования.

Функциональные и нефункциональные требования

Мы можем разбить требование на два основных типа, таких как функциональные и нефункциональные требования.

Для всех технологических проектов функциональные и нефункциональные требования должны быть разделены и проанализированы отдельно.

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

Обзор широко используемых методов бизнес-анализа, которые в настоящее время на рынке —

Процессы	методы	Результаты процесса (итоги)
Определить функциональные и нефункциональные требования	Сеансы JAD Сценарии и варианты использования Организационное моделирование Scope Modeling Функциональная декомпозиция Интервью Наблюдение (Job Shadowing) Фокус группы Принятие и оценка Диаграммы последовательности Пользовательские истории мозговая атака Раскадровка макетирования Структурированная Проход Анализ событий Анализ бизнес-правил Требования Семинары Анализ риска Анализ причин	Документы бизнес-требований — Бизнес и функциональные требования Нефункциональные требования Бизнес правила Матрица прослеживаемости требований Общий шаблон — Документ бизнес-требований

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

Общий шаблон —

Применимость инструментов и процессов

Хотя существует множество инструментов и процедур, доступных бизнес-аналитикам, все зависит от текущей практики организации и того, как они хотели бы ее использовать.

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

Однако документ бизнес-требований является наиболее популярным и общепринятым способом представить требования в формате документации.

В последующих главах мы подробно обсудим некоторые из перечисленных методов.

Бизнес-анализ — JAD-сессия

Совместная разработка приложений (JAD) — это процесс, используемый для сбора бизнес-требований при разработке новых информационных систем для компании. Процесс JAD может также включать подходы для расширения участия пользователей, ускорения разработки и повышения качества спецификаций. Целью сеанса JAD является объединение предметного эксперта / бизнес-аналитика или ИТ-специалиста для выработки решений.

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

Использование сессии JAD

Сеансы JAD являются высоко структурированными, организованными семинарами, в которых принимают участие лица, принимающие решения, и ИТ-персонал, чтобы за короткое время получить высококачественные результаты.

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

Проще говоря, сеансы JAD могут

• Упрощение — объединяет месяцы встреч и телефонных звонков в структурированный семинар.

• Определить — Проблемы и участники

• Количественная оценка — информация и обработка потребностей

• Уточнение — Кристаллизация и уточнение всех требований, согласованных на сессии.

• Unify — выход из одной фазы разработки является вкладом в следующую.

• Удовлетворение — клиенты определяют систему; следовательно, это их система. Совместное участие вносит свой вклад в результат; они становятся приверженцами системного успеха.

Упрощение — объединяет месяцы встреч и телефонных звонков в структурированный семинар.

Определить — Проблемы и участники

Количественная оценка — информация и обработка потребностей

Уточнение — Кристаллизация и уточнение всех требований, согласованных на сессии.

Unify — выход из одной фазы разработки является вкладом в следующую.

Удовлетворение — клиенты определяют систему; следовательно, это их система. Совместное участие вносит свой вклад в результат; они становятся приверженцами системного успеха.

Участники сессии JAD

Участники сессии JAD:

Исполнительный спонсор

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

Эксперт предметной области

Это бизнес-пользователи и сторонние эксперты, которые необходимы для успешного семинара. Эксперты в данной области являются основой сессии JAD. Они будут управлять изменениями.

посредник

Он председательствует на собрании; он определяет проблемы, которые могут быть решены в рамках встречи. Фасилитатор не передает информацию на встречу.

Ключевые пользователи

Ключевые пользователи или также называемые суперпользователями в некоторых случаях использовались взаимозаменяемо и по-прежнему отличаются от компании к компании. Ключевыми пользователями, как правило, являются бизнес-пользователи, которые более тесно связаны с ИТ-проектом и несут ответственность за настройку профилей членов своей команды в ходе проектов.

Например: предположим, что Джон является ключевым пользователем, а Нэнси, Эван — пользователями системы SAP. В этом случае Нэнси и Эван не имеют доступа к изменению функциональности и профиля, в то время как Джон, являющийся Ключевым пользователем, имеет доступ к редактированию профиля с дополнительными полномочиями.

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

Техника сбора требований

Методы описывают, как задачи выполняются при определенных обстоятельствах. Задача может не иметь ни одного, или одного, или нескольких связанных методов. Техника должна быть связана хотя бы с одной задачей.

Ниже приведены некоторые из известных методов сбора требований:

мозговая атака

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

Анализ документов

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

Фокус-группа

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

Анализ интерфейса

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

Опрос

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

наблюдение

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

макетирования

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

Семинары по требованиям

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

Обратный инжиниринг

Если у проекта миграции нет доступа к достаточной документации существующей системы, обратный инжиниринг определит, что делает система. Он не будет определять, что должна делать система, и не будет определять, когда система поступает неправильно.

Анкетирование

При сборе информации от многих людей — слишком много, чтобы провести собеседование с бюджетом и временными ограничениями — можно использовать опрос или анкету. Опрос может заставить пользователей выбирать из вариантов, оценивать что-либо («Согласен строго, согласен…») или иметь открытые вопросы, позволяющие получить ответы в произвольной форме. Дизайн опроса сложный — вопросы могут поставить в тупик респондентов.

Документ о функциональных требованиях

Документ о функциональных требованиях (FRD) является формальным заявлением о функциональных требованиях приложения. Он служит той же цели, что и контракт. Здесь разработчики соглашаются предоставить указанные возможности. Клиент соглашается найти продукт удовлетворительным, если он обеспечивает возможности, указанные в FRD.

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

Документ функциональных требований (FRD) имеет следующие характеристики:

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

• Содержит полный набор требований к заявке. Никто не оставляет места для принятия чего-либо, что не указано в FRD.

• Это решение не зависит. ERD — это заявление о том, что должно делать приложение, а не о том, как оно работает. FRD не обязывает разработчиков разрабатывать дизайн. По этой причине любые ссылки на использование конкретной технологии совершенно неуместны в FRD.

Это демонстрирует, что приложение обеспечивает ценность с точки зрения бизнес-целей и бизнес-процессов в течение следующих нескольких лет.

Содержит полный набор требований к заявке. Никто не оставляет места для принятия чего-либо, что не указано в FRD.

Это решение не зависит. ERD — это заявление о том, что должно делать приложение, а не о том, как оно работает. FRD не обязывает разработчиков разрабатывать дизайн. По этой причине любые ссылки на использование конкретной технологии совершенно неуместны в FRD.

Функциональное требование должно включать следующее:

• Описания данных для ввода в систему

• Описание операций, выполняемых каждым экраном

• Описания рабочих процессов, выполняемых системой

• Описания системных отчетов или других выходов

• Кто может ввести данные в систему?

• Насколько система соответствует применимым нормативным требованиям?

Описания данных для ввода в систему

Описание операций, выполняемых каждым экраном

Описания рабочих процессов, выполняемых системой

Описания системных отчетов или других выходов

Кто может ввести данные в систему?

Насколько система соответствует применимым нормативным требованиям?

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

Функциональные требования.

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

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

• Модель бизнес-процесса — модель текущего состояния процесса (модель «как есть») или концепция того, каким процессом должен стать (модель «быть»)

• Диаграмма контекста системы — Диаграмма контекста показывает границы системы, внешние и внутренние объекты, которые взаимодействуют с системой, и соответствующие потоки данных между этими внешними и внутренними объектами.

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

• Бизнес-правила и требования к данным. Бизнес-правила определяют или ограничивают некоторые аспекты бизнеса и используются для определения ограничений данных, значений по умолчанию, диапазонов значений, количества элементов, типов данных, расчетов, исключений, обязательных элементов и реляционной целостности данных.

• Модели данных — диаграммы отношений сущностей, описания сущностей, диаграммы классов

• Концептуальная модель — отображение высокого уровня различных объектов для бизнес-функции и их взаимосвязи.

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

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

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

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

Функциональные требования — документ, содержащий подробные требования к разрабатываемой системе. Эти требования определяют функциональные особенности и возможности, которыми должна обладать система. Убедитесь, что любые предположения и ограничения, выявленные в ходе бизнес-кейса, все еще точны и актуальны.

Модель бизнес-процесса — модель текущего состояния процесса (модель «как есть») или концепция того, каким процессом должен стать (модель «быть»)

Диаграмма контекста системы — Диаграмма контекста показывает границы системы, внешние и внутренние объекты, которые взаимодействуют с системой, и соответствующие потоки данных между этими внешними и внутренними объектами.

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

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

Модели данных — диаграммы отношений сущностей, описания сущностей, диаграммы классов

Концептуальная модель — отображение высокого уровня различных объектов для бизнес-функции и их взаимосвязи.

Логическая модель — иллюстрирует конкретные сущности, атрибуты и отношения, вовлеченные в бизнес-функцию, и представляет все определения, характеристики и отношения данных в деловой, технической или концептуальной среде.

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

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

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

Спецификация требований к программному обеспечению

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

Документ SRS концентрируется на том, ЧТО должно быть сделано, и тщательно избегает решения ( как это сделать ). Он служит контрактом между командой разработчиков и заказчиком. Требования на этом этапе написаны с использованием терминологии конечного пользователя. При необходимости позже из него будет разработана формальная спецификация требований.

SRS — это полное описание поведения системы, подлежащей разработке, и может включать набор вариантов использования, которые описывают взаимодействия, которые пользователи будут иметь с программным обеспечением.

Назначение СГД

SRS — это средство связи между клиентом / клиентом, бизнес-аналитиком, разработчиками системы и группами обслуживания. Это также может быть договор между покупателем и поставщиком.

• Это даст прочную основу для этапа проектирования
• Поддерживает управление проектами и контроль
• Помогает в управлении и развитии системы

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

Следующее должно быть учтено в спецификации системы —

• Определите функции систем
• Определить аппаратное / программное функциональное разбиение
• Определить технические характеристики
• Определить производительность оборудования / программного обеспечения
• Определить требования безопасности
• Определить пользовательский интерфейс (руководство пользователя)
• Предоставить монтажные чертежи / инструкции
• Шаблон спецификации требований к программному обеспечению

лист регистраций изменений

Дата	Описание	автор	Комментарии
<Дата>	<Версия 1>	<Ваше имя>	<Первая редакция>

Утверждение документа

Следующая спецификация требований к программному обеспечению была принята и одобрена следующим:

Подпись	Напечатанное имя	заглавие	Дата
	<Ваше имя>	Ведущий Software Eng.
	Дэвид	инструктор

Бизнес-анализ — варианты использования

Одна из девяти диаграмм UML — это Диаграмма вариантов использования. Это не только важное, но и необходимое требование для программных проектов. Он в основном используется в жизненных циклах программного обеспечения. Как мы знаем, в цикле разработки существуют различные фазы, и наиболее используемая фаза для вариантов использования будет на этапе сбора требований.

Что такое вариант использования?

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

Актер — это Кто в системе, другими словами, он конечный пользователь.

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

Вариант использования определяет поток событий в системе. Это больше касается того, что выполняется системой для выполнения последовательности действий.

Преимущества варианта использования

Вариант использования обеспечивает следующие преимущества:

• Это простое средство определения функциональных требований с акцентом на добавленную стоимость для пользователя.

• Варианты использования относительно легко написать и прочитать по сравнению с традиционными методами требований.

• Варианты использования заставляют разработчиков думать с точки зрения конечного пользователя.

• Вариант использования вовлекает пользователя в процесс требования.

Это простое средство определения функциональных требований с акцентом на добавленную стоимость для пользователя.

Варианты использования относительно легко написать и прочитать по сравнению с традиционными методами требований.

Варианты использования заставляют разработчиков думать с точки зрения конечного пользователя.

Вариант использования вовлекает пользователя в процесс требования.

Анатомия варианта использования

Имя : Описательное имя, которое иллюстрирует цель варианта использования.

Описание : Описывает, что использует прецедент в нескольких предложениях.

Актер : Перечислите любых актеров, которые участвуют в сценарии использования.

Предварительное условие : условия, которые должны быть выполнены до начала использования.

Поток событий : описание взаимодействия между системой и актером.

Состояние после публикации : Опишите состояние системы после того, как сценарий использования завершил свою работу.

Руководство для шаблона использования

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

Идентификация варианта использования

• Идентификатор варианта использования — присвойте каждому варианту использования уникальный числовой идентификатор в иерархической форме: XY Связанные варианты использования можно сгруппировать в иерархии. Функциональные требования можно проследить до обозначенного варианта использования.

• Имя варианта использования — укажите краткое, ориентированное на результаты имя для варианта использования. Они отражают задачи, которые пользователь должен выполнять с помощью системы. Включите глагол действия и существительное. Некоторые примеры —

  • Просмотр информации о номере детали.

  • Вручную пометьте источник гипертекста и установите ссылку на цель.

  • Сделайте заказ на компакт-диск с обновленной версией программного обеспечения.

Идентификатор варианта использования — присвойте каждому варианту использования уникальный числовой идентификатор в иерархической форме: XY Связанные варианты использования можно сгруппировать в иерархии. Функциональные требования можно проследить до обозначенного варианта использования.

Имя варианта использования — укажите краткое, ориентированное на результаты имя для варианта использования. Они отражают задачи, которые пользователь должен выполнять с помощью системы. Включите глагол действия и существительное. Некоторые примеры —

Просмотр информации о номере детали.

Вручную пометьте источник гипертекста и установите ссылку на цель.

Сделайте заказ на компакт-диск с обновленной версией программного обеспечения.

История использования

Здесь мы упоминаем об именах людей, которые являются заинтересованными сторонами документа Usecase.

• Создано — укажите имя человека, который первоначально задокументировал этот вариант использования.

• Дата создания — введите дату, в которую сценарий использования был первоначально задокументирован.

• Последнее обновление — укажите имя человека, который выполнил самое последнее обновление, в описании варианта использования.

• Дата последнего обновления — введите дату последнего использования варианта использования.

Создано — укажите имя человека, который первоначально задокументировал этот вариант использования.

Дата создания — введите дату, в которую сценарий использования был первоначально задокументирован.

Последнее обновление — укажите имя человека, который выполнил самое последнее обновление, в описании варианта использования.

Дата последнего обновления — введите дату последнего использования варианта использования.

Определение варианта использования

Ниже приведены определения ключевых концепций варианта использования.

Актер

Актер — это физическое или физическое лицо, не относящееся к указанной программной системе, которое взаимодействует с системой и выполняет сценарии использования для выполнения задач. Разные действующие лица часто соответствуют разным пользовательским классам или ролям, определенным сообществом клиентов, которые будут использовать продукт. Назовите актера, который будет выполнять этот сценарий использования.

Описание

Предоставьте краткое описание причины и результата этого варианта использования или высокоуровневое описание последовательности действий и результатов выполнения варианта использования.

Предпосылками

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

Примеры

• Личность пользователя была подтверждена.
• На компьютере пользователя имеется достаточно свободной памяти для запуска задачи.

Условия размещения

Опишите состояние системы в конце исполнения варианта использования. Пронумеруйте каждый пост.

Примеры

• Документ содержит только допустимые теги SGML.
• Цена товара в базе данных была обновлена ​​с новым значением.

приоритет

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

Частота использования

Оцените, сколько раз этот сценарий использования будет выполняться актерами за определенную подходящую единицу времени.

Нормальный ход событий

Предоставьте подробное описание действий пользователя и ответов системы, которые будут иметь место во время выполнения сценария использования в нормальных, ожидаемых условиях. Эта последовательность диалогов в конечном итоге приведет к достижению цели, указанной в названии и описании варианта использования. Это описание может быть написано как ответ на гипотетический вопрос: «Как мне <выполнить задачу, указанную в имени варианта использования>?». Лучше всего это сделать в виде нумерованного списка действий, выполняемых субъектом, чередующихся с предоставленными ответами. по системе.

Альтернативные курсы

Документируйте другие, законные сценарии использования, которые могут иметь место в этом сценарии использования отдельно в этом разделе. Укажите альтернативный курс и опишите любые различия в последовательности шагов. Пронумеруйте каждый альтернативный курс, используя идентификатор прецедента, а затем «AC», чтобы указать «Альтернативный курс». Пример: XYAC.1.

Исключения

Опишите любые ожидаемые ошибки, которые могут возникнуть во время выполнения сценария использования, и определите, как система должна реагировать на эти условия. Кроме того, опишите, как система должна реагировать в случае сбоя при выполнении варианта использования по какой-то непредвиденной причине. Пронумеруйте каждое исключение, используя ID прецедента в качестве префикса, затем «EX» для обозначения «Exception». Пример: XYEX.1.

Включает в себя

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

Специальные требования

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

Предположения

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

Примечания и проблемы

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

Управление изменениями и контроль версий

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

Диаграммы прецедентов

Важной частью Unified Modeling Language (UML) являются средства для рисования диаграмм вариантов использования. Варианты использования используются на этапе анализа проекта для определения и разделения функциональности системы. Они разделяют систему на участников и варианты использования. Актеры представляют роли, которые могут играть пользователи системы.

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

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

Рисование диаграмм вариантов использования

На рисунке ниже показано, как вариант использования может выглядеть как схематическая форма UML. Сам вариант использования выглядит как овал. Актеры нарисованы как маленькие фигурки. Актеры связаны с сценарием использования с линиями.

Вариант использования 1 — продавец проверяет товар

• Клиент выставляет товар на прилавок.
• «Использует» Swipe UPC Reader.
• Система ищет UPC-код в базе данных для описания товара и цены
• Система издает звуковой сигнал.
• Система объявляет описание товара и цену за голосовой вывод.
• Система добавляет цену и тип товара к текущему счету.
• Система добавляет цену, чтобы исправить итоговую сумму налога

Таким образом, отношение «использует» очень похоже на вызов функции или подпрограмму.

Вариант использования, используемый таким образом, называется абстрактным вариантом использования, поскольку он не может существовать сам по себе, но должен использоваться другими вариантами использования.

Пример ─ Сценарий вывода средств

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

Денежный торговый автомат предоставляет Сценарий вывода средств для клиента и участников Банка.

Отношения между актерами и сценариями использования

Варианты использования могут быть организованы с использованием следующих отношений —

• Обобщение
• ассоциация
• простираться
• Включают

Обобщение между вариантами использования

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

Ассоциация между вариантами использования

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

простираться

Есть некоторые функции, которые запускаются по желанию. В таких случаях используется отношение расширения, и к нему присоединяется правило расширения. Следует помнить, что базовый вариант использования должен иметь возможность выполнять функцию самостоятельно, даже если расширенный вариант использования не вызывается.

Отношение расширения показано в виде пунктирной линии с открытой стрелкой, направленной от расширяющегося варианта использования к расширенному (базовому) сценарию использования. Стрелка помечена ключевым словом «удлинить».

Включают

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

Включите связь между вариантами использования, которая показана пунктирной стрелкой с открытой стрелкой от базового варианта использования до включенного варианта использования. Стрелка помечена ключевым словом «включить».

Варианты использования имеют дело только с функциональными требованиями к системе. Другие требования, такие как бизнес-правила, требования к качеству обслуживания и ограничения реализации, должны быть представлены отдельно.

Диаграмма, показанная ниже, является примером простой диаграммы вариантов использования со всеми отмеченными элементами.

Основные принципы успешного применения прецедентов

• Будьте проще, рассказывая истории
• Быть продуктивным без совершенства
• Понять общую картину
• Определить возможность повторного использования для вариантов использования
• Фокус на стоимости
• Сборка системы по частям
• Доставить систему с шагом
• Адаптировать для удовлетворения потребностей команды

Шаблон варианта использования

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

Идентификатор варианта использования:
Название варианта использования:
Создано:		Последнее обновление
Дата создания:		Дата последнего обновления
Актер:
Описание:
Предпосылки:
Условия размещения:
Приоритет:
Частота использования:
Нормальный ход событий:
Альтернативные курсы:
Исключения:
Включает в себя:
Специальные требования:
Предположения:
Примечания и проблемы:

Бизнес-анализ — требования Mngmt

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

Ключевые заинтересованные стороны хотят, чтобы кто-то мог объяснить требования клиента / клиента простым языком. Будет ли это полезным для них от понимания ценности на высоком уровне? Это будет основной областью, так как они попытаются сопоставить документацию с требованиями и тем, как BA может общаться наилучшим образом.

Почему проекты терпят неудачу

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

• Сбой рынка и стратегии
• Организационные и плановые сбои
• Сбои качества
• Лидерство и неудачи в управлении
• Навыки, Знания и недостатки компетенции
• Помолвка, работа в команде и сбои связи

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

Почему успешные команды делают управление требованиями

Управление требованиями подразумевает синхронизацию вашей команды и предоставление информации о том, что происходит внутри проекта.

Для успеха ваших проектов крайне важно, чтобы вся ваша команда понимала, что вы строите и почему — именно так мы определяем управление требованиями. «Почему» важно, потому что оно обеспечивает контекст для целей, обратной связи и решений, принимаемых в отношении требований.

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

Начнем с основ

Требование — это условие или способность, необходимые заинтересованному лицу для решения проблемы или достижения цели. Состояние или способность, которой должна соответствовать система или система. Компонент для удовлетворения контракта, стандарта, спецификации или других формально наложенных документов.

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

Требования высокого уровня иногда называют просто потребностями или целями . В практике разработки программного обеспечения требования могут упоминаться как «варианты использования», «функции» или «функциональные требования». Более конкретно, в методологиях гибкой разработки требования часто отражаются в эпосах и историях .

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

Заинтересованная сторона может запросить функцию, которая описывает, как продукт будет обеспечивать ценность при решении проблемы. Разработчик может определить требование на основе того, как конечный продукт должен выглядеть или работать с точки зрения удобства использования или пользовательского интерфейса.

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

Теперь, когда мы определили ценность управления требованиями на высоком уровне, давайте углубимся в четыре основных принципа, которые каждый член команды и заинтересованное лицо может извлечь выгоду из понимания —

• Планирование хороших требований: «Какого черта мы строим?»
• Совместная работа и вступительный взнос: «Просто одобрите спецификацию, уже!»
• Отслеживание и управление изменениями: «Подождите, разработчики знают, что изменилось?»
• Гарантия качества: «Здравствуйте, кто-нибудь проверял эту вещь?»

Все знают, что мы строим и почему? Это ценность управления требованиями.

Сотрудничество и бай-ин от заинтересованных сторон

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

На практике вам не обязательно нужен «консенсус», вы хотите «вступительный взнос» от группы и одобрение со стороны контролирующих, чтобы вы могли продвигать проект вперед. С консенсусом вы пытаетесь заставить всех пойти на компромисс и согласиться с решением. С бай-ином вы пытаетесь заставить людей поддержать лучшее решение, принять разумное решение и сделать все необходимое для продвижения вперед.

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

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

Именно тогда, когда разработчики, тестировщики или другие заинтересованные стороны чувствуют себя «не в курсе», возникают проблемы с коммуникацией, люди разочаровываются, а проекты задерживаются. После того, как все согласились с объемом работ, необходимо, чтобы требования были четкими и хорошо документированными. Отслеживание всех требований — вот где все становится сложнее.

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

Планирование хороших требований

Итак, что делает хорошее требование? Хорошее требование должно быть ценным и действенным; это должно определить потребность, а также обеспечить путь к решению. Все в команде должны понимать, что это значит. Требования различаются по сложности.

• Хороший документ с требованиями может быть частью группы с требованиями высокого уровня, разбитыми на подусловия.

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

• Хорошие требования должны быть краткими и конкретными и должны отвечать на вопрос «что нам нужно?», А не «как мы удовлетворяем потребность?»

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

Хороший документ с требованиями может быть частью группы с требованиями высокого уровня, разбитыми на подусловия.

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

Хорошие требования должны быть краткими и конкретными и должны отвечать на вопрос «что нам нужно?», А не «как мы удовлетворяем потребность?»

Хорошие требования гарантируют, что все заинтересованные стороны понимают свою часть плана; если детали неясны или неверно истолкованы, конечный продукт может быть неисправен или неисправен.

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

Сбор и анализ требований

Требование — это условие или способность, необходимые заинтересованному лицу для решения проблемы или достижения организационной цели; состояние или способность, которой должна соответствовать система.

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

Требования должны быть —

• документированный
• Осуществимое
• измеримый
• Тестируемые
• прослеживаемый

Требования должны быть связаны с определенными бизнес-потребностями или возможностями и определены с уровнем детализации, достаточным для проектирования системы.

Бизнес-аналитик собирает информацию, наблюдая за существующими системами, изучая существующие процедуры, обсуждая с клиентами и конечными пользователями. Аналитик также должен обладать творческими и творческими навыками в отсутствие работающей Системы. Анализ собранных требований для поиска недостающих ссылок — это анализ требований.

Выявление Подхода

Чтобы определить цели, задайте бизнес-эксперту, менеджеру по развитию и спонсору проекта следующие вопросы:

• Каких бизнес-целей компании поможет этот проект?

• Почему мы делаем этот проект сейчас?

• Что будет, если мы сделаем это позже?

• Что делать, если мы не делаем это вообще?

• Кто выиграет от этого проекта?

• Считают ли люди, которые извлекут из этого пользу, самым важным улучшением, которое может быть сделано в это время?

• Должны ли мы делать другой проект вместо этого?

Каких бизнес-целей компании поможет этот проект?

Почему мы делаем этот проект сейчас?

Что будет, если мы сделаем это позже?

Что делать, если мы не делаем это вообще?

Кто выиграет от этого проекта?

Считают ли люди, которые извлекут из этого пользу, самым важным улучшением, которое может быть сделано в это время?

Должны ли мы делать другой проект вместо этого?

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

Различные типы требований

Наиболее распространенные типы требований, которые интересуют бизнес-аналитика, следующие:

Бизнес-требования

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

Требования к пользователю

Пользовательские требования должны указывать конкретные требования, которые пользователь ожидает / хочет от программного обеспечения, которое будет создано из программного проекта. Требование пользователя должно быть Проверяемым, Четким и кратким, Полным, Последовательным, Прослеживаемым, Жизнеспособным.

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

Системные Требования

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

Функциональные требования

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

Нефункциональные требования

Нефункциональное требование — это то, которое определяет критерии, которые могут использоваться для оценки работы системы, а не для конкретного поведения. Архитектура системы говорит о плане реализации нефункциональных требований.

Нефункциональные требования говорят о том, как должна выглядеть система, или ее можно назвать «система должна быть». Нефункциональные требования называются качествами системы.

Требования к переходу

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

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

Отслеживание и управление изменениями

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

Матрица возможностей трассировки требований (RTM) предоставляет метод для отслеживания функциональных требований и их реализации в процессе разработки. Каждое требование включено в матрицу вместе с соответствующим номером раздела.

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

Включить столбцы для каждого из следующих в RTM —

• Описание требования
• Требование ссылки в FRD
• Метод проверки
• Ссылка на требование в плане испытаний

Пример — подключение точек для определения взаимосвязей между элементами в вашем проекте. Это соединитель общего нисходящего потока.

Идея Требования Дизайн Тест Бизнес Цели

Вы должны быть в состоянии проследить каждое из ваших требований до их первоначальной бизнес-цели.

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

Гарантия качества

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

Вкратце, конкретные требования могут помочь вам обнаружить и исправить проблемы раньше, а не позже, когда их решение намного дороже. Кроме того, исправление дефекта в процессе разработки после его кодирования может стоить в 100 раз дороже, чем исправление на раннем этапе, когда это требуется.

Интегрируя управление требованиями в свой процесс обеспечения качества, вы можете помочь своей команде повысить эффективность и устранить доработки. Кроме того, на переделках возникает большинство проблем с расходами.

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

Таким образом, управление требованиями может показаться сложной дисциплиной, но когда вы сводите его к простой концепции — речь идет о том, чтобы помочь командам ответить на вопрос: «Все ли понимают, что мы строим и почему?» От бизнес-аналитиков, продукта менеджеры и руководители проектов разработчикам, менеджерам по обеспечению качества и тестировщикам, а также заинтересованным сторонам и заказчикам — поэтому зачастую причиной провала проекта является неправильное понимание масштабов проекта.

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

Примечание. Исследования показали, что проектные группы могут устранить 50-80% дефектов проекта, эффективно управляя требованиями. По данным Института разработки программного обеспечения Карнеги-Меллона, «60–80 процентов затрат на разработку программного обеспечения находятся в процессе доработки».

Получение требований Signoff

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

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

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

Бизнес Анализ — Моделирование

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

• Основные ценности компании
• Что это служит?
• Что отличает?
• Его ключевые ресурсы
• Основные отношения
• Каналы доставки

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

Бизнес-модель — это структурированная модель, похожая на план разработки конечного продукта. Это дает структуру и динамику для планирования. Это также обеспечивает основу для конечного продукта.

Цель бизнес-моделирования

Бизнес-моделирование используется для проектирования текущего и будущего состояния предприятия. Эта модель используется бизнес-аналитиком и заинтересованными сторонами для обеспечения точного понимания текущей модели предприятия «как есть».

Он используется для проверки того, имеют ли заинтересованные стороны общее понимание предлагаемого «будущего решения».

Анализ требований является частью процесса бизнес-моделирования и формирует основное направление деятельности. Функциональные требования собраны во время «Текущее состояние». Эти требования предоставляются заинтересованными сторонами в отношении бизнес-процессов, данных и бизнес-правил, которые описывают желаемую функциональность, которая будет разработана в будущем государстве.

Выполнение анализа GAP

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

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

Если пробела нет (т. Е. Текущее состояние является достаточным для удовлетворения потребностей бизнеса и желаемых результатов), вероятно, не будет необходимости запускать ИТ-проект. В противном случае, проблемы / проблемы, которые необходимо решить для устранения разрыва, должны быть определены.

Можно использовать такие методы, как SWOT-анализ (анализ сильных и слабых сторон, возможностей и угроз) и анализ документов.

Оценить предложенную систему

BA должен помочь команде ИТ-проекта в оценке предлагаемой ИТ-системы, чтобы убедиться, что она отвечает потребностям бизнеса и максимизирует ценности, предоставляемые заинтересованным сторонам. БА также следует проверить готовность организации поддержать переход к предлагаемой ИТ-системе, чтобы обеспечить беспроблемное внедрение системы.

BA должен помочь команде ИТ-проекта определить, могут ли предлагаемый вариант системы и проектирование системы высокого уровня удовлетворить потребности бизнеса и обеспечить достаточную ценность для бизнеса, чтобы оправдать инвестиции. Если имеется несколько вариантов системы, BA должен сотрудничать с ИТ-специалистами, чтобы определить плюсы и минусы каждого варианта и выбрать вариант, обеспечивающий наибольшую ценность для бизнеса.

Руководящие принципы для бизнес-моделирования

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

• Вариация домена и пользователя — разработка бизнес-модели часто выявляет области разногласий или путаницы между заинтересованными сторонами. Бизнес-аналитику необходимо будет документировать следующие изменения в модели «как есть».

• Несколько рабочих единиц выполняют одну и ту же функцию: документируйте отклонения в модели AS-IS. Это могут быть разные подразделения или географии.

• Несколько пользователей выполняют одну и ту же работу — разные заинтересованные стороны могут выполнять одинаковую работу по-разному. Различия могут быть результатом различных наборов навыков и подходов разных бизнес-единиц или результатом различных потребностей внешних заинтересованных сторон, обслуживаемых предприятием. Документируйте отклонения в модели AS-IS.

• Механизм разрешения . Бизнес-аналитик должен задокументировать, будет ли решение ToBe учитывать несоответствия в текущей бизнес-модели или решение будет нуждаться в стандартизации. Заинтересованные стороны должны определить, какой подход следует использовать. Модель To-Be будет отражать их решение.

Вариация домена и пользователя — разработка бизнес-модели часто выявляет области разногласий или путаницы между заинтересованными сторонами. Бизнес-аналитику необходимо будет документировать следующие изменения в модели «как есть».

Несколько рабочих единиц выполняют одну и ту же функцию: документируйте отклонения в модели AS-IS. Это могут быть разные подразделения или географии.

Несколько пользователей выполняют одну и ту же работу — разные заинтересованные стороны могут выполнять одинаковую работу по-разному. Различия могут быть результатом различных наборов навыков и подходов разных бизнес-единиц или результатом различных потребностей внешних заинтересованных сторон, обслуживаемых предприятием. Документируйте отклонения в модели AS-IS.

Механизм разрешения . Бизнес-аналитик должен задокументировать, будет ли решение ToBe учитывать несоответствия в текущей бизнес-модели или решение будет нуждаться в стандартизации. Заинтересованные стороны должны определить, какой подход следует использовать. Модель To-Be будет отражать их решение.

Пример роли БА в моделировании ERP-систем

Предполагается, что бизнес-аналитик должен определить стандартный бизнес-процесс и внедрить его в систему ERP, что имеет ключевое значение для эффективной реализации. Обязанностью БА также является определение языка разработчиков на понятном языке перед внедрением, а затем использование лучших практик и их отображение на основе возможностей системы.

Требование к системе — это анализ соответствия GAAP, который должен быть сбалансирован между —

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

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

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

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

Функциональный бизнес-аналитик

Экспертиза предметной области, как правило, приобретается в течение определенного периода, когда вы занимаетесь бизнесом. Например,

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

• Торговый представитель страховой компании может понять различные стадии, связанные с получением страхового полиса.

• У маркетолога больше шансов понять ключевых заинтересованных лиц и бизнес-процессы, вовлеченные в систему управления взаимоотношениями с клиентами.

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

• Бизнес-аналитик в области здравоохранения должен иметь базовые знания о показателях в области здравоохранения и финансового использования в США, технический опыт и понимание EDI 837/835/834, руководств HIPAA, кодификации ICD — 9/10 и кодов CPT, LOINC, знаний SNOMED.

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

Торговый представитель страховой компании может понять различные стадии, связанные с получением страхового полиса.

У маркетолога больше шансов понять ключевых заинтересованных лиц и бизнес-процессы, вовлеченные в систему управления взаимоотношениями с клиентами.

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

Бизнес-аналитик в области здравоохранения должен иметь базовые знания о показателях в области здравоохранения и финансового использования в США, технический опыт и понимание EDI 837/835/834, руководств HIPAA, кодификации ICD — 9/10 и кодов CPT, LOINC, знаний SNOMED.

Некоторые бизнес-аналитики получают знания в области, тестируя бизнес-приложения и работая с бизнес-пользователями. Они создают благоприятную среду обучения, используя свои межличностные и аналитические навыки. В некоторых случаях они дополняют свои знания предметной области несколькими сертификатами доменов, предлагаемыми AICPCU / ​​IIA и LOMA в области страхования и финансовых услуг. Есть и другие институты, которые предлагают сертификацию в других областях.

Другие основные виды деятельности

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

• Организация подготовки формализованного и унифицированного описания бизнес-процессов таким образом, чтобы обеспечить эффективную автоматизацию в системе.

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

• Для участия в рабочих встречах определены требования к разработчикам.

• Проверьте и проконтролируйте, были ли установленные вами требования правильно «воспроизведены» и записаны в документах, описывающих будущую модель в системе (Blueprints).

• Подготовка данных и помощь в создании прототипа системы.

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

• Проверка прототипа установки на соответствие требованиям, определенным владельцами бизнес-процессов.

• Выступать в качестве ресурса поддержки для ваших ИТ-групп при подготовке данных и фактической производительности функциональных и интеграционных тестов в системе.

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

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

Для участия в рабочих встречах определены требования к разработчикам.

Проверьте и проконтролируйте, были ли установленные вами требования правильно «воспроизведены» и записаны в документах, описывающих будущую модель в системе (Blueprints).

Подготовка данных и помощь в создании прототипа системы.

Помощь в подготовке данных для миграции списков и балансов в формате, требуемом системой.

Проверка прототипа установки на соответствие требованиям, определенным владельцами бизнес-процессов.

Выступать в качестве ресурса поддержки для ваших ИТ-групп при подготовке данных и фактической производительности функциональных и интеграционных тестов в системе.

В следующем разделе мы кратко обсудим некоторые из популярных инструментов бизнес-моделирования, используемых крупными организациями в ИТ-средах.

Инструмент 1: Microsoft Visio

MS-Visio — это программное обеспечение для рисования и построения диаграмм, которое помогает преобразовать концепции в визуальное представление. Visio предоставляет вам заранее определенные формы, символы, фоны и границы. Просто перетащите элементы на диаграмму, чтобы создать профессиональный инструмент коммуникации.

Шаг 1 — Чтобы открыть новый чертеж Visio, перейдите в меню «Пуск» и выберите «Программы» → Visio.

Шаг 2 — Наведите курсор на «Бизнес-процесс» и выберите «Основная блок-схема».

На следующем снимке экрана показаны основные разделы приложения MS-Visio.

Давайте теперь обсудим основную полезность каждого компонента —

A — панели инструментов в верхней части экрана похожи на другие программы Microsoft, такие как Word и PowerPoint. Если вы использовали эти программы раньше, вы можете заметить несколько различных функций, которые мы рассмотрим позже.

Выбор справки Галерея диаграмм — это хороший способ ознакомиться с типами рисунков и диаграмм, которые можно создавать в Visio.

B — В левой части экрана отображаются меню, относящиеся к типу создаваемой вами диаграммы. В этом случае мы видим —

• Стрелка Формы
• Фон
• Основные формы блок-схемы
• Границы и названия

C — В центре экрана отображается рабочее пространство диаграммы, которое включает в себя фактическую страницу диаграммы, а также некоторое пустое пространство рядом с этой страницей.

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

Инструмент 2: Enterprise Architect

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

Цель Enterprise Architect — определить, как организация может наиболее эффективно достичь своих текущих и будущих целей.

У архитектора предприятия есть четыре точки зрения, которые следующие:

• Бизнес-перспектива — Бизнес-перспектива определяет процессы и стандарты, в соответствии с которыми бизнес работает на ежедневной основе.

• Перспектива приложения — Перспектива приложения определяет взаимодействие между процессами и стандартами, используемыми организацией.

• Информационная перспектива — определяет и классифицирует необработанные данные, такие как файлы документов, базы данных, изображения, презентации и электронные таблицы, которые требуются организации для эффективной работы.

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

Бизнес-перспектива — Бизнес-перспектива определяет процессы и стандарты, в соответствии с которыми бизнес работает на ежедневной основе.

Перспектива приложения — Перспектива приложения определяет взаимодействие между процессами и стандартами, используемыми организацией.

Информационная перспектива — определяет и классифицирует необработанные данные, такие как файлы документов, базы данных, изображения, презентации и электронные таблицы, которые требуются организации для эффективной работы.

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

Инструмент 3: Rational Requisite Pro

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

Мониторинг состояния и контроль изменений в базовых требованиях. Основными элементами являются Управление изменениями и Отслеживаемость.

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

В Requisite Pro пользователь может работать с документом требований. Документ представляет собой файл MS-Word, созданный в приложении Reqpro и интегрированный с базой данных проекта. Требования, созданные вне Requisite pro, могут быть импортированы или скопированы в документ.

В Requisite Pro мы также можем работать с отслеживаемостью, здесь это зависимость между двумя требованиями. Отслеживаемость — это методический подход к управлению изменениями путем связывания требований, которые связаны друг с другом.

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

Проекты Requisite Pro позволяют нам создавать структуру проекта, в которой артефакты проекта организованы и управляются. В каждый проект включено следующее.

• Общая информация о проекте
• пакеты
• Общая информация о документе
• Типы документов
• Типы требований
• Атрибуты требования
• Значения атрибута
• Межпроектная прослеживаемость

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

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