Что использовать: User Stories или Use Cases?

Вопрос непростой, но мы постараемся на него ответить.

На самом деле, это зависит от вашей аудитории. Формальные и неформальные Use Cases помимо того, что более затратны в реализации, также предоставляют больше контекста и позволяют вам описать более сложные варианты использования вашего продукта. Некоторые пользователи настолько сложны, что вам необходимо использовать Use Cases для их описания. Некоторые настолько просты, что что-либо сложнее User Story является бесполезной тратой усилий. Интерпретация того, что является сложным, а что простым, тем не менее, не является просто оценкой того, что пользователи хотят делать, она также зависит от уровня владения предметной областью вашей командой разработчиков.

В процессе проектирования взаимодействия с системой в виде Use Case, руководитель продукта описывает много сопутствующей информации: роли пользователей, внутренние правила работы потенциальных пользователей, которые влияют на логику Use Case и являются бизнес-правилами. В процессе расстановки приоритетов и выявления критичности тех или других Use Case формируются требования к пользовательскому интерфейсу. При определении частоты выполнения того или иного действия пользователя в системе, описанного в виде Use Case, формируются требования к производительности системы.

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

Вот ключевые отличия кейсов от историй:

1. UML-диаграмма прецедентов (Use Case) может использоваться с обеими схемами представления требований, наглядно показывая основные функциональные возможности взаимодействия стейкхолдера с проектируемой системой, без детализации их выполнения. Однако, неподготовленному читателю такая диаграмма покажется сложной и непонятной, в отличие от простых формулировок User Story и текстового (табличного) представления Use Case.
2. User Story отлично подходит для разработки поведенческих сценариев тестирования, программы и методики приемочных испытаний;
3. Сценарии использования (Use case), в отличие от пользовательских историй, описывают процесс и его шаги подробно, предоставляя всю необходимую информацию о взаимодействии актора с системой, включая цель, пред- и пост-условия, триггеры, основные и альтернативные потоки, а также бизнес-правила;
4. User Story позволяет указать нефункциональные требования с точным заданием значений нужных показателей, например, время отклика на событие, наработку на отказ и пр.;
5. Use Сase объединяет функциональные требования по контексту.

Больше полезных материалов смотрите в моем Телеграм-канале: https://t.me/FreshProductGo.