Методы анализа требований на примере: полное руководство

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

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

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

 

Методы анализа требований

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

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

1. Нотация моделирования бизнес-процессов (BPMN).

BPMN (Моделирование и нотация бизнес-процессов) — это графическое представление вашего бизнес-процесса с использованием простых объектов, которое помогает организации общаться стандартным образом. Различные объекты, используемые в BPMN, включают в себя

• Объекты потока
• Соединение объектов
• Дорожки для плавания
• Артефакты.

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

• Кто осуществляет эти действия?
• Какие элементы данных необходимы для этой деятельности?

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

2. UML (унифицированный язык моделирования)

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

• Область
• объект
• Активность
• Диаграмма классов

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

3.Техника блок-схемы

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

4. Схема потока данных

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

• Разработка
• Поток
• Магазин
• терминатор

Логическая диаграмма потоков данных показывает деятельность системы, а физическая диаграмма потоков данных показывает инфраструктуру системы. Диаграмму потока данных можно разработать на ранней стадии процесса выявления требований на этапе анализа в рамках SDLC (Жизненный цикл разработки системы), чтобы определить масштаб проекта. Для облегчения анализа диаграмму потока данных можно разбить на подпроцессы, известные как «выровненный DFD».

5. Диаграммы ролевой деятельности (RAD)

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

• Действия
• Внешние события
• Области

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

Внешние события — это точки, в которых происходят изменения состояния.

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

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

6. Диаграммы Ганта

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

7. IDEF (интегрированное определение функционального моделирования)

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

8. Цветные сети Петри (ЦПС).

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

Объекты сетей Петри имеют специальную надпись, например, для

• Места: Имеет надписи типа .Имя, .Набор цветов, .Начальная маркировка и т. д.
• Переход : имеет надписи типа .Name (для идентификации) и .Guard (логическое выражение состоит из некоторых переменных)
• Дуги: Имеет надпись типа .Arc. Когда выражение дуги оценивается, оно дает несколько наборов цветов токенов.

9. Техника рабочего процесса

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

• Сбор информации
• Моделирование рабочего процесса
• Моделирование бизнес-процессов
• Реализация, проверка и исполнение

10. Объектно-ориентированные методы

Метод объектно-ориентированного моделирования использует объектно-ориентированную парадигму и язык моделирования для проектирования системы. Основное внимание уделяется поиску и описанию объекта в проблемной области. Целью объектно-ориентированного метода является

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

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

У объекта есть состояние, а изменения состояния отражаются поведением. Итак, когда объект получает сообщение, его состояние меняется в зависимости от поведения.

11. Анализ пробелов

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

• Revпросмотреть систему
• Требования к разработке
• сравнение
• Значение
• СОВЕТЫ