Пример требований к системе. Часть 2.

3 Спецификация вариантов использования


3.1 Общие сценарии
3.1.1 Удаление любого объекта, (если не сказано обратного)
Примечание по реализации. Запрос подтверждения удаления не нужен, т.к. нельзя удалить большой блок информации без возможности восстановления.

3.1.1.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель

3.1.1.2 Основной сценарий
1. ОДЛ отдает команду на удаление объекта
2. Система подтверждает, что данный объект не был отослан на другие базы данных
3. Система удаляет объект и все дочерние объекты

3.1.1.3 Альтернативный сценарий 2а
1. Данный объект был отослан
2. Система помечает объект как удаленный
3. Система устанавливает признаки объекта “изменен” и “время изменения”

3.1.2 Редактирование любого объекта
3.1.2.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель

3.1.2.2 Предусловие
ОДЛ просматривает объект

3.1.2.3 Основной сценарий
1. ОДЛ изменяет значения атрибутов объекта
2. Система отображает сделанные изменения
3. ОДЛ отдает команду на сохранение
4. Система сохраняет сделанные изменения
5. Система устанавливает признаки объекта “изменен” и “время изменения” в БД

3.1.3 Восстановление объекта помеченного как удаленный
3.1.3.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель
Контекст: ОДЛ просматривает список соответствующих объектов

3.1.3.2 Основной сценарий
1. ОДЛ устанавливает фильтр в значение “показать удаленные объекты”
2. Система отображает полный список объектов
3. ОДЛ дает команду на восстановление объекта
4. Система устанавливает для объекта признак “активен” и устанавливает дату изменения.
3.2 Партнеры
3.2.1 Просмотр списка партнеров
3.2.1.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель

3.2.1.2 Основной сценарий
1. ОДЛ отдает команду на просмотр списка партнеров
2. Система отображает список партнеров, упорядоченный по имени.

3.2.1.3 Расширение
1. ОДЛ ищет партнера, набирая первые буквы.
2. Система подтверждает, что есть хотя бы один партнер, имя которого начинается с данной комбинации
3. Система позиционирует фокус на первом партнере, имя которого начинается с введенной комбинации.

3.2.2 CRUD Партнера
ОДЛ – медпредставитель

3.3 Группа “Связанные объекты партнера”

Сценарии похожи для объектов:

  • Обязательство
  • ПМИ
  • Визит
  • Презентация
  • Семинар
  • Спонсорство
  • Вопросник

ОДЛ - медпредставитель

3.3.1 Просмотр списка обязательств по партнеру
3.3.1.1 Расширение
Просмотр удаленных

3.3.2 CRUD обязательств по партнеру
3.3.3 Простановка отметки о выполнении обязательства
3.3.3.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель
Контекст: ОДЛ просматривает список обязательств

3.3.3.2 Основной сценарий
1. ОДЛ отдает команду на ввод даты выполнения для определенного обязательства
2. Система предоставляет форму ввода
3. ОДЛ вводит дату
4. ОДЛ отдает команду на сохранение
5. Система сохраняет сделанные изменения

3.3.4 Снятие отметки о выполнении обязательства
3.3.4.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель
Контекст: ОДЛ просматривает список обязательств

3.3.4.2 Основной сценарий
1. ОДЛ отдает команду на снятие отметки о выполнении
2. Система подтверждает выполнение операции

3.3.5 Просмотр списка ПМИ
3.3.6 CRUD

3.3.7 Просмотр списка визитов

3.3.8 CRUD визитов

3.3.9 CRUD объектов визита

3.3.10 Просмотр списка спонсорства

3.3.11 CRUD

3.3.12 Просмотр списка вопросников
3.3.12.1 Расширение
Печать вопросника

3.3.13 CRUD вопросника

3.3.14 Создание вопросника
3.3.14.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель
Контекст: ОДЛ просматривает список вопросников

3.3.14.2 Основной сценарий
1. ОДЛ отдает команду на создание вопросника
2. Система отображает список шаблонов
3. ОДЛ выбирает шаблон
4. Система создает экземпляр вопросника
5. ОДЛ заполняет вопросник
6. ОДЛ отдает команду на сохранение
7. Система подтверждает выполнение

3.3.14.3 Расширение ” Печать вопросника”

3.4 Семинары
Данная группа не привязана к одному партнеру.
Семинар проводится для группы, среди которых может быть несколько приглашенных партнеров. Затрагивает одну или несколько тем.
Презентация проводится для неопределенной аудитории. Сопровождается раздачей образцов.
3.4.1 Просмотр списка семинаров
3.4.1.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель
Контекст:

3.4.1.2 Основной сценарий

3.4.2 CRUD
Примечание по реализации. Эта группа прецедентов касается основной информации о семинаре:
• Дата
• Время
• Тема (если тем несколько, то основная, дополнительные в отдельном прецеденте)
Работа с прочими атрибутами описывается в других прецедентах.

3.4.3 Редактирование списка партнеров на семинаре
3.4.3.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель
Контекст: ОДЛ просматривает список партнеров, присутствующих на семинаре

