Повышение эффективности разработки программного обеспечения с использованием подхода, ориентированного на случаи использования: реальные шаблоны и примеры

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

Преимущества

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

• Углублённое понимание потребностей и требований пользователей
• Чёткое определение поведения и функциональности системы
• Раннее выявление потенциальных проблем и конфликтов
• Улучшенное взаимодействие между заинтересованными сторонами
• Эффективное распределение ресурсов и усилий
• Эффективная приоритизация функций и требований

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

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

1. Определите заинтересованные стороны и их требования:Начните с определения всех заинтересованных сторон, участвующих в проекте, и соберите их требования. К ним могут относиться конечные пользователи, владельцы бизнеса и другие члены команды.
2. Приоритизируйте требования:Как только у вас будет список требований, приоритизируйте их на основе их важности и влияния на проект. Это поможет вам сначала сосредоточиться на наиболее критичных потребностях.
3. Определите границы проекта:На основе приоритизированных требований определите границы проекта. Это включает определение функций и возможностей, которые будет включать проект.
4. Создайте случаи использования:Случаи использования — это описания того, как пользователь взаимодействует с системой для достижения конкретной цели. Создайте случаи использования, описывающие различные сценарии, в которых будет использоваться система.
5. Проверьте и уточните случаи использования:Проверьте случаи использования вместе с заинтересованными сторонами и уточните их на основе их обратной связи. Это может включать добавление или удаление шагов, обновление требований или уточнение деталей.
6. Создайте пользовательские истории:Пользовательские истории — это краткие описания функции или функциональности с точки зрения конечного пользователя. Создайте пользовательские истории на основе разработанных вами случаев использования.
7. Оцените усилия:Оцените усилия, необходимые для разработки каждой пользовательской истории. Это поможет вам спланировать график проекта и распределение ресурсов.
8. Приоритизируйте пользовательские истории:Приоритизируйте пользовательские истории на основе их важности и влияния на проект.
9. Планируйте спринты:На основе приоритизированных пользовательских историй планируйте спринты разработки. Каждый спринт должен включать набор пользовательских историй, которые можно завершить в течение срока спринта.
10. Просмотр и уточнение: Оцените прогресс каждого спринта и при необходимости уточните случаи использования и пользовательские истории.
11. Тестирование и подтверждение: Протестируйте систему, чтобы убедиться, что она соответствует требованиям, и подтвердите, что она отвечает потребностям заинтересованных сторон.
12. Развертывание и мониторинг: Как только система будет протестирована и подтверждена, разверните ее в производственной среде и контролируйте ее на наличие каких-либо проблем или ошибок.

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

Шаблоны документов Agile для подхода к случаям использования

Документ анализа заинтересованных сторон

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

Документ анализа заинтересованных сторон: мобильное банковское приложение

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

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

Шаблон сбора требований

Вот пример шаблона сбора требований для описанной вами проблемы:

Шаблон сбора требований: мобильное приложение для банковского обслуживания

Описание требования	Уровень приоритета	Критерии приемки	Имя заинтересованного лица
Возможность просмотра остатков по счетам	Высокий	Пользователь должен иметь возможность видеть текущие остатки по всем счетам, связанным с его профилем	Клиенты
Возможность перевода средств между счетами	Высокий	Пользователь должен иметь возможность переводить средства между счетами с помощью мобильного приложения	Клиенты
Возможность оплаты счетов	Высокий	Пользователь должен иметь возможность оплачивать счета через мобильное приложение	Клиенты
Эффективная системная часть	Высокий	Системная часть должна быть способна обрабатывать высокие объемы транзакций и быть простой в обслуживании	Сотрудники банка
Отслеживание метрик использования	Средний	Приложение должно иметь возможность отслеживать метрики использования клиентами и уровни удовлетворенности	Владельцы бизнеса

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

Матрица следования требований

Вот пример матрицы следования требований для описанной вами проблемы:

Матрица следования требований: мобильное приложение для банковского обслуживания

Идентификатор требования	Описание требований	Имя заинтересованного лица	Статус	Ссылка на документ проектирования	Ссылка на документ тестирования
R1	Возможность просмотра остатков по счетам	Клиенты	Осуществлено	Дизайн интерфейса 1.1	Случай тестирования 1.1
R2	Возможность перевода средств между счетами	Клиенты	В процессе	Дизайн интерфейса 1.2	Случай тестирования 1.2
R3	Возможность оплаты счетов	Клиенты	Не начато	Дизайн интерфейса 1.3	Случай тестирования 1.3
R4	Эффективная системная часть	Сотрудники банка	Осуществлено	Проектирование системной части 2.1	Случай тестирования 2.1
R5	Отслеживание метрик использования	Владельцы бизнеса	В процессе	Дизайн аналитики 3.1	Тестовый случай 3.1

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

Документ о пользовательской персоне

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

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

Имя персоны: Сара

Биография:

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

Демография:

• Возраст: 29
• Пол: Женский
• Семейное положение: Холоста
• Профессия: Графический дизайнер
• Местоположение: Город

Цели:

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

Проблемы:

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

Цитата:

«Мне нравится использовать свое мобильное приложение для управления своими финансами. Это экономит мне так много времени и хлопот. Я просто хочу быстро и легко получать доступ к своим балансам, переводить деньги между своими счетами и вовремя оплачивать счета.»

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

 

Список кандидатских вариантов использования

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

1. Просмотр балансов счетов – Пользователи должны иметь возможность видеть текущие балансы своих счетов по всем счетам, связанным с их профилем.
2. Перевод средств между счетами – Пользователи должны иметь возможность переводить средства между своими счетами с помощью мобильного приложения.
3. Оплата счетов – Пользователи должны иметь возможность оплачивать счета через мобильное приложение.
4. Настройка автоматических платежей – Пользователи должны иметь возможность настраивать автоматические платежи за повторяющиеся счета.
5. Пополнение счета чеками – Пользователи должны иметь возможность вносить чеки с помощью мобильного приложения.
6. Поиск ближайших банкоматов и отделений – Пользователи должны иметь возможность находить ближайшие банкоматы и отделения банка с помощью мобильного приложения.
7. Сообщить о потерянной или украденной карте – Пользователи должны иметь возможность сообщать о потерянных или украденных картах с помощью мобильного приложения.
8. Обратиться в службу поддержки клиентов – Пользователи должны иметь возможность обращаться в службу поддержки клиентов через мобильное приложение.
9. Просмотр истории транзакций – Пользователи должны иметь возможность просматривать историю своих транзакций по всем счетам, связанным с их профилем.
10. Настройка уведомлений по счету – Пользователи должны иметь возможность настраивать уведомления о низком балансе, крупных транзакциях и других действиях по счету.

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

 

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

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

Случай использования	Размер	Приоритет	Цель/Ценности
Просмотр балансов счетов	Малый	Высокий	Удобство, доступ к информации
Перевод средств между счетами	Средний	Высокий	Удобство, эффективность
Оплата счетов	Средний	Высокий	Удобство, эффективность
Настройка автоматических платежей	Средний	Средний	Удобство, эффективность
Пополнение чеков	Средний	Средний	Удобство, эффективность
Найти ближайшие банкоматы и отделения	Малый	Средний	Удобство, доступ к информации
Сообщить о потерянных или украденных картах	Малый	Средний	Безопасность, предотвращение мошенничества
Связаться со службой поддержки клиентов	Малый	Средний	Служба поддержки клиентов, удовлетворенность
Просмотр истории транзакций	Средний	Низкий	Ведение учета, доступ к информации
Настройка оповещений по счету	Средний	Низкий	Удобство, безопасность

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

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

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

Имя варианта использования: Просмотр балансов счетов

Участники:

• Клиент

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

Предварительные условия:

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

Основной поток:

1. Клиент открывает мобильное приложение для банковского обслуживания.
2. Клиент выбирает опцию «Просмотр балансов счетов» в главном меню.
3. Приложение отображает список счетов клиента вместе с текущим балансом каждого счета.
4. Клиент просматривает балансы счетов.

Альтернативные потоки:

• Если у клиента только один счет, приложение может автоматически отобразить баланс счета, не показывая список счетов (шаг 3).
• Если у клиента несколько счетов, но приложение не может получить балансы счетов, клиенту отображается сообщение об ошибке.

Постусловия:

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

Исключения:

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