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

Table of Contents hide

1 Какие методы фиксации функциональных требований?

2 Сбор функциональных требований с помощью пользовательских историй

4 Как определить функциональные требования с помощью варианта использования?

5 Реальный пользователь против субъекта варианта использования

6 Как получить функциональные требования, определив варианты использования системы

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

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

ОТРЕДАКТИРУЙТЕ ЭТУ ИЛЛЮСТРАЦИЮ — ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ ПРОТИВ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ

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

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

Какие методы фиксации функциональных требований?

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

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

Сбор функциональных требований с помощью пользовательских историй

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

Шаблон пользовательской истории

Пользовательские истории охватывают только основные элементы требования:

Для кого это?
Чего он ожидает от системы?
Почему это важно (необязательно?)?

Вот простой формат пользовательской истории, который используют 70% практиков:

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

Будьте максимально конкретными
Команда разработчиков НЕ является пользователем

Действие — поведение системы должно быть описано как действие.

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

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

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

Как определить функциональные требования с помощью варианта использования?

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

Ответ на этот вопрос таков: действующее лицо в анализе вариантов использования

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

Вариант использования начинается с «актера» или «кто», конкретного пользователя продукта или услуги.

Актор – это человек или внешняя система, играющая роль во взаимодействии с системой . Экземплярами акторов могут быть отдельные лица или внешние системы; тем не менее, каждый актор обеспечивает уникальную и важную точку зрения на систему, точку зрения, общую для каждого экземпляра (фактического человека/пользователя) актера.

Реальный пользователь против субъекта варианта использования

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

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

Это различие между акторами и экземплярами акторов иллюстрируется следующим:

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

ИЗМЕНИТЬ ЭТУ ИЛЛЮСТРАЦИЮ ТОРГОВОГО АВТОМАТА

И наоборот, один и тот же пользователь может играть несколько ролей (т. е. один и тот же человек может играть разные роли).

Например, доктор Гейтс, член комитета Computer Society. Он отвечает за управление системой управления членством, например за добавление и удаление учетных записей пользователей. Когда он это делает, он играет роль администратора (актера). Впрочем, тот же доктор Гейтс может быть и членом Компьютерного общества. В этом случае он также будет играть роль под названием «Член» (актер).

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

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

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

Обратите внимание, что:

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