Анализ, приоритизация и категоризация требований. Разработка моделей требований.

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

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

1. Анализ собранных данных

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

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

Результат анализа: уточнённый и детализированный набор требований, который устраняет любые неопределённости или противоречия.

Приоритизация и категоризация требований

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

2. Приоритизация

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

Модель MoSCoW. Один из самых распространённых методов. Требования разделяются на четыре категории:

Must have (обязательные) — требования, без которых система не может функционировать.
Should have (желательные) — требования, которые важны, но не критичны для первоначальной реализации.
Could have (могут быть) — требования, которые полезны, но могут быть исключены без значительного ущерба для системы.
Won't have (не будут реализованы) — требования, которые не будут реализованы в этом проекте или текущей фазе.

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

3. Категоризация

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

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

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

Разработка моделей требований

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

4. ERD (Entity-Relationship Diagram)

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

Сущности. Объекты или классы, которые будут существовать в системе (например, «Пользователь», «Заказ»).
Связи. Отношения между сущностями. Например, «Пользователь» может делать много «Заказов», но «Заказ» принадлежит только одному «Пользователю».
Атрибуты. Характеристики сущностей. Например, «Пользователь» может иметь атрибуты «Имя», «Адрес электронной почты».

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

5. UML (Unified Modeling Language)

UML — универсальный язык моделирования, который используется для представления различных аспектов программного обеспечения. Наиболее распространённые диаграммы UML включают:

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

UML помогает визуализировать различные аспекты системы, что облегчает понимание и проектирование.

6. Диаграммы потока данных (Data Flow Diagrams)

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

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

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

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