3.4.3.2 Основной сценарий
1. ОДЛ отдает одну из команд: добавить, удалить партнера из списка, присутствующих на семинаре
2. Система подтверждает выполнение действия
3. ОДЛ отдает команду сохранить список партнеров, присутствующих на семинаре
4. Система подтверждает выполнение операции

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

3.4.4 Учет розданных материалов

  • Материалы
  • Образцы
  • Сувениры

3.5 Отчеты по медпредставителю
3.5.1 Календарный Отчет
Примечание по реализации. Может быть перенесено в группу “Ежедневник”

ОДЛ – медпредставитель

3.6 Ежедневник (еженедельник)
Приоритет этой группы низкий. Может быть специфицировано позднее.
Примечание по требованиям. Должна быть печать расписания. Должна быть корректировка расписания.
3.6.1 Просмотр списка задач
3.6.1.1 Расширения
• Печать
• Навигация

3.7 Синхронизация с центральной БД
3.7.1 Пользовательский сценарий
3.7.1.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: медпредставитель

3.7.1.2 Предусловие
Установлен канал связи

3.7.1.3 Основной сценарий
1. ОДЛ отдает команду на синхронизацию с центральной БД
2. Система подтверждает установления связи с центральным сервером
Система отображает ход операции
3. Запускается сценарий “Передача изменений в партнерах и связанных объектах”
4. Запускается сценарий “Синхронизация списка партнеров”
5. Запускается сценарий “Синхронизация справочников”
6. Система подтверждает успешное завершение операции

3.7.1.4 Альтернативный сценарий
3.7.2 Передача изменений в партнерах и связанных объектах
Устанавливается признак “отослан”
3.7.3 Синхронизация списка партнеров
3.7.4 Синхронизация справочников
Устанавливается признак “отослан”

3.8 Администрирование
3.8.1 CRUD пользователя системы
3.8.2 Настройка прав доступа пользователя системы
Приоритет низкий.
В первой версии системы:
• Всегда существует только один администратор
• Он же обладает правами аналитика
• Отдельные пользователи “аналитики” не предусматриваются
• Все добавленные пользователи системы автоматически получают роль медпредставителя
3.8.3 Просмотр партнеров и медпредставителей
3.8.4 Открепление партнера
3.8.4.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: администратор
Контекст: Просмотр партнеров и медпредставителей
3.8.4.2 Основной сценарий

3.8.5 Прикрепление партнера
3.8.5.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: администратор
Контекст: Просмотр партнеров и медпредставителей

3.8.5.2 Основной сценарий
3.8.6 Передача партнера
3.8.6.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: администратор
Контекст: Просмотр партнеров и медпредставителей

3.8.6.2 Основной сценарий
1. ОДЛ отдает команду о передаче партнера от одного медпредставителя другому
2. Запускается прецедент “Открепление партнера”
3. Запускается прецедент “Прикрепление партнера”

3.8.7 Создание базы данных медпредставителя
Примечание. Это решает проблему разрушения локальной БД. Остается открытым вопрос передачи этой базы на место. Может быть решено в следующем сценарии:

3.8.7.1 Краткое описание
Уровень: обобщенный
ОДЛ: администратор
ДЛ: мепредставитель
Цель: создание нового представителя или восстановление разрушенной локальной БД

3.8.7.2 Предусловие
Медпредставитель есть в системе

3.8.7.3 Основной сценарий
1. ОДЛ отдает команду на создание локальной БД медпредставителя
2. Система уничтожает текущую локальную БД представителя на сервере ОДЛ
3. Система создает БД представителя на сервере ОДЛ
4. Система устанавливает признак “отправлен” для медпредставителя
5. Система создает бэкап БД
6. ОДЛ отправляет бэкап БД ДЛ (вне рамок системы)
7. ДЛ сохраняет на своем ПК бэкап БД (вне рамок системы)
8. ДЛ запускает приложение
9. ДЛ отдает команду на импорт БД
10. Система уничтожает текущую локальную БД представителя на ПК ДЛ
11. Система создает БД представителя на ПК ДЛ

3.9 Настройка
3.9.1 Просмотр шаблонов вопросников
3.9.2 CRUD шаблона вопросника

3.9.3 Создание тела шаблона вопросника
3.9.3.1 Краткое описание
Уровень: цель пользователя
Основное действующее лицо: администратор

3.9.3.2 Основной сценарий
1. ОДЛ вводит новый вопрос, удаляет или редактирует вопрос
2. ОДЛ указывает тип ответа: “Выбор из списка ответов”; “Текст”; “диапазон”
3. ОДЛ вводит/редактирует/удаляет ответы
4. ОДЛ отдает команду на сохранение изменений
5. Система сохраняет шаблон

Примечание по реализации. В первой версии реализуется единственный тип “Выбор из списка ответов”.
3.9.4 Просмотр списка справочников
Примечания.

  • Сценарии для всех справочников похожи и будут специфицированы в общем виде.
  • Список справочников может быть изменен только программно.

3.9.5 Просмотр справочника

3.9.6 CRUD справочника

3.10 Аналитика
3.10.1 Получение отчета в разрезе
(простейшие фильтры)
3.11 Склад
Приоритет низкий.
Данная группа сценарием может быть специфицирована позднее

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.