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

Я работал со многими командами, адаптирующими Agile в своей работе. В каждой ситуации, как правило, камнем преткновения всегда оказывались пользовательские истории, при часто задаваемом вопросе типа: “В чем заключается различие между традиционными требованиями, вариантами использования и пользовательскими историями?” Я бы хотел ответить на этот вопрос, дать определение каждому типу требования и привести примеры. Я буду использовать следующие пример на протяжении всей статьи: представьте, что вы создаете программное оборудование для фирм по трудоустройству управленческих кадров, и одна из таких фирм запросила возможность поиска кандидатов на определенную должность по специальности в пределах конкретной географической локации. Например, “Я хочу найти всех бизнес-аналитиков, специализирующихся в области закона Сарбейнса-Оксли (SOX), в пределах пятидесяти миль от Нью-Йорка”.

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

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

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

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