2. Документ «Видения». Модель и словарь предметной области.

Видение (Vision) – это представление программного продукта со стороны пользователя или заказчика на уровне ключевых потребностей заинтересованных лиц и свойств системы.

Свойства системы (feature) – это эксплуатационная возможность системы, которая удовлетворяет потребность потребителя.

Пример. Потребность1: повышение оперативности доступа к изменению материала. Свойство ПП1: хранение учебного материала в единой БД, доступной преподавателям и студентам.

Потребность2: общение преподавателей и студентов в неурочное время. Свойство ПП2: реализация электронной почты или электронной доски объявлений.

Модель и словарь предметной области.

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

1. модель бизнес-процессов, которые протекают в системе;

2. модель предметной области в виде диаграмм.

Модель предметной области определяет наиболее важные классы объектов (уточнение требований - цель ее создания).

Понятия (классы), которые могут выявляться при построении бизнес - модели:

1. физические и материальные объекты (облако, ветер – физические, стул, стол – материальные);

2. спецификация (описание объекта: полета, товара)

3. место расположения (магазин, аэропорт);

4. транзакция (продажа, платеж);

5. роли людей (студент, продавец);

6. контейнеры объектов (склад, касса);

7. содержимое контейнеров;

8. внешние системы;

9. организации (деканат);

10. событие (кража, продажа);

11. правила и политики (правило возврата товара);

12. перечень (каталоги) – каталог товаров.

Ассоциация - отображение взаимосвязи (глаголы).

Роль - является содержанием (для дисциплины - учебный материал).

Цель модели - выявить требования к системе.

Словарь предметной области (глоссарий) – все, что есть в предметной области д.б. в глоссарии, но могут быть и дополнения.

3. Функциональные и нефункциональные требования к системе. Варианты использования системы.

В процесс определения требований к системе входят определение функциональных и нефункциональных требований.

Функциональные требования (модель прецедентов или вариантов использования) описывают желаемое поведение системы.

Вариант использования (Use Case) – это последовательность действий актанта и реакций системы, приводящая к полезному для актанта результату.

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

Модель вариантов использования – совокупность функциональных требований к системе, описанных в форме вариантов использования. Она содержит описание актантов, спецификации вариантов использования и ассоциаций между ними. Модель вариантов использования является соглашением между заказчиком и разработчиком ПО.

Нефункциональные требования - любые требования, не являющиеся функциональными, например: надежность, производительность, ограничения среды; ограничение реализации; зависимость от платформы; рентабельность; расширяемость. Некоторые нефункциональные требования являются слишком обобщенными и не могут быть привязаны к конкретному варианту использования или конкретному реальному классу. Они должны быть вынесены в отдельный список дополнительных требований

Спецификация вариантов использования включает в себя:

• Название варианта использования

• Актанты

• Краткое описание

• Основной поток событий – типовая и, может быть, самая короткая последовательность действий, дающая актанту желаемый результат

• Альтернативные потоки событий – вспомогательный вариант получения желаемого результата, который используется, если выполнение основного потока не возможно.

• Предусловия

• Постусловия

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

• Особые требования