Второй уровень точности — краткое описание варианта использования, изложение варианта использования в двух-трех предложениях. Для просмотра краткое описание также можно ввести в электронную таблицу или табличную форму (см. таблицу 3.3). Это полезно для обзора системы и организации работы.
Краткость в описании каяедого варианта использования имеет смысл, если вы хотите просмотреть полный набор вариантов использования за один раз. Однако придет время, когда вам понадобится сгруппировать их.
Создать группы вариантов использования.
Если вы работаете с инструментами обработки текстов, такими как Lotus Notes, электронные таблицы или текстовые редакторы, вы можете сформировать группы (кластеры) вариантов использования с помощью обычных методов расстановки меток. В инструментах, поддерживающих UML, такие группы называются пакетами. Ниже описаны четыре общих и достаточно эффективных метода группировки.
ПО ДЕЙСТВУЮЩЕМУ ЛИЦУ. Наиболее очевидный способ группировки вариантов использования — по основному действующему лицу. Однако при 80-100 вариантах использования этот способ неэффективен. На этом уровне у вас будет либо слишком много вариантов использования на одно основное действующее лицо, либо слишком много основных действующих лиц, либо слишком много пересечений между действующими лицами и вариантами использования.
ПО ОБОБЩЕННОМУ ВАРИАНТУ ИСПОЛЬЗОВАНИЯ. Некоторые варианты использования естественно группируются по своему жизненному циклу или (в больших проектах) по их месту в жизненном цикле. Такие связанные варианты использования обнаруживаются в обобщенных вариантах использования. Если вы не пишете обобщенные варианты использования, вам все же может понадобиться сгруппировать варианты использования, чтобы создавать, обновлять и удалять информацию определенного вида, а это и есть группа. В одном проекте система поддерживала эквивалент чековой книжки для клиентов. Мы назвали все изменяющие чековую книжку варианты использования вариантами использования чековой книжки. Эта группа разрабатывалась одной командой разработчиков, и все ее члены двигались вперед таким образом, что руководителям проекта было легко управлять разработкой.
ПО КОМАНДЕ РАЗРАБОТЧИКОВ И ВЕРСИИ. Группировка вариантов использования по команде разработчиков, которая должна реализовывать проект, и номеру версии упрощает контроль над выполнением работ. В таком случае правомерен вопрос: “Собирается ли команда, отвечающая за группу профилей пользователей, разработать ее в срок?” Группировка по команде разработчиков возможна даже в больших проектах.
ПО ПРЕДМЕТНОЙ ОБЛАСТИ. Если в проекте более 100 вариантов использования, разработчики автоматически разделяют их по предметным областям. Обычно именовать естественные предметные области не составляет труда. Один проект использовал информацию клиента, продвижения, выписку счетов и рекламную деятельность. В другом были такие предметные области, как прием заказов, маршрутизация, отслеживание, доставка и выписка счета. Зачастую внутри различных предметных областей существуют подпроекты. Каждая предметная область может содержать от 20 до 100 вариантов использования.
Несмотря на то, что отслеживать 240 вариантов использования довольно сложно, отслеживать 15-20 групп вполне приемлемо. В большом проекте я бы в первую очередь сгруппировал варианты использования по предметной области, чтобы получить 3-6 групп по 20-100 вариантов использования в каждой, а затем сгруппировал бы их по версии и команде разработчиков. В зависимости от количества вариантов использования в этих группах, я бы подытожил прогресс в работе с помощью соответствующих групп или обобщенных вариантов использования.