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

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

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

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

Специалист по размещению выбирает поиск по кандидатам.

Система получает перечень специализаций кандидата и заполняет список кандидатов.

Система получает заранее определенный перечень специализаций кандидата и заполняет список специализаций.

Система получает заранее определенный перечень географических регионов.

Система отображает окно поиска кандидатов.

Специалист по размещению выбирает специализацию кандидата.

Специалист по размещению выбирает должность кандидата.

Специалист по размещению выбирает географический регион.

Система определяет регион и заполняет подрегион.

Специалист по размещению выбирает географический подрегион.

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

Система получает перечень кандидатов, которые соответствуют поисковому запросу специализаций кандидата. [Alt 1]

Система отображает перечень кандидатов, которые соответствуют поисковому запросу. [Alt 2]

Конец варианта использования

Alt 1: Если соответствия не найдены, система отображает сообщение, информирующее об отсутствии найденных соответствий. Конец варианта использования.

Alt 2: Если количество найденных соответствий превышает количество, доступное для просмотра пользователем, система предоставит возможность отобразить несколько страниц. Конец варианта использования.

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

--

Автор: Charles Suscheck

Оригинал статьи: http://www.agileconnection.com/print/art[...]traditional-vs-use-cases-vs-user-stories

Еще интересные статьи на эту тему:

• Wiki для управления требованиями
• Лучше не писать техническое задание в Google Docs
• Нефункциональные пользовательские истории
• Критерии приёмки для требований в Agile
• Проектная документация в Agile