Конспект

Пользовательские требования

Ключевые тезисы

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

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

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

Ценность и назначение

• Фокусировка на ценности: Позволяют сконцентрироваться на том, какую пользу (ценность) продукт приносит пользователю.
• Средство коммуникации: Унифицируют и фиксируют общее понимание ожиданий между всеми заинтересованными сторонами.
• Основа для тестирования: Используются для составления тест-кейсов, критериев приемки (Acceptance Criteria) и определения готовности (Definition of Ready).

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

1. Подготовка: Определение стейкхолдеров, прояснение и обоснование запроса, понимание бизнес-целей, бюджета и ограничений.
2. Сбор: Использование методов (интервью, анкетирование, наблюдение, анализ документации и регламентов) для выявления потребностей.
3. Анализ и структурирование: Обработка собранной информации, выявление ключевых моментов и их формализация.
4. Документирование: Фиксация требований с использованием шаблонов (например, User Story или Use Case).
5. Согласование: Утверждение артефакта со всеми заинтересованными лицами перед передачей в разработку.

Критерии качества

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

• Однозначными (понятными).
• Проверяемыми.
• Конкретными.
• Непротиворечивыми.
• Соответствующими бизнес-целям и первоначальной постановке задачи.

Способы представления

User Story (Пользовательская история)

Краткое описание функции с точки зрения пользователя по шаблону:
«Как [тип пользователя], я хочу [цель], чтобы [причина/ценность]».

Примеры:

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

Преимущество: Позволяет лаконично зафиксировать роль, задачу и ценность. Часто используется в гибкой (Agile) разработке.

Use Case (Вариант использования)

Краткое описание в формате «Глагол + Объект» (например, «Просмотреть резюме», «Создать вакансию»).

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

Диаграмма вариантов использования (Use Case Diagram)

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

Алгоритм построения:

1. Выявление акторов: Определение классов пользователей системы (например, соискатель, работодатель, менеджер).
2. Формулирование целей: Понимание, чего хочет достичь каждый актор.
3. Составление списка Use Case: Описание конкретных действий (вариантов использования) для каждой цели.
4. Определение отношений: Расстановка связей между Use Case (включение, расширение).

Типы отношений на диаграмме:

• Включение (Include): Обязательная связь. Один Use Case не может быть выполнен без другого (например, для «Управления вакансией» необходимо «Просмотреть список вакансий»).
• Расширение (Extend): Необязательная, дополняющая связь. Один Use Case расширяет поведение другого при определенных условиях (например, «Отфильтровать список» расширяет «Просмотреть список»).

Критерии качества диаграммы:

• Все ключевые акторы идентифицированы.
• Каждый Use Case представляет одну цель.
• Нет дублирующихся или пересекающихся Use Case.
• Связи логичны и необходимы.
• Диаграмма читаема и не перегружена.

Практический пример: Система для кадрового агентства

Акторы: Соискатель, Работодатель, Менеджер (кадрового агентства).

Возможные варианты использования (Use Case):

• Для всех: Авторизоваться.
• Для Менеджера: Просмотреть резюме, Просмотреть вакансии, Откликнуться на вакансию (за соискателя), Связаться с работодателем.
• Для Соискателя: Создать/редактировать резюме, Просмотреть вакансии, Откликнуться на вакансию.
• Для Работодателя: Создать вакансию, Просмотреть список своих вакансий, Управлять вакансией (редактировать/удалить), Просмотреть отклики.

Выводы
Пользовательские требования — ключевой артефакт, связывающий бизнес-цели с функциональностью системы. Их корректная формулировка и визуализация (через User Story или Use Case Diagram) позволяют создать общее видение, управлять скоупом проекта и заложить основу для последующих этапов проектирования, разработки и тестирования.