Опубликован: 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 часов.

Денис Овчинников
Денис Овчинников
Россия
Павел Артамонов
Павел Артамонов
Россия, Москва, Московский университет связи и информатики, 2016