И измеримый результат, важный для заказчика

Определение требований, приносящих ощутимый

По мнению Карла Вигера, «перспективы, открываемые вариантами использования,

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

позволяющих заказчикам делать их работу» [20]. Существует несколько

причин, благодаря которым дело обстоит именно так.

Во-первых, построение вариантов использования помогает создавать программы,

соответствующие целям пользователей. Варианты использования — это функции

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

Определяя поле зрения каждого типа пользователей, мы можем определить

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

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

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

сложно понять, действительно ли эти функции так важны, и вообще годятся ли

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

удовлетворяют? Насколько значимый результат они должны принести бизнесу?

Лучшими вариантами использования считаются те, которые приносят наиболее

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

Варианты использования, приносящие результаты с отрицательной ценностью

или заставляющие пользователя делать то, чего он делать не способен, не считаются

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

использования», поскольку они описывают те способы использования системы,

которые должны быть предотвращены. Примером такого неправильного варианта

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

с чужих счетов на свой. Варианты использования, приносящие малоценные или

не имеющие ценности результаты, используются редко, это скорее «варианты неиспользования

».

Как мы отмечали в главе 1, множество людей приходило к выводу, что просто

задаваться вопросом, чего они ждут от системы, неправильно. Вместо верного ответа

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

достаточно разумным, но при пристальном рассмотрении мог оказаться никак не

связанным с истинными потребностями пользователей. Стратегия вариантов использования

предлагает нам перефразировать этот вопрос, добавляя в его конец

три слова — что должна делать система для каждого пользователя? Может показаться,

что разница невелика, но результат получается совершенно другой. Это

добавление помогает нам постоянно концентрироваться на понимании того, как

система должна поддерживать работу своих пользователей. Это направляет нас на

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

нам воздержаться от предложения дополнительных функций, не нужных никому

из пользователей.

Кроме того, варианты использования интуитивно понятны. Пользователи и заказчики

не должны изучать сложную нотацию. Почти все время можно использовать

английский (то есть естественный) язык^ Это делает легким как чтение описаний

вариантов использования, так и внесение в них изменений.

Или русский. — Примеч. пер. __

заказчиков и разработчиков. Пользователи и заказчики выступают в качестве

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

обсуждение и помочь пользователям и заказчикам изложить свои пожелания.

Модель вариантов использования применяется для достижения соглашения

с пользователями и заказчиками о функциях будущей системы. Мы можем считать

модель вариантов использования полной спецификацией всех возможных

путей использования системы (вариантов использования). Эта спецификация

может войти и в договор, заключаемый с заказчиком. Модель вариантов использования

помогает нам определить границы системы, описывая все, что она должна

делать для пользователей Интересный подход к структурированию вариантов использования

содержится в [ 15]. А [57] содержит удачное общее введение в эту тему.