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

Первая часть описывает типы пользователей (актера), имеющих контакт с дипломным приложением. Необходимо перечислить все типы вовлеченных пользователей и дать краткое описание основных задач и уровеня ответственности и для каждого из них.

2. Функциональные требования

Вторая часть описывает функциональные требования к дипломному приложению. Функциональные требования описывают функции системы, а также ее поведение в ответ на реакцию пользователей (или некоторого события). При разработке требований как правило следует избегать технических деталей реализации тех или иных требований. Более подробная информация о функциональных требованиях доступна в [2].

Каждое функциональное требование должно предоставлять как можно более полную информацию о некоторой ОДНОЙ функции дипломного приложения. Полнота описания требования определяется присутствием следующих атрибутов:

• уникальный идентификатор требования;

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

• список вовлеченных пользователей (актеры-участники);

• связанный с требованием сценарий (если есть);

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

• Гарантии успеха, обозначают то, что получат актеры-участники в случае успешного достижения цели (например в случае успешной авторизации).

• Минимальные гарантии, обозначают то, что получат актеры-участники, если цель не была достигнута (например в случае ошибки аутентификации).

Для каждого требования указываются только значимые атрибуты.

При документировании требований следует учитывать следующую информацию:

• Атомарность требования. Каждое требование должно описывать только одну функцию приложения.

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

• Верифицируемость требования. Каждое требование должно обладать свойством верифицируемости, т. е. для каждого требования должна существовать объективная процедура проверки достижимости требования приложением.

1. Моделирование прецедентов

Для каждого актера связанные с ним функциональные требования необходимо представить в виде UML диаграммы прецендентов (Use cases diagram). Диаграммы и функциональные требования должны быть синхронизированы. Важно понимать что диаграмма является иллюстрацией и не может рассматриваться полноценным носителем информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. User Stories

TBD