Опубликован: 18.06.2007 | Уровень: для всех | Доступ: платный | ВУЗ: Сибирский федеральный университет (г. Красноярск)
Лекция 8:

Классификация и специфицирование требований

< Лекция 7 || Лекция 8: 123 || Лекция 9 >

Шаблон полного описания варианта использования по А. Коберну

Название <краткая фраза в виде глагола в неопределенной форме совершенного вида, отражающая цель>

Контекст использования <уточнение цели, при необходимости - условия ее нормального завершения>.

Область действия <ссылка на рамки проекта>. Например - подсистема бухгалтерского учета.

Уровень <один из трех: обобщенный, цели пользователя, подфункции>. Автор задает предопределенную трехуровневую классификацию требований, в целом соответствующую классификации требований на бизнес-требования, требования пользователей и функциональные требования, см. "Понятие требования. Классификации требований" .

Основное действующее лицо <имя роли основного актора или его описание>.

Участники и интересы <список других акторов-участников прецедента с указанием их интересов>.

Предусловие <то, что ожидается, уже имеет место>.

Минимальные гарантии <что гарантируется акторам-участникам>. Например - в случае неудавшейся транзакции все данные, имевшиеся в системе до ее начала, сохраняются неизменными.

Гарантии успеха <что получат акторы-участники в случае успешного достижения цели>.

Триггер <то, что "запускает" вариант использования, обычно - событие во времени>.

Основной сценарий <здесь перечисляются шаги основного сценария, начиная от триггера и вплоть до достижения гарантии успеха>.

Формат описания: <Номер шага> <Описание действия>

Расширения <здесь последовательно описываются все альтернативные сценарии>. Каждая из альтернатив привязана к шагу основного сценария.

Формат описания: <Номер шага.Номер расширения> <Условие>:<Действие или ссылка на подчиненный вариант использования>.

Любой из шагов основного сценария может иметь 1 или более ветвлений. Каждое ветвление оформляется в виде расширения. В блоке "Расширения" все расширения описываются последовательно.

В случае, если альтернативный сценарий не удается описать одной строкой - применяется следующий формат.

Начиная со строки, следующей после описания расширения, идет описание его действий в формате основного сценария:

<Номер шага.Номер расширения.Номер шага расширения> <Действие>

Описание расширения заканчивается описанием выхода из расширения. Основные варианты выхода из расширения: возврат к очередному по номеру шагу основного сценария, окончание прецедента, переход к другому шагу основного сценария.

Список изменений в технологии и данных <что гарантируется акторам-участникам>. Например - в случае неудавшейся транзакции все данные, имевшиеся в системе до ее начала, сохраняются неизменными.

Вспомогательная информация <дополнительная информация, полезная при описании варианта использования>.

Табличные представления варианта использования

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

Таблица 8.1. Таблица в 2 колонки:
Актор Действие
Пользователь Формирует запрос на поиск заказов
Система Отображает список заказов
Пользователь Выбирает требуемый заказ
Система Показывает подробную информацию по заказу
Таблица 8.2. Таблица в 3 колонки:
№ шага Пользователь Система
1 Делает запрос на поиск заказов Отображает список заказов
2 Выбирает требуемый заказ Показывает подробную информацию по заказу

Шаблон варианта использования RUP

С шаблоном описания варианта использования RUP и примерами можно ознакомиться в интерактивной версии RUP 2http://www-306.ibm.com/software/rational/ .

Ниже приведен краткий обзор его разделов.

  1. Наименования и краткое описание. В этом разделе указывается: наименование варианта использования, акторы варианта использования, краткое (в один абзац) описание варианта использования.
  2. Поток событий

    2.1. Основной поток событий

    Так же, как в "Основной сценарий".

    2.2. Альтернативные потоки событий

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

  3. Специальные требования

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

  4. Предусловия

    События, описываемые предусловиями или постусловиями, должны быть состояниями, которые пользователь может наблюдать [8.3]. Предусловие описывает состояние, в котором система должна находиться до начала исполнения прецедента.

  5. Постусловия

    Постусловие RUP по сути описывает то же, что и минимальная гарантия у Коберна. Л.Новиков [8.3] акцентирует внимание на том, что корректно сформулированное постусловие должно быть истинным при любом возможном сценарии прецедента, а не описанном в основном потоке.

  6. Точки расширения

    Данный параграф определяет положение точек, расширяющих поток событий.

< Лекция 7 || Лекция 8: 123 || Лекция 9 >
Оксана Швецова
Оксана Швецова

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

Ринат Гатауллин
Ринат Гатауллин

Здравствуйте. Интересует возможность получения диплома( https://intuit.ru/sites/default/files/diploma/examples/P/955/Nekommerch-2-1-PRF-example.jpg ). Курс пройден. Сертификат не подходит. В сертификате ошибка, указано по датам время прохождения около 14 дней, хотя написано 576 часов.

Руслан Рекун
Руслан Рекун
Россия, г. Краснодар
Анна Анисимова
Анна Анисимова
Россия, Москва, МГУ имени М.В. Ломоносова, 2